Жизненный цикл тестирования
Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.
Зачем эта статья. Тестирование — цикл из пяти фаз: спланировали → спроектировали тесты → выполнили → оценили результат → закрыли итерацию. Стандарт ISO/IEC/IEEE 29119 описывает именно так; ниже — та же логика простым языком.
Play ITЗагрузка интерактивного демо…
Жизненный цикл тестирования
Процесс тестирования как управляемая инженерная деятельность
Тестирование — это строго регламентированный процесс, состоящий из последовательных, взаимосвязанных этапов, каждый из которых имеет чёткие входы, выходы и критерии завершения.
В стандартах, таких как ISO/IEC/IEEE 29119, тестирование рассматривается как жизненный цикл, включающий пять основных фаз:
- планирование и контроль,
- анализ и проектирование,
- реализация и выполнение,
- оценка критериев выхода и отчётность,
- деятельность по завершению тестирования.
Параллельно с ISO 29119 полезно понимать, как модель разработки ПО задаёт ритм проверок — см. таблицу ниже и методологию SDLC.
Модели разработки и момент тестирования
Одна и та же фаза "тестирование" выглядит по-разному в Waterfall, итерациях и Agile. Сводка с акцентом на QA:
| Модель | Когда тестируют | Плюсы для QA | Риски |
|---|---|---|---|
| Каскад (Waterfall) | Отдельная фаза после разработки | Предсказуемые документы, тест-план заранее | Позднее обнаружение дефектов в требованиях |
| V-модель | Каждому этапу разработки соответствует уровень тестов | Прослеживаемость "требование → тест" | Тяжёлая документация, слабая гибкость |
| Итерационная инкрементальная | В конце каждой итерации + регресс прошлого | Ранние прототипы, управляемые инкременты | Пропуски, заложенные в ранних итерациях |
| Спиральная | По виткам, с упором на риски | Глубокий анализ рисков на крупных проектах | Высокие накладные расходы, сложно для малых команд |
| Гибкая (Agile / Scrum) | Непрерывно в рамках спринта | Тесная связь с разработкой, быстрая обратная связь | Мало формальных артефактов — нужна дисциплина в кейсах и DoD |
Пять фаз ISO (ниже в статье) — управленческий каркас: план → дизайн → прогон → отчёт → закрытие итерации.
Замкнутый цикл на итерации (планирование → уточнение критериев приёмки → проектирование тестов → выполнение → отчётность → корректировка) повторяется каждый спринт или релиз.
Оба описания совместимы: ISO — "что должно быть в процессе", итерационный цикл — "как это крутится каждые 2 недели".
Планирование и контроль
На этом этапе формируется стратегия тестирования — документ, определяющий общий подход к обеспечению качества в рамках проекта. Стратегия включает:
- цели и приоритеты тестирования;
- типы и уровни тестирования, которые будут применены;
- выбранные методы (ручные/автоматизированные);
- критерии входа и выхода (entry/exit criteria);
- оценку рисков и распределение ресурсов.
Из стратегии вытекает план тестирования — более детализированный документ, привязанный к конкретному релизу или итерации. Он содержит расписания, ответственных лиц, инструменты, окружения, зависимости и метрики. План тестирования — это живой документ, который корректируется по мере изменения требований или условий проекта.
Контроль осуществляется через регулярный мониторинг прогресса — сколько тест-кейсов выполнено, сколько дефектов открыто/закрыто, соблюдаются ли критерии покрытия, укладываются ли сроки. На основе этих данных принимаются управленческие решения — например, о необходимости расширения покрытия или отсрочке релиза.
Критерии входа и выхода — на примерах
Entry criteria (критерии входа) — когда можно начинать тестирование сборки. Типичные условия:
- сборка собрана и развёрнута на test/staging;
- есть актуальные требования или список изменений в релизе;
- критичные блокеры прошлой итерации закрыты или явно отложены с согласия владельца продукта;
- тестовые данные и доступы выданы.
Exit criteria (критерии выхода) — когда можно рекомендовать релиз (финальное слово часто за владельцем продукта):
- выполнен согласованный набор smoke и регресса по рискам;
- нет открытых дефектов уровня Blocker / Critical (или есть явное исключение);
- известные ограничения задокументированы в release notes.
Пример для интернет-магазина: вход — "ветка release/2.1 на preprod, миграции БД применены"; выход — "оформление заказа и оплата прошли smoke, 0 блокеров, 2 minor с отложением на 2.2".
Критерии фиксируют в тест-плане или в Definition of Done спринта — не "на словах в чате". Шаблоны артефактов — в документации тестировщика.
Анализ требований и проектирование тестов
Анализ требований, описанный ранее, служит основой для проектирования тестовых условий — абстрактных описаний того, что должно быть протестировано (например, "проверка валидации email-адреса при регистрации"). На основе этих условий создаются тест-кейсы — конкретные сценарии с предусловиями, шагами, входными данными и ожидаемыми результатами.
Проектирование тестов использует формальные техники:
- Эквивалентное разбиение — деление входных данных на классы, в пределах которых система должна вести себя одинаково.
- Анализ граничных значений — фокус на значениях на границах допустимых диапазонов (минимум, максимум, чуть ниже/выше границы).
- Таблицы принятия решений — для моделирования логики с множеством условий и действий.
- Сценарии использования — проверка сквозных пользовательских потоков.
Качественный тест-кейс должен быть однозначным, воспроизводимым, атомарным и независимым от других тестов.
Реализация и выполнение
На этапе реализации тест-кейсы преобразуются в исполняемые артефакты:
- для ручного тестирования — в тест-наборы (test suites) в системах управления тестированием (TestRail, Zephyr, qTest);
- для автоматизированного тестирования — в скрипты на соответствующих языках и фреймворках.
Выполнение тестов проводится в контролируемых окружениях, соответствующих цели проверки (dev, staging, pre-prod). Результаты фиксируются — успешные и проваленные тесты, возникшие дефекты, временные метки, логи. При выявлении несоответствия создаётся отчёт о дефекте, структура которого включает:
- краткое название;
- детальное описание и шаги воспроизведения;
- ожидаемое и фактическое поведение;
- окружение (ОС, браузер, версия ПО);
- скриншоты, логи, видео (при необходимости);
- приоритет и серьёзность (severity vs priority).
Оценка критериев выхода и отчётность
Перед завершением тестирования проводится оценка по заранее определённым критериям выхода, например:
- 100 % выполнение критических тест-кейсов;
- отсутствие дефектов блокирующего уровня;
- покрытие требований — не менее 95 %;
- стабильность регрессионного набора (не более 2 % нестабильных тестов).
На основе собранных данных формируется отчёт о тестировании (test summary report), который содержит:
- обзор проведённых работ;
- метрики (количество тестов, покрытие, плотность дефектов, тренды);
- выявленные риски;
- рекомендации по релизу.
Этот отчёт служит основанием для принятия решения о готовности продукта к выпуску.
Завершение тестирования
После релиза проводится ретроспектива — анализ эффективности тестовой деятельности, выявление узких мест, обновление репозиториев тест-кейсов и автоматизированных сценариев. Все артефакты архивируются для будущих аудитов или повторного использования.
Пример цикла тестирования на одном спринте
Рассмотрим фичу "восстановление пароля":
- Планирование — команда фиксирует риски (почта, токены, безопасность), критерии входа и выхода.
- Анализ и проектирование — QA строит набор тестовых условий — валидный email, просроченный токен, повторное использование ссылки.
- Реализация и выполнение: часть сценариев выполняется вручную, часть автоматизируется в API/UI.
- Оценка выхода: закрываются блокеры, проверяется smoke и регресс по авторизации.
- Завершение: обновляют документацию, добавляют lessons learned в шаблоны тест-дизайна.
Этот пример показывает, что жизненный цикл тестирования работает как управляемый конвейер, а не как "один финальный прогон перед релизом".
Артефакты, которые дают реальную управляемость
Для каждой фазы полезно хранить конкретные артефакты:
- тест-стратегия и тест-план;
- карта покрытия требований и трассировка тестов;
- реестр дефектов с severity/priority и статусами;
- сводный отчёт по прогону с метриками и рисками;
- список технического долга по тестированию.
Когда эти артефакты живые и актуальные, менеджер, аналитик и разработчик видят одно и то же состояние качества.
Что чаще всего ломает жизненный цикл
- Критерии входа/выхода неформальные и не зафиксированы.
- Тест-дизайн делается "на лету" уже после разработки.
- Прогоны стартуют без подготовленных данных и окружения.
- Отчётность сводится к "прошло/не прошло" без анализа рисков.
Практический результат таких проблем — непредсказуемое качество релизов и постоянные споры о готовности.
Связанные статьи для углубления
- Классификация видов тестирования — какие уровни и типы проверок включать в цикл.
- Документация тестировщика — шаблоны артефактов и структура баг-репорта.
- Стратегия и пирамида автоматизации — как распределять ручные и автоматизированные проверки.
- Артефакты качества — что хранить как доказательную базу по качеству.
CI/CD-кейс — встраивание фаз цикла в пайплайн
Жизненный цикл тестирования удобно отражается в этапах CI/CD:
- Plan: проверка готовности требований и критериев входа в тикетах.
- Build + Unit: быстрый барьер качества на уровне кода.
- Integration: проверка контрактов сервисов и миграций.
- System/Smoke: валидация ключевого потока на staging.
- Report + Gate: отчёт с рисками и автоматическое решение о релизе.
Так команда получает единый контур: процесс из статьи совпадает с реальным релизным конвейером.
Шаблон артефакта — test summary report
Test Summary Report:
- Release/Build: __________
- Scope: какие модули и сценарии покрыты
- Выполнение: passed __ / failed __ / blocked __
- Критичные дефекты: __ (список ссылок)
- Риски релиза: __
- Рекомендация QA: go / no-go
- Ответственные за риски: __
Такой формат ускоряет решение по релизу и сохраняет историю качества по итерациям.
Готовые поля для Jira и YouTrack
Issue Type: Release / QA Report
Summary: [QA SUMMARY] Итоги тестирования релиза X
Entry Criteria: met / partial / failed
Exit Criteria: met / partial / failed
Coverage: requirements __%, critical scenarios __%
Defects:
- Blocker: __
- Critical: __
- Major: __
Residual Risks: ...
Recommendation: go / no-go / conditional go
Owners for Risks: ...
Пример заполнения:
Issue Type: Release / QA Report
Summary: [QA SUMMARY] Итоги тестирования релиза 3.8.0
Entry Criteria: met
Exit Criteria: partial
Coverage: requirements 94%, critical scenarios 100%
Defects:
- Blocker: 0
- Critical: 1
- Major: 4
Residual Risks: нестабильный сценарий оплаты через 3DS
Recommendation: conditional go
Owners for Risks: backend.lead, payments.pm
Навигация по разделу "Тестирование"
- Маршрут: О разделе · Резюме раздела · Карта уровней и практик (Unit / Integration / UI / E2E, TDD, BDD)
- Теория и процесс: Основы · Классификация · Жизненный цикл · Порядок этапов · Артефакты качества
- Уровни проверок: Unit · Integration · E2E, системное и UI · API · Тестовые дублёры · Покрытие кода · White-box · Мутационное тестирование
- Практика QA: Документация · Тест-дизайн · Ручное веб · SQL
- Автоматизация: Стратегия и пирамида · Каталог инструментов · Selenium · Playwright
- Практикум и углубление: Подготовка среды и создание первого теста · Проверка взаимодействия компонентов · Проверка пользовательского сценария · Проверка надежности под нагрузкой · Мобильное · Нагрузка · Безопасность · Самопроверка · Доп. материалы курса · Инструменты с низким кодом для тестирования · Тестирование нейроморфных систем