Жизненный цикл ПО с точки зрения QA⁠⁠

Всем привет!

Сегодня поговорим о том, как выглядит жизненный цикл по с точки зрения QA

Можно долго рассуждать о том, что есть разные модели доставки ПО, такие как waterfall, increment, и другие.

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

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

Потому что чем раньше фича начнет рассматриваться QA специалистом, тем дешевле будет исправлять ошибки. Это можно назвать “стоимостью устранения бага”, чем дальше по циклу разработки заходит фича - тем дороже фиксить возникающие баги, а если баг находится в самой бизнес-логике фичи? - тогда стоимость будет просто колоссальная (но все же ниже, чем если баг обнаружится уже в продакшене)

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

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

Для примера ниже график из отчета Национального института стандартов и технологий (NIST) помогаем визуализировать сравнительную стоимость фикса одного и того же бага на разных стадиях разработки