Home

Автор: Алан Ричардсон

Оригинал статьи: http://blog.eviltester.com/2017/11/what-is-agile-testing.html

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

Когда мы работаем над Agile-проектом, нам требуется гигантская гибкость и возможность подгонки того, что мы делаем, под нужную форму.

Я могу сказать, чем Agile-тестирование не является. Существительным.

Поэтому когда мы спрашиваем, что такое Agile-тестирование – это не вещь. Нельзя купить пачку Agile-тестирования… Это глагол, это подход, это процесс.

Это то, как мы тестируем в Agile-проектах.

Это то, что мы делаем, и образ нашего мышления. Характерного для Agile-проекта.

Это кажется тавтологичным, очевидным, но по какой-то причине люди все усложняют, и началось это не вчера, как мы сейчас и выясним.

Люди цепляются за слова. А цепляются за них они потому, что не понимают по-настоящему, что эти слова означают. Они не понимали, что тестирование значило раньше. И Agile-тестирование кажется им новшеством.

В Agile мы необязательно заранее знаем, что мы будем делать.

Мы будем адаптироваться. Мы будем приоритезировать одну функциональность против другой, и тест-подход это компенсирует. И это делает наше тестирование уникальным.

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

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

Процесс тестирования – не нечто отдельное, живущее параллельной жизнью, не то, что можно отдать на аутсорс и оффшор. Это процесс, тесно связанный с подходом к программированию.

Потому что все это – подход к разработке ПО.

Одна часть этого подхода – программирование.

Другая часть – тестирование.

Они сливаются воедино, создавая эффективный процесс Agile-разработки.

Возможно, в нашем обычном процессе программирования внедрено множество снижающих риск процессов (TDD, ATDD).

Следовательно, подход к тестированию меняется, потому что меняется профилирование рисков.

Риски будут возникать в других местах системы, поэтому мы тестируем иначе, чтобы постараться это учесть.

Хочется верить, что тестировщик может тестировать лучше других; может тестировать иначе, чем другие. И мы хотим соответствующим образом использовать эти навыки в проекте, чтобы тестировщики не тратили свое время, покрывая только базовые критерии приемки.

Потому что практически кто угодно может протестировать на покрытие базовых приемочных критериев.

По мере развития проекта профиль его рисков меняется. Когда проект стартует, мы принимаем высокие риски, потому что мы стараемся создать минимально жизнеспособный продукт, хоть что-нибудь, чтобы обосновать определенные предположения, убедиться, что мы на верном пути, или полностью определиться, чего же хотят наши пользователи. Однако позднее мы хотим сделать наш проект более устойчивым, и не принимаем на себя столько риска, когда системой уже пользуются живые люди.

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

Подход Agile на самом деле ничем фундаментально не отличается от любого другого тестирования. Отличия заключаются в том, что у нас принято ассоциировать тестирование с большим количеством процессов, ловушек, атрибутики. Множеством дополнений.

Эти дополнения – ответ на требования процесса разработки, делающего множество всего заранее. А тестирование очень часто меняется в ответ на требования разработки.

Еще больше тут требуется вербальная коммуникация, дабы брать на себя ответственность за идентификацию рисков и проблем, когда они возникают.

Нам не нужна расширенная документация.

Это не значит, что у нас ее вообще нет.

Попытки что-то записать все еще важны для нас.

Но это не значит, что нам нужен инструмент управления тестированием – мы можем использовать какой угодно инструмент для отслеживания нашего проекта.

Нам нужно понимать тестирование, и поэтому и существует проблема с Agile-тестированием – просто потому, что люди не понимают, а что тестирование вообще такое. Поэтому они пытаются принести в проект все то, чем они занимались в традиционном «водопаде» - все шаблоны, все процессы. Просто потому, что они не понимают, что такое тестирование.

Все это – не тестирование.

Нам нужно понимать суть тестирования.

Это очень важно в Agile-процессах: мы делаем нечто постепенно, по ходу пьесы. И это означает, что мы отвечаем на нужды и изменения окружающей среды на основании своего опыта и опыта других людей, на основании того, что происходит в мире, конференций, статей. Мы впитываем все это. Мы экспериментируем. Мы видим, что работает, а что нет.

«Делать что-то по ходу пьесы» звучит так, как будто это что-то плохое. Мы делаем продукт по ходу дела, потому что мы тратим много времени на изучение областей, которые работают, которые связаны со сложными динамическими системами, и учимся у них.

Тестирование никогда не было про тестировщика.

Тестирование всегда было про процессы, которые мы используем, про подход, который мы применяем, и про полученные результаты. И Agile в особенности отвергает подход «тестировщик занимается тестированием».

Agile про то, что тестировать – глагол, процесс в проекте. И если тестировщики держатся за тестирование обеими руками, крича, что «тестируем тут мы», то они не пользуются гибкостью и свободой Agile-проекта.

Нет такого, что вы приходите в Agile, и начинается «ага, это Agile-проект, нам нужна тест-стратегия, на одну страничку, потому что это Agile, а наш процесс в том, что…». Все развивается. Все меняется в зависимости от нужд проекта, навыков людей в команде, динамики существующего набора, и мы ожидаем этих перемен.

Мы можем добиться успеха в Agile через понимание и использование сути тестирования, и этому мы как тестировщики должны научиться. Это та ценность, которую мы даем Agile-проектам – сущность тестирования. И иногда мы – единственные, кто может ее внедрить, пока мы не научим других, как это правильно делается.

Более подробное мнение Алана Ричардсона см. на видео (на английском языке)

Обсудить в форуме