Переход от модели "водопада" к Agile-тестированию

Переход от "водопада" (каскадной модели) к гибкому тестированию

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

Как тестирование в Agile сравнивается с тестированием модели Waterfall?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестировщики должны быть уверены в том, что, чем больше они работают, тем более качественный продукт будет поставлен клиенту.