Когда можно считать что тестирование завершено?

Критерии завершения тестирования

Вопрос о том, когда можно считать тестирование завершенным, является критическим для любого QA инженера. Это не просто «когда закончили тесты», а когда мы можем с уверенностью сказать, что продукт готов к релизу.

Основные критерии завершения

1. Плановое тестовое покрытие достигнуто Основной критерий — выполнены все запланированные тестовые случаи. Если план предусматривал 500 тестов, то все 500 должны быть выполнены и документированы. Покрытие функциональности должно соответствовать требованиям: критичные функции — 100%, важные — минимум 95%, остальное — согласно договоренности с командой.

2. Критичные баги устранены Все Critical и Blocker баги должны быть закрыты. High-приоритетные баги закрыты на 95%+. Оставить можно только заведомо известные ограничения, которые задокументированы и согласованы с бизнесом.

3. Регрессионные тесты пройдены Получить зеленый статус от автоматизированных регрессионных тестов. Если была история релизов, то новая версия не должна сломать существующий функционал. Это проверяется набором регрессионных тестов.

4. Согласованные метрики качества Основной инструмент контроля — метрики дефектности:

• Количество найденных багов на 1000 строк кода
• Скорость закрытия багов (trend должен быть вверх)
• Плотность критичных ошибок должна упасть ниже установленного порога

Например, если на начало тестирования было 100 ошибок, а теперь осталось 5 (и все Low priority), это хороший знак.

5. Требования Requirements Traceability Matrix (RTM) Каждое требование должно быть проверено соответствующим тестовым случаем. Если требование не покрыто тестом, это красный флаг. RTM гарантирует, что ничего не упущено.

6. Граничные и исключительные случаи протестированы

• Edge cases (граничные значения) — тестировались
• Error cases (ошибочные сценарии) — обработаны
• Поведение под нагрузкой проверено (если критично)
• Интеграция с внешними системами работает

7. Утверждение от заинтересованных сторон Получено одобрение:

• Product Owner или Business Analyst (функционал соответствует требованиям)
• Разработчики (известны проблемы, которые остались)
• Менеджмент (риск приемлем)

Это критично — нельзя просто взять и релизнуть без согласования.

Процессные критерии

Документирование завершено

• Все тестовые случаи задокументированы
• Составлен итоговый отчет о тестировании (Test Summary Report)
• Известные проблемы и ограничения описаны
• Release Notes содержат информацию об исправленных и известных ошибках

Окружение стабильно

• Тестовое окружение готово и стабильно
• Все тестовые данные подготовлены и верифицированы
• БД откатываются между запусками (если требуется)

Документирование регрессионных тестов

• Создан или обновлен набор автоматизированных регрессионных тестов
• Он будет использоваться для будущих релизов
• Maintenance процесс ясен

Реальные сценарии

Сценарий 1: Все идеально (редко)

• 100% критичной функциональности протестировано
• 0 Critical/Blocker багов
• 2-3 Low баги (minor UX issues)
• Все требования покрыты
• Результат: Go to Production

Сценарий 2: Типичный сценарий

• 95% функциональности протестировано
• 0 Critical bagов, 1-2 High баги (которые фиксятся позже)
• 10-15 Medium/Low багов
• 98% требований покрыто
• Результат: Go to Production с условиями (Known Issues задокументированы)

Сценарий 3: Не готово

• 80% функциональности протестировано
• 5+ Critical багов
• 30+ Medium/High багов
• Много требований не протестировано
• Результат: STOP. Вернуться на разработку

Критическое правило

Тестирование считается завершенным, когда:

1. Выполнены все плановые тесты
2. Критичный функционал работает стабильно
3. Количество и серьезность оставшихся ошибок приемлемы для бизнеса
4. Все заинтересованные стороны дали одобрение
5. Риск выпуска продукта известен и задокументирован

Просто сказать «мы протестировали все» недостаточно. Нужна объективная метрика, достаточное документирование и консенсус всей команды. Тестирование — это искусство найти баланс между качеством, временем и затратами.