Какие знаешь критерии окончания тестирования тест плана?

Критерии окончания тестирования (Test Completion Criteria)

Определение момента, когда нужно остановить тестирование, — это одна из самых важных и часто игнорируемых задач в QA. За 10+ лет работы я видел, как плохо определенные критерии окончания приводили к задержкам релизов или к выпуску низкокачественного кода. Расскажу подробно о правильных критериях.

Почему это важно

Три крайности:

1. Остановить слишком рано: Пропустить критичные баги

   • "Мы протестировали 50% функционала и готовы к production"
   • Результат: Пользователи находят баги в production

2. Продолжить слишком долго: Бесконечное тестирование

   • "Давайте протестируем еще (every edge case)"
   • Результат: Релиз откладывается на месяцы

3. Правильный баланс: Определить ясные критерии

   • "Мы тестировали достаточно, остальное риски известны"
   • Результат: Качественный релиз в сроки

ТОП Критерии окончания тестирования

1. Покрытие Test Cases (80-90%)

Определение: Процент test case'ов, которые успешно пройдены.

Примеры:

• Написано 100 test case'ов
• Пройдено 90 из них ✓
• Осталось 10 failed/blocked → анализ

Как это работает:

• Пройденные → можно закрывать
• Упавшие → либо баги (нужно исправить), либо окружение (нужно пересоздать)
• Blocked → зависимость от другой фичи

Практический пример: Тестировал e-commerce систему:

• Написано 200 test case'ов
• Пройдено 190 (95%) ✓
• 10 failed из-за того, что Admin panel не готов
• Решение: Admin panel будет в следующем спринте, это accepted risk
• Вывод: Готово к release

2. Покрытие требований (100%)

Определение: Каждое требование должно быть протестировано.

Проверка:

• Требование 1: "Пользователь может добавить товар в корзину" → тест Case 1 ✓
• Требование 2: "Корзина показывает итоговую сумму" → test Case 5 ✓
• Требование 3: "Оплата работает с Visa" → test Case 15 ✓

Важно:

• Каждое requirement должно иметь минимум один test case
• Если requirement не протестировано → оно не готово

3. Дефекты критичности High/Critical закрыты (100%)

Определение: Все критичные баги должны быть исправлены.

Классификация Severity:

Critical (блокирует функционал):
- Приложение падает на старте
- Платеж не работает
- БД теряет данные
→ ОБЯЗАТЕЛЬНО исправить перед release

High (серьёзно влияет на функционал):
- Фильтр работает, но очень медленно
- Email не отправляется в половине случаев
- API возвращает неправильное значение
→ Нужно исправить перед release (или документировать как known issue)

Medium (влияет, но есть workaround):
- Кнопка смещена на 5 пикселей
- Сообщение об ошибке не очень понятно
→ Можно отложить на next release

Low (минорные проблемы):
- Typo в тексте
- Неправильный цвет кнопки
→ Можно отложить на next release

Практика:

Все Critical: 0 (закрыты) ✓
Все High: 0 (закрыты или согласованы как known issue) ✓
Medium: 12 (отложены на next sprint) → Ok
Low: 25 (отложены на next sprint) → Ok

4. Code Coverage (80-90% минимум)

Определение: Процент кода, покрытый автоматическими тестами.

Примеры:

• Функция payment_processor() 100 строк кода
• Покрыта unit тестами: 85 строк
• Coverage: 85% ✓

Минимальные требования по линии:

• Unit тесты: 80-90%
• Интеграционные: 60-70% (сложнее писать)
• E2E: critical paths 100%

Итого: Среднее покрытие 70-80% → приемлемо

5. Регрессионное тестирование пройдено (100%)

Определение: Все старые test case'ы на старом функционале должны пройти.

Процесс:

1. До каждого release запустить regression suite
2. Все case'ы должны пройти
3. Если что-то упало → fix или evaluate impact

Примеры:

• Новая фича: Фильтр по цене
• Regression suite: 50 test case'ов на старый функционал
• Все должны пройти ✓
• Если один упал → проверить, это баг в новой фиче или старой?

6. Performance требования выполнены

Определение: Приложение работает с нужной скоростью.

Примеры требований:

• Загрузка страницы: < 2 сек
• API response: < 200ms
• Batch processing: < 1 sec per 100 items
• Mobile app start: < 3 secs

Тестирование:

• Запустить load test на 1000+ пользователей
• Проверить response time
• Если все < target → Ok ✓

7. Security requirements выполнены

Определение: Приложение защищено от базовых уязвимостей.

Проверка:

• Нет SQL injection в inputs
• Нет XSS в user-generated content
• Все passwords зашифрованы
• HTTPS везде
• CSRF protection на POST запросы
• Authentication/Authorization работает
• Нет утечек sensitive данных в логах

8. Известные проблемы документированы

Определение: Все проблемы, которые не будут исправлены, должны быть задокументированы.

Примеры:

Known Issues в v1.0:
1. Safari на iOS 13 не поддерживается (2% пользователей) → Fix в v1.1
2. Отчет с 10000+ строк выполняется 30 сек → нужна оптимизация БД
3. Синхронизация между мобильным и веб иногда запаздывает на 5 сек

Доставить пользователям → они знают о проблемах → нет surprise issues

9. Stakeholder Sign-off

Определение: PM, Product Lead, Business Owner согласны выпускать.

Процесс:

1. QA подготавливает отчет
2. Показывает результаты
3. Документирует известные проблемы
4. Получает approval
5. Если не одобрено → доработать

Реальный пример: Генерировал отчет для CEO перед большим release:

QA Readiness Report

Functionality: 95% тестов пройдено ✓
Performance: Все метрики в target ✓
Security: Базовые проверки пройдены ✓

Known Issues:
- Экспорт в PDF медленный (2 sec для 100 pages) → Ok
- Mobile на старых версиях (iOS < 12) не поддерживается → Ok

Risk Assessment: LOW

Recommendation: GO FOR RELEASE

Sign-off: CEO ✓

Когда НЕ закрывать тестирование

Красные флаги:

1. Много upfront backlog

   • Если осталось 50+ test case'ов не протестировано
   • Если 20% требований не покрыто

2. Много critical/high дефектов

   • Если еще 10+ critical bagов открыто
   • Если 50% test case'ов падают

3. Нет regression тестирования

   • Если не запустили старые test case'ы
   • Если не проверили, что не сломали старый функционал

4. Performance не тестировалась

   • Если нет load test результатов
   • Если нет baseline для сравнения

5. Нет stakeholder sign-off

   • Если PM не знает о known issues
   • Если Business не знает о рисках

Мой процесс определения готовности

За неделю до release:

Чеклист готовности QA:

☐ Написано X test case'ов
☐ Пройдено Y (>90%)
☐ Все требования покрыты
☐ Critical баги: 0
☐ High баги: 0 (или documented as known issue)
☐ Coverage >80%
☐ Regression suite пройдена
☐ Performance тесты пройдены
☐ Security проверки сделаны
☐ Known issues документированы
☐ Отчет подготовлен для stakeholders

За 2 дня до release:

1. Финальный regression run (убедиться, что ничего не сломалось)
2. Проверка на последние minute баги
3. Финальный sign-off от разработчика
4. Финальный sign-off от PM

День release:

1. Smoke тесты перед deploy
2. Post-release sanity tests
3. Мониторинг production на первый час

Особенные критерии для разных типов тестирования

Smoke Testing (быстрая проверка перед дальнейшим тестированием) Критерии завершения:

• Приложение стартует ✓
• Основные экраны загружаются ✓
• Логин работает ✓
• Нет immediate errors ✓

Если хотя бы одно не выполнено → STOP, вернуть на fix

UAT (User Acceptance Testing) Критерии завершения:

• Все acceptance criteria выполнены
• Business stakeholders одобрили
• Нет блокирующих проблем
• Known issues задокументированы

Performance Testing Критерии завершения:

• Load тесты на ожидаемую нагрузку выполнены ✓
• Response time < target ✓
• Error rate < 1% ✓
• Нет memory leaks ✓

Security Testing Критерии завершения:

• Penetration testing пройдено ✓
• OWASP Top 10 проверено ✓
• Compliance требования выполнены ✓
• Security team одобрила ✓

Типичные ошибки при определении окончания

Ошибка 1: Тестировать хаотично без критериев

Плохо: "Мы тестируем, пока не кончится время"

Хорошо: "Мы тестируем пока не будут выполнены эти критерии: покрытие >85%, критичные баги 0, regression пройдена"

Ошибка 2: Критерии слишком высокие

Плохо: "100% code coverage, 0 дефектов, идеально"

Хорошо: "80-90% code coverage, критичные баги 0, medium баги задокументированы"

Ошибка 3: Нет communication со stakeholders

Плохо: "QA говорит release готов, но PM не знает о known issues"

Хорошо: "QA подготавливает отчет, документирует known issues, получает sign-off от PM"

Итог

Критерии окончания тестирования — это не просто чеклист, это:

• Минимальный стандарт качества перед release
• Защита бизнеса от выпуска плохого продукта
• Защита QA от обвинений в том, что мол "ты недостаточно тестировал"
• Ясность для всей команды когда можно остановиться

Мои критерии, которые я использую в 90% проектов:

1. ✓ 90%+ test case'ов пройдено
2. ✓ 100% требований покрыто
3. ✓ 0 critical / 0 high дефектов
4. ✓ 80%+ code coverage
5. ✓ Regression suite 100% пройдена
6. ✓ Performance требования выполнены
7. ✓ Known issues документированы
8. ✓ Stakeholder sign-off получена

Это гарантирует качественный релиз без чрезмерного бюрократизма.