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

«Пользователь может войти»: нетестируемый критерий приёмки. «Пользователь с валидными учётными данными перенаправляется на /dashboard в течение 3 секунд; пользователь с невалидными учётными данными видит "Invalid email or password"»: тестируемый. Найти этот разрыв на этапе требований стоит одного разговора; найти его после разработки стоит целого спринта. Статья разбирает что QA-инженеры реально делают на каждом из семи этапов SDLC, где точки максимального влияния и как роль отличается в Waterfall, Agile и DevOps.

Этапы

1. Планирование

Проект оценивается по объёму. Пишутся требования. Ставятся бюджеты и сроки.

Что делает QA здесь: в большинстве команд почти ничего. Это проблема. Лучший вклад QA на планировании: выявить требования к тестируемости заранее. Нужно ли фиче логирование? Доступ к тестовой среде? Возможность сбрасывать состояние? Поднять эти вопросы на планировании стоит часов. Поднять их во время разработки стоит дней. Что должен делать QA: присутствовать на встречах по планированию. Задавать вопрос «как мы узнаем что это работает?» для каждой предлагаемой фичи. Выявлять требования которые неясны или нетестируемы.

2. Анализ требований

Требования уточняются и конкретизируются. Пишутся пользовательские истории. Определяются критерии приёмки.

Что делает QA здесь: ревьюит критерии приёмки на полноту. «Пользователь может войти»: нетестируемо. «Пользователь с валидными учётными данными перенаправляется на /dashboard в течение 3 секунд, пользователь с невалидными учётными данными видит ошибку "Invalid email or password"»: тестируемо. Что должен делать QA: писать тест-кейсы пока требования ещё финализируются, а не после. Поднимать пропущенные граничные случаи. Возражать против размытых формулировок. Именно здесь происходит наиболее ценная работа QA.

3. Проектирование

Проектируется техническая архитектура. Схема базы данных. API-контракты. Структура компонентов. Топология развёртывания.

Что делает QA здесь: ревьюит дизайн на тестируемость. Можно ли тестировать систему в изоляции? Есть ли тестируемые API или всё идёт через UI? Есть ли хуки для логирования и наблюдаемости? Есть ли способ инжектировать тестовые данные? Что должен делать QA: поднимать вопросы тестируемости на ревью дизайна. «У этой фичи нет API, её можно тестировать только через UI, а значит все тесты будут медленными и хрупкими. Можем ли мы добавить API-эндпоинт или хотя бы способ заполнить тестовое состояние?»

4. Разработка

Разработчики пишут код. Фичи строятся.

Что делает QA здесь: пишет тест-кейсы параллельно. Настраивает тестовые окружения. Пишет автотесты для фич по мере их готовности. Фиксирует найденные баги. Что должен делать QA: тестировать фичи инкрементально, а не все сразу в конце. Договариваться с разработчиками что значит «готово к QA». Рассматривать парное тестирование для сложных фич.

5. Тестирование

Фичи завершены и готовы к систематической верификации.

Что делает QA здесь: выполняет тест-кейсы, запускает автоматизацию, проводит исследовательское тестирование, верифицирует исправления багов, проводит регрессионное тестирование неизменённых областей. Что должен делать QA: вести чёткий реестр дефектов. Ясно коммуницировать риски («5 открытых критических багов, рекомендуем не выпускать релиз пока не будут исправлены хотя бы 3»). Не просто находить баги, но помогать расставлять приоритеты и коммуницировать их влияние.

6. Развёртывание

Продукт выходит к пользователям.

Что делает QA здесь: дымовое тестирование в продакшне или staging после деплоя. Мониторинг продакшн-ошибок. Быстрая валидация критического пути. Что должен делать QA: иметь чеклист валидации деплоя. Знать 5–10 тестов которые запускаются сразу после каждого деплоя, чтобы подтвердить что система здорова. Мониторить инструменты отслеживания ошибок в первые часы после релиза.

7. Сопровождение

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

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

Модели SDLC

Waterfall

Все фазы идут последовательно. Требования фиксируются до начала проектирования. Проектирование фиксируется до начала разработки. Тестирование происходит только после завершения разработки.

QA в Waterfall: тестирование оказывается финальной фазой. Это порождает самые дорогие дефекты: баги найденные поздно дорого обходятся при исправлении. Почти никакие современные команды не используют чистый Waterfall.

Agile (Scrum, Kanban)

Работа ведётся короткими итерациями (спринтами). Каждый спринт включает планирование, разработку и тестирование. Фичи выходят инкрементально.

QA в Agile: тестирование происходит внутри спринта, а не после него. QA-инженеры входят в кросс-функциональную команду. Это доминирующая модель в 2026 году для продуктовых команд.

DevOps / Непрерывная поставка

Непрерывная интеграция и непрерывное развёртывание. Изменения кода запускают автотесты и могут попасть в продакшн несколько раз в день.

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

Почему QA-инженерам важно это знать

Знание где ты находишься в SDLC говорит тебе какая QA-работа наиболее ценна прямо сейчас.

На планировании: ревью требований. На разработке: раннее написание тест-кейсов. После деплоя: дымовое тестирование. QA-инженер который умеет только выполнять тест-кейсы на фазе тестирования полезен лишь в одной из семи фаз. QA-инженер понимающий полный SDLC может добавлять ценность на каждом этапе.

Именно поэтому «shift-left» стал доминирующей философией QA: перенести тестирование раньше в SDLC, где это дешевле и даёт больший эффект.