Переход от водопада к гибкому тестированию

Когда компания решает перейти от Waterfall к Agile-тестированию, на каких наиболее важных областях следует сосредоточиться для эффективного Agile-тестирования?

Как тестирование в Agile сравнивается с тестированием модели Waterfall? Какой набор действий важно знать и делать тестировщикам?



Тестирование в процессе разработки

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


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

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


В модели Waterfall нас учат мыслить поэтапно, например, этап проектирования, этап разработки и этап тестирования. Гибкая разработка не имеет отдельной фазы тестирования как таковой. Разработчики гораздо более активно участвуют в тестировании, написав автоматические повторяемые модульные тесты для проверки своего кода.





Участие разработчиков в тестировании

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

Тестирование в Agile также означает раннее начало. Это означает, что QA нужно будет задействовать прямо на этапе проектирования, понять особенности и истории, а также заранее начать подготовку и даже написание тестов.

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




Интегрированные и кросс-функциональные команды

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

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

Работа в команде - это главный ключевой момент при переходе от Waterfall к Agile Testing. Компания может принять решение перейти на Agile Testing, но люди должны поддержать это изменение, чтобы добиться успеха.

В Agile нет тестовой команды.




Качественный образ мышления, коллективный подход

Стремитесь к предотвращению дефектов, а не к их обнаружению.

При раннем участии тестировщиков в проекте они могут помочь в определении ключевых сценариев, необходимых для тестирования истории. Довольно часто критерии приемки составляются совместными усилиями Владельца продукта, Разработчика и Тестировщика - Трех Амигос.

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

Все вовлечены и несут ответственность за качество продукта.




Меньше документации, больше сотрудничества

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

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

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

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


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