Зачем тестированию нужны контрольные точки
Представьте, что вы начинаете системное тестирование и обнаруживаете, что тестовое окружение не настроено или половина функций ещё разрабатывается. Вы потратите дни впустую, прежде чем сможете провести хоть какое-то осмысленное тестирование. А теперь представьте, что тестирование объявляется «завершённым» без чёткого определения того, что значит «завершённое» — у каждого стейкхолдера будет своё мнение.
Критерии входа и выхода решают обе проблемы. Это контрольные точки (gates), которые определяют, когда фаза тестирования начинается и когда она может завершиться.
Что такое критерии входа?
Критерии входа — это предусловия, которые должны быть выполнены перед началом конкретной фазы тестирования. Они отвечают на вопрос: «Готовы ли мы начать?»
Думайте о критериях входа как о чек-листе у ворот. Если все пункты отмечены, ворота открываются и тестирование начинается. Если пункты не выполнены, команда должна сначала их закрыть.
Типичные критерии входа включают:
- Требования рассмотрены и утверждены
- Тестовое окружение настроено и доступно
- Тестовые данные подготовлены
- Тест-кейсы написаны и прошли ревью
- Билд развёрнут и smoke-тест пройден
- Все блокирующие дефекты с предыдущей фазы исправлены
Что такое критерии выхода?
Критерии выхода — это условия, которые должны быть выполнены, чтобы считать фазу тестирования завершённой. Они отвечают на вопрос: «Закончили ли мы?»
Без критериев выхода понятие «готово» становится субъективным. Один человек может считать, что 80% выполнения тестов достаточно; другой будет настаивать на 100%. Критерии выхода устраняют неоднозначность, устанавливая объективные, измеримые пороговые значения.
Типичные критерии выхода включают:
- Определённый процент тест-кейсов выполнен (например, 95%)
- Нет открытых дефектов критической или высокой серьёзности
- Плотность дефектов ниже согласованного порога
- Все запланированные виды тестирования (функциональное, регрессионное, нагрузочное) выполнены
- Итоговый отчёт о тестировании подготовлен и рассмотрен
Критерии входа и выхода по фазам STLC
Конкретные критерии зависят от фазы тестирования. Ниже представлена подробная справочная таблица.
Модульное тестирование (Unit Testing)
| Критерии входа | Критерии выхода |
|---|---|
| Модуль кода завершён и компилируется | Все модульные тесты проходят |
| Фреймворк для unit testing настроен | Покрытие кода соответствует целевому значению (напр., 80%) |
| Ревью на соответствие стандартам кодирования проведено | Нет критических дефектов в модуле |
Интеграционное тестирование (Integration Testing)
| Критерии входа | Критерии выхода |
|---|---|
| Модульное тестирование завершено (критерии выхода выполнены) | Все кейсы интеграционного тестирования выполнены |
| Модули для интеграции доступны | Дефекты интерфейсов исправлены |
| План интеграционного тестирования утверждён | Поток данных между модулями проверен |
| Тестовое окружение поддерживает интеграцию | Итоговый отчёт подготовлен |
Системное тестирование (System Testing)
| Критерии входа | Критерии выхода |
|---|---|
| Интеграционное тестирование завершено | 95%+ тест-кейсов выполнено |
| Полный билд развёрнут в тестовом окружении | Нет открытых дефектов Critical/High |
| План и кейсы системного тестирования прошли ревью | Все функциональные требования верифицированы |
| Тестовые данные подготовлены | Нефункциональные требования валидированы |
| Матрица трассировки обновлена | Итоговый отчёт утверждён |
Приёмочное тестирование (UAT)
| Критерии входа | Критерии выхода |
|---|---|
| Критерии выхода системного тестирования выполнены | Все сценарии UAT выполнены |
| Окружение UAT воспроизводит продакшн | Бизнес-стейкхолдеры дали sign-off |
| Бизнес-пользователи обучены и доступны | Нет открытых дефектов, блокирующих бизнес-процессы |
| Сценарии UAT утверждены бизнесом | Решение о go-live задокументировано |
Кто определяет критерии?
Критерии входа и выхода не создаются одним человеком изолированно. Они формируются в результате совместной работы:
QA Lead обычно готовит первоначальный вариант критериев на основе опыта и отраслевых стандартов. Затем команда рассматривает и корректирует их. Итоговые согласованные критерии документируются в тест-плане и доводятся до всех стейкхолдеров.
Ключевой принцип: критерии должны быть измеримыми и объективными. «Достаточно хорошее качество» — это не критерий. «Ноль критических дефектов и менее 5 дефектов высокой серьёзности» — это критерий.
Практические примеры
Пример 1: Функция оформления заказа в E-Commerce
Критерии входа для системного тестирования:
- Интеграция с платёжным шлюзом завершена
- Тестовые номера кредитных карт настроены в sandbox
- Процесс оформления заказа развёрнут в staging-окружении
- Тест-кейсы покрывают все методы оплаты (кредитная карта, PayPal, Apple Pay)
Критерии выхода для системного тестирования:
- Все сценарии оформления заказа протестированы в 3 браузерах
- Обработка платежей проверена для всех поддерживаемых валют
- Нет дефектов с серьёзностью Critical или High
- Производительность: оформление заказа завершается менее чем за 3 секунды
Пример 2: Мобильное банковское приложение
Критерии входа для UAT:
- Критерии выхода системного тестирования выполнены
- Окружение UAT использует данные, близкие к продакшн (анонимизированные)
- У бизнес-тестировщиков есть тестовые аккаунты и устройства
- Проверки регуляторного соответствия задокументированы
Критерии выхода для UAT:
- Все 50 сценариев UAT выполнены бизнес-пользователями
- Получен sign-off от Compliance, Operations и Product
- Для всех отложенных дефектов задокументированы workarounds
- Чек-лист go-live заполнен
Что происходит, когда критерии не выполнены?
Когда критерии входа не полностью выполнены, у команды есть три варианта:
- Ждать — отложить фазу до выполнения всех критериев
- Продолжить с рисками — начать тестирование с задокументированными рисками и планом их снижения
- Снять отдельные критерии — формально согласовать пропуск критерия с одобрения стейкхолдеров
Решение должно быть задокументировано. В большинстве организаций продолжение работы с невыполненными критериями требует одобрения менеджера проекта или управляющего комитета.
Когда критерии выхода не выполнены, команда сталкивается с аналогичным выбором: продолжить тестирование, выпустить с известными рисками или продлить сроки.
Лучшие практики
- Определяйте критерии заранее — включайте их в тест-план, а не добавляйте в последний момент
- Делайте критерии измеримыми — используйте числа, проценты и конкретные условия
- Получайте согласие стейкхолдеров — критерии работают только если все с ними согласны
- Пересматривайте и обновляйте — корректируйте критерии по мере развития проекта
- Отслеживайте прогресс — мониторьте метрики критериев выхода ежедневно во время тестирования
- Документируйте отклонения — если критерии были сняты, записывайте кто утвердил и почему
Распространённые ошибки
- Слишком строгие критерии — требование 100% pass rate, когда 95% реалистично
- Слишком мягкие критерии — допуск критических дефектов в продакшн
- Отсутствие документации — устные договорённости забываются
- Игнорирование критериев под давлением — когда приближаются дедлайны, критерии становятся первой жертвой
- Универсальные критерии — разные проекты и фазы требуют разных пороговых значений
Упражнение: определите критерии входа и выхода
Сценарий: Вы QA Lead новой функции в портале для пациентов медицинского учреждения. Функция позволяет пациентам просматривать и скачивать результаты лабораторных анализов в формате PDF. Портал обрабатывает конфиденциальные медицинские данные (регулируется HIPAA).
Ваша задача: Определите критерии входа и выхода для системного тестирования и UAT этой функции.
Учитывайте:
- Что делает этот проект высокорисковым?
- Какие критерии, связанные с безопасностью, должны быть включены?
- Какие требования compliance влияют на критерии?
- Насколько строгим должен быть порог дефектов?
Запишите критерии в формате таблицы для каждой фазы.
Подсказка
Подумайте об уникальных аспектах медицинского ПО:
- Соответствие HIPAA требует журналов аудита и контроля доступа
- Точность медицинских данных критична (неверные результаты анализов могут навредить пациентам)
- Генерация PDF должна быть протестирована на целостность данных
- Security testing (тестирование на проникновение, контроль доступа) должно быть критерием входа или выхода
Решение
Системное тестирование — Критерии входа
| # | Критерий |
|---|---|
| 1 | Интеграция результатов анализов с backend API завершена |
| 2 | Модуль генерации PDF развёрнут и функционирует |
| 3 | Тестовое окружение настроено с логированием, совместимым с HIPAA |
| 4 | Тестовые данные содержат анонимизированные, но реалистичные результаты анализов |
| 5 | Тест-кейсы безопасности (контроль доступа, шифрование) прошли ревью |
| 6 | Чек-лист соответствия HIPAA доступен |
| 7 | Smoke-тест пройден на текущем билде |
Системное тестирование — Критерии выхода
| # | Критерий |
|---|---|
| 1 | 100% тест-кейсов критического пути выполнено (просмотр, скачивание, печать) |
| 2 | 95% общего выполнения тест-кейсов |
| 3 | Ноль открытых дефектов Critical или High |
| 4 | Security testing завершено: несанкционированный доступ невозможен |
| 5 | Содержимое PDF совпадает с записями в базе данных (целостность данных подтверждена) |
| 6 | Журнал аудита фиксирует все обращения к результатам анализов |
| 7 | Производительность: PDF генерируется за 5 секунд или менее |
UAT — Критерии входа
| # | Критерий |
|---|---|
| 1 | Критерии выхода системного тестирования выполнены |
| 2 | Окружение UAT использует данные, приближённые к продакшн (анонимизированные реальные записи) |
| 3 | Клинический персонал и представители пациентов обучены |
| 4 | Ответственный за compliance доступен для проверки |
| 5 | Сценарии UAT утверждены медицинской и compliance командами |
UAT — Критерии выхода
| # | Критерий |
|---|---|
| 1 | Все сценарии UAT выполнены клиническим персоналом |
| 2 | Пользовательские сценарии проверены представителями пациентов |
| 3 | Sign-off ответственного за compliance по требованиям HIPAA |
| 4 | Ноль дефектов, которые могут привести к отображению некорректных медицинских данных |
| 5 | Требования доступности проверены (WCAG 2.1 AA) |
| 6 | Решение go/no-go задокументировано с подписями всех стейкхолдеров |
Почему эти критерии уместны:
- Строже, чем для типичных проектов, из-за регулирования HIPAA и безопасности пациентов
- 100% выполнение на критических путях (не только 95%), потому что точность медицинских данных не подлежит компромиссу
- Включают специфические критерии выхода по compliance, которые стандартным проектам не нужны
- Требуют явного sign-off от клинических стейкхолдеров и специалистов по compliance
Ключевые выводы
- Критерии входа предотвращают преждевременное начало; критерии выхода предотвращают преждевременное завершение
- Критерии должны быть измеримыми, задокументированными и согласованными со стейкхолдерами
- Разные фазы STLC требуют разных критериев
- Регулируемые отрасли требуют более строгих и специфичных критериев
- Когда критерии не могут быть выполнены, документируйте отклонение и получите формальное одобрение