QA на ранних стадиях разработки

Наличие QA на ранней стадии разработки потенциально позволяет её упростить, путем обнаружения проблем до того, как они выльются в неправильно работающее приложение. Есть ряд активностей, которые могут в этом помочь: 

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

Тестирование прототипа UI имеет те же преимущества. Пример:

  1. Требования были обновлены: в форме регистрации появилось новое поле;
  2. Макет, в свою очередь, обновлен не был;
  3. В ходе разработки пользовательского интерфейса поле просто добавляется в нижнюю часть формы;
  4. Форма регистрации больше не помещается на экран мобильного телефона, а заказчик не хочет прокрутку на странице.

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

Процесс тестирования может быть скорректирован. Например, может оказаться, что для проведения тестирования необходимо лицензировать ПО, написать заглушки (mock-up) или развернуть среду для исполнение автоматизированных тестов.

К сожалению, наличие тестировщика в команде на ранних стадиях имеет и ряд недостатков:

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