Переход от водопада к гибкому тестированию
Когда компания решает перейти от Waterfall к Agile-тестированию, на каких наиболее важных областях следует сосредоточиться для эффективного Agile-тестирования?
Как тестирование в Agile сравнивается с тестированием модели Waterfall? Какой набор действий важно знать и делать тестировщикам?
Тестирование в процессе разработки
Первое, что нужно понять, это то, что в гибкой разработке тестирование интегрировано на протяжении всего жизненного цикла; непрерывное тестирование программного обеспечения на протяжении всего процесса его разработки.
В традиционной модели Waterfall тестирование требует больших усилий и остается ближе к концу разработки, тогда как в Agile тестирование небольшое, но более частое и происходит на протяжении всего процесса разработки.
Тестирование на протяжении всего процесса разработки также означает, что программное обеспечение находится в состоянии готовности к выпуску на протяжении всего процесса разработки, поэтому его можно отправить в любое удобное время.
В модели Waterfall нас учат мыслить поэтапно, например, этап проектирования, этап разработки и этап тестирования. Гибкая разработка не имеет отдельной фазы тестирования как таковой. Разработчики гораздо более активно участвуют в тестировании, написав автоматические повторяемые модульные тесты для проверки своего кода.
Участие разработчиков в тестировании
С помощью автоматических модульных тестов тестирование можно проводить как часть сборки, обеспечивая правильную работу всех функций при каждом создании сборки. Имея прочную основу в виде хорошего покрытия модульными тестами, разработчики также будут более уверенно рефакторировать код.
Тестирование в Agile также означает раннее начало. Это означает, что QA нужно будет задействовать прямо на этапе проектирования, понять особенности и истории, а также заранее начать подготовку и даже написание тестов.
Еще одним важным аспектом является автоматизация тестирования, позволяющая выполнять тесты непрерывно по мере разработки продукта. Это не только модульные автоматизированные тесты, но и автоматизированные тесты API и пользовательского интерфейса.
Интегрированные и кросс-функциональные команды
Переход на Agile - это работа кросс-функциональной проектной команды. Эти совместные усилия не ограничиваются тестированием. Разработчики должны помогать с тестированием фреймворков и создавать функции, бизнес-аналитики помогают с уточнением истории.
Каждый член команды работает над историей, пока вся история не будет готова, то есть разработана и протестирована. Дизайнеры, разработчики и тестировщики работают вместе параллельно, поэтому достигают общей цели, и все они должны знать, что необходимо для ее выполнения.
Работа в команде - это главный ключевой момент при переходе от Waterfall к Agile Testing. Компания может принять решение перейти на Agile Testing, но люди должны поддержать это изменение, чтобы добиться успеха.
Качественный образ мышления, коллективный подход
Стремитесь к предотвращению дефектов, а не к их обнаружению.
При раннем участии тестировщиков в проекте они могут помочь в определении ключевых сценариев, необходимых для тестирования истории. Довольно часто критерии приемки составляются совместными усилиями Владельца продукта, Разработчика и Тестировщика - Трех Амигос.
Это гарантирует, что все, что создается, можно протестировать и понять все заинтересованные стороны. Кроме того, по мере того, как все больше людей участвует в определении критериев приемки и «Определения готового», ошибки можно исправить раньше, и в конечном итоге правильный продукт будет построен правильно.
Все вовлечены и несут ответственность за качество продукта.
Меньше документации, больше сотрудничества
В Agile-разработке больше внимания уделяется разговору и сотрудничеству для уточнения требований, чем традиционному подходу к спецификациям и документации.
Несмотря на то, что требования могут быть до некоторой степени прояснены в гибкой разработке, требования все же могут быть неоднозначными и неполными, а члены команды могут иметь разное понимание требований.
Итак, что это значит для гибкого тестировщика? Обычно тестировщиков, переходящих на гибкую разработку, беспокоит то, что они не знают точно, для чего тестируют. У них нет подробной спецификации для тестирования, так как же они могут ее проверить?
Чтобы начать тестирование, вам не нужна подробная документация. Часто достойные тестировщики могут использовать свое суждение и здравый смысл для проверки продукта. Знание предметной области становится критически важным.
Тестировщики должны быть уверены, что они будут работать больше, исходя из собственных знаний о том, как выглядит хорошее. Это, конечно, не просто следование сценарию тестирования, чтобы убедиться, что программное обеспечение выполняет то, что указано в спецификации.
