Сообщений в теме: 5

[baranceva]

Автор: Патрик Прилл (Patrick Prill).

Оригинал статьи: https://testpappy.wo...for-the-future/

Перевод: Ольга Алифанова.

 

Если говорить о будущем тестирования и тестировщиков, для начала стоит обдумать текущую ситуацию и то, почему она нуждается в переменах.

Последние десять лет тестированию постоянно угрожают вымиранием. "Тестирование умерло", "Тестировщики должны учиться программировать", и как же обойтись без любимого лозунга торговцев автоматизацией "все тесты должны быть автоматизированы".

 

В середине мая 2016 года Джеймс и Джон Бах проводили воркшоп на тему "Преобразование тестировщиков". Я на нем не присутствовал, поэтому не буду вдаваться в детали. Он не произвел никаких потрясений в сообществе – мое внимание привлек один-единственный слайд, вырванный из контекста и опубликованный в Твиттере.

 

Подробнее...

[Vasiliy]

Хорошая статья, спасибо за перевод.

[Mendel]

Особенно интересно рассматривать, в свете того что к Agile прибавилась мобилизация. Спасибо за перевод, это действительно острый вопрос для отрасли.

[SALar]

Особенно интересно рассматривать, в свете того что к Agile прибавилась мобилизация. Спасибо за перевод, это действительно острый вопрос для отрасли.

Был такой замечательный блог "Тестирование по вторникам" замечательного специалиста Александра Александрова. Несколько цитат оттуда:

 

 

Вот оно чего, Михалыч … 
Я не являюсь апологетом гибких технологий. Я ни разу не слышал (хотя много раз слушал и Асхата Уразбаева, с которым работал много лет в Люксофте, и других евангелистов Agile) про инженерные особенности Agile. 

Я много раз слушал доклады про тестирование в Agile проектах (в частности, Илью Гаврилова и Алексея Баранцева, в квалификации которых не сомневаюсь), но ни разу не услышал ничего такого, что не имело бы непосредственного отношения к любым активностям тестирования в других (не Agile) проектах. 

.... 

Но причем здесь вторник? 
Если тестирование во вторник (тестирование в Agile) ничем не отличается от тестирования в остальные дни недели (тестирования в остальных методологиях), то есть ли такое понятие – тестирование в Agile - вообще? 

 

http://www.luxoft-tr...weekend/32.html

 

 

Про мобилизацию.

Я тестировал десктоп, веб, телефоны, инфоматы, банковские карты и т.д. Не поверите, отличия такие же как отличие тестирования по вторникам от тестирования по пятницам.

 

Be happy. 

[Mendel]

Речь идёт, про ускорение итераций (e.x. Scrum), если абстрагироваться от кода и на все деньги устраивать старый добрый ручной регресс всего и вся, то польза от тестирования не покроет затрат на него. Если же хорошо понимаешь какие компоненты в коде затронули и на что это может влиять, то можно сильно сократить время тестирования. Отличие от того же ватерфолл тут очевидное: в глобальных доработках затрагиваются все компоненты систем, в быстрых и локальных хот-фиксах - конкретные. По крайней мере композиция процессов тут должна быть другая.

С мобилизацией другая проблема, много устройств, и работа приложения может на них очень сильно отличаться. Тут тоже встаёт важный вопрос, либо закрыть глаза на потенциальные баги, либо расширять команду, либо делать гибкую автоматизацию, что ведёт к целому спектру новых проблем.

Если рассмотреть эти вещи вместе, то видно что при тех же основах процессы прилично меняются. Плюс к этому, появляются новые способы влиять на качество, а часть старых теряют свою актуальность.

[SALar]

Речь идёт, про ускорение итераций (e.x. Scrum), если абстрагироваться от кода и на все деньги устраивать старый добрый ручной регресс всего и вся, то польза от тестирования не покроет затрат на него. Если же хорошо понимаешь какие компоненты в коде затронули и на что это может влиять, то можно сильно сократить время тестирования. Отличие от того же ватерфолл тут очевидное: в глобальных доработках затрагиваются все компоненты систем, в быстрых и локальных хот-фиксах - конкретные. По крайней мере композиция процессов тут должна быть другая.

С мобилизацией другая проблема, много устройств, и работа приложения может на них очень сильно отличаться. Тут тоже встаёт важный вопрос, либо закрыть глаза на потенциальные баги, либо расширять команду, либо делать гибкую автоматизацию, что ведёт к целому спектру новых проблем.

Если рассмотреть эти вещи вместе, то видно что при тех же основах процессы прилично меняются. Плюс к этому, появляются новые способы влиять на качество, а часть старых теряют свою актуальность.

По пунктам.

1.До Scrum нормой был вывод фичи в продакшен в 1-3 дня. Так делал я в 90-х, такое я видел в проектах близких по методологии к RUP (это то, чему противопоставлялась agile) в 2001. Для оценки масштаба: в 2001 (RUP, не Agile) проект зарабатывал в день столько же, сколько рамблер в год. 

Н-да.

Но потом пришел Scrum (Agile) и начался ад в несколько недель.

 

2. Водопада не существует и противопоставлять его эджайлу некорректно. Водопад - это удобная мишень для плохих консультантов. Очень удобно бороться с тем, что и так понятно, что плохо.

Противопоставляйте эджайл RUP-у  и MSF.

 

 

> С мобилизацией другая проблема, много устройств, и работа приложения может на них очень сильно отличаться.

Чем это отличается от проверки по куче ОС, DirectX, разрешений экрана, памяти, процессорах ...? Не гневите бога, конфигурационное тестирование десктоп сложнее мобильного. Вы счастливые люди, у вас ОЧЕНЬ мало конфигураций. 

А потов вы приходите к тестированию инфоматов, и понимаете, что десктоп - это цветочки.

 

Но при этом разницы в подходах к тестированию все равно нет.