QA в жизненном цикле разработки

Где именно тестировщик встроен в разработку, чем спринт отличается от водопада и почему лучший баг находят до того, как написана первая строка кода.

SDLC (Software Development Life Cycle, жизненный цикл разработки) — последовательность этапов, через которые проходит продукт: сбор требований → проектирование → разработка → тестирование → релиз → поддержка. Модель разработки определяет, как эти этапы расположены во времени — и от этого напрямую зависит, чем занят тестировщик.

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

Waterfall: тестирование как этап в конце

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

Плюсы	Минусы
Понятный план и бюджет, много документации	Дефект требования всплывает через полгода — в самой дорогой точке
Легко принимать работу по подписанному ТЗ	Тестирование зажато между «разработка опоздала» и «релиз не двигается» — сроки съедаются
Работает там, где требования правда не меняются (медицина, авиация, госсистемы)	Обратная связь от пользователя приходит в самом конце — когда менять поздно

У водопада есть важная для нас надстройка — V-модель. Она говорит: каждому этапу проектирования соответствует свой уровень тестирования, и планировать проверки нужно одновременно с проектированием, а не после.

Этап проектирования (левая ветвь V)	Соответствующий уровень тестирования (правая ветвь)
Требования бизнеса	Приёмочное тестирование: то ли мы вообще построили
Системные требования	Системное тестирование: продукт целиком по спецификации
Архитектура, интерфейсы модулей	Интеграционное тестирование: модули стыкуются друг с другом
Детальный дизайн, код	Модульное (юнит) тестирование: отдельная функция или класс

Главная мысль V-модели: приёмочные сценарии пишутся тогда же, когда пишутся бизнес-требования. Это первая историческая попытка сдвинуть тестирование влево — за десятилетия до слова «shift-left».

Agile: тестирование как непрерывная деятельность

В гибких подходах цикл сжимается до одной-двух недель, и все этапы происходят внутри спринта параллельно. Тестировщик перестаёт быть «последним рубежом» и становится участником с первого дня.

Момент спринта	Что делает тестировщик	Какой дефект он ловит
Груминг и планирование	Читает истории, задаёт неудобные вопросы, требует критерии приёмки, оценивает риски	Дыры и противоречия в требованиях — самые дешёвые
Начало спринта, код ещё пишется	Готовит чек-листы и тест-данные, договаривается с разработчиком, что покроют юнит-тесты, а что он проверит сам	Пробелы в покрытии, дубли усилий
Первая готовая часть	Проверяет по кусочкам, не дожидаясь «всей фичи»; исследовательская сессия	Архитектурные ошибки, пока их дёшево менять
Фича собрана	Функциональные проверки, негативные сценарии, граничные значения, регресс затронутых областей	Основная масса функциональных дефектов
Конец спринта, демо	Показывает, что работает; честно называет непроверенное и открытые риски	Ложное ощущение готовности
Ретроспектива	Приносит статистику: где родились баги, что менять в процессе	Причины, а не следствия (это уже QA)

Если из этой таблицы вычеркнуть всё, кроме строки «фича собрана», получится мини-водопад внутри спринта: разработчики отдают всё в четверг, тестировщик героически не спит до пятницы, найденные баги переезжают в следующий спринт. Это самая распространённая болезнь молодых Agile-команд — и, к сожалению, обычная реальность первой работы. Уметь её называть — уже половина лечения.

Shift-left: лучший баг тот, который не написан

Shift-left тестирование — сдвиг активностей по качеству «влево» по оси времени: к требованиям, дизайну и коду, вместо того чтобы копить всё на фазу проверки готовой сборки.

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

Чек-лист тестирования требования

Однозначность. Можно ли понять фразу двумя способами? «Быстрая загрузка» — это 200 мс или 3 секунды?
Полнота. Описаны ли альтернативные и негативные ветки? Что если сервис оплаты не ответил?
Тестируемость. Можно ли придумать проверку, которая покажет «выполнено/не выполнено»? Если нет — требование бесполезно.
Непротиворечивость. Не спорит ли оно с соседней историей или с текущим поведением системы?
Границы. Что на минимуме, максимуме и за пределом? Скидка 0%? 100%? −5%?
Обратимость. Что происходит при отмене, повторе, двойном клике, обрыве сети посередине?
Права. Кто может это делать, а кто нет? Что видит гость?

Как это выглядит на практике

Было (требование из реальной жизни):
  «Пользователь может применить промокод в корзине.»

Вопросы тестировщика на груминге:
  - Промокод и скидка постоянного клиента складываются или берётся бóльшая?
  - Регистр важен? SALE и sale — один код?
  - Что показываем на просроченный код, на несуществующий, на уже использованный?
  - Код одноразовый на аккаунт или вообще одноразовый?
  - Что с кодом, если товар из корзины удалили и сумма стала меньше порога?
  - Промокод сохраняется, если пользователь ушёл и вернулся через час?

Стало (критерии приёмки, формат Given/When/Then):
  1. Given корзина на 2000 руб. и действующий код SALE10 (10%)
     When пользователь применяет код
     Then итоговая сумма 1800 руб., в корзине показана строка «Скидка 200 руб.»

  2. Given у пользователя уже есть персональная скидка 5%
     When он применяет SALE10
     Then применяется только бóльшая скидка (10%), скидки НЕ складываются,
          показано сообщение «Применена лучшая из доступных скидок»

  3. Given код просрочен
     When пользователь применяет его
     Then сумма не меняется, показана ошибка «Срок действия кода истёк»

  4. Given сумма корзины упала ниже порога 1000 руб. после удаления товара
     When код был применён ранее
     Then код автоматически снимается, показано предупреждение

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

Договорённости команды: DoR и DoD

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

Definition of Ready — задачу можно брать в спринт, если…	Definition of Done — задача готова, если…
Есть критерии приёмки	Код написан и прошёл ревью
Описаны негативные сценарии	Есть юнит-тесты, CI зелёный
Есть макет или ссылка на дизайн	Проверены все критерии приёмки
Понятно, как это тестировать (есть доступы, тестовые данные, контур)	Прогнан регресс затронутой области
Нет открытых вопросов к аналитику	Дефекты приоритетов P0/P1 закрыты, остальные заведены и оценены
Задача влезает в спринт	Обновлена документация и тест-модель

Как это работает: с кем и как вы разговариваете

С аналитиком и продактом

Ваш вклад — вопросы к тексту до начала разработки и приоритеты по рискам. Правило вежливости, которое экономит нервы: приходите не с «тут всё непонятно», а со списком конкретных ситуаций и своим предположением. «Я думаю, скидки не складываются — подтвердите?» продвигает дело, «требования сырые» — нет.

С разработчиком

Здесь ломается больше всего карьер, поэтому по пунктам:

Баг — это свойство продукта, а не оценка человека. «Твой код падает» и «при вводе −1 в поле количества сервис возвращает 500» — это две разные профессии.
Договоритесь заранее, кто что покрывает: юнит-тесты на расчёты — за разработчиком, сценарии в интерфейсе — за вами. Иначе одно и то же проверяют дважды, а стык не проверяет никто.
Показывайте баг вживую до заведения тикета, если разработчик рядом: половина «дефектов» рассыпается за минуту (не та ветка, старый кэш, не прогнали миграции).
Просите не «пофиксить», а объяснить причину — это ваш бесплатный источник знаний о том, где ещё искать. Починили гонку в оплате? Значит, такая же гонка вероятна в возвратах.

С DevOps и поддержкой

Тестовые контуры, данные, логи, доступ к мониторингу. Ваша сила растёт ровно настолько, насколько вы умеете смотреть в логи и метрики сами, а не ждать, пока кто-то посмотрит за вас. А поддержка — бесплатный поток информации о том, что реально ломается у людей: раз в спринт зайти к ним и спросить «на что жалуются?» ценнее, чем пара тест-кейсов.

Частые ошибки

Мини-водопад внутри спринта. Всё падает в тест в последний день. Лечится тем, что тестировщик начинает работу вместе со спринтом, а не в конце: чек-листы, вопросы, проверка по частям.
Не читать требования до готовности сборки. Самые дорогие дефекты вы пропускаете именно так — они уже реализованы «правильно».
Роль вратаря. «Я не пропущу этот релиз» — позиция, которая делает вас врагом команды и всё равно ничего не решает: релиз — решение бизнеса. Ваша власть — не запрет, а честно названный риск.
Быть бутылочным горлышком. Если фича не может считаться готовой без ваших трёх дней ручного регресса — виновата не команда, а отсутствие автоматизации и договорённостей о покрытии.
Проверять только починенный баг. После фикса нужен ещё и регресс вокруг: правки ломают соседей чаще, чем кажется.
Молчать на ретроспективе. Вы единственный, кто видит статистику дефектов целиком. Если вы не приносите выводы, процесс не меняется, и следующий спринт будет таким же.

Итоги

В Waterfall тестирование — фаза в конце; спасение — V-модель: проверки планируются одновременно с проектированием.
В Agile тестирование — непрерывная деятельность внутри спринта, от груминга до ретроспективы.
Shift-left — сдвиг качества к началу: тестируем требования, участвуем в ревью, требуем критерии приёмки в формате Given/When/Then.
DoR и DoD — письменные договорённости, которые защищают команду от «а мы думали, оно готово».
С разработчиком говорите про поведение системы, а не про людей; заранее делите зоны покрытия.
Тестировщик не блокирует релиз — он делает так, чтобы решение о релизе принимали с открытыми глазами.