5 критериев завершения тестирования ПО: когда пора в релиз

Для кого эта статья:

• Тестировщики программного обеспечения (QA-инженеры)
• Менеджеры по качеству и разработке программного обеспечения

• Студенты и начинающие специалисты в области тестирования ПО

  Вечный вопрос, который мучает каждого тестировщика: «Пора ли отпустить продукт в релиз или нужно ещё потестировать?» 🤔 Этот вопрос не праздный — недостаточное тестирование грозит репутационными потерями, а избыточное — пустой тратой ресурсов и упущенными возможностями на рынке. В этой статье я расскажу о пяти надёжных критериях, которые позволят вам с уверенностью сказать: «Тестирование завершено, продукт готов к выпуску».

Понимание того, когда можно завершить тестирование, — ключевой навык профессионального QA-инженера. На Курсе тестировщика ПО от Skypro вы не только освоите техники тестирования, но и научитесь определять оптимальный момент для релиза продукта. Наши эксперты помогут вам разработать собственную систему критериев завершения тестирования, применимую к любому проекту — от мобильных приложений до корпоративных систем.

Критерии завершения тестирования: когда можно остановиться

Определение момента, когда тестирование можно считать завершённым, — это искусство балансирования между качеством и сроками. Идеального продукта без багов не существует, поэтому нам нужны объективные критерии, позволяющие принять обоснованное решение о готовности продукта к релизу.

Существует пять ключевых критериев, которые помогают определить завершённость тестирования:

• Выполнение тест-плана — все запланированные тест-кейсы выполнены, а их результаты задокументированы;
• Достижение целевого тестового покрытия — код, функциональность и требования покрыты тестами в соответствии с установленными нормативами;
• Соответствие метрикам качества — количество и критичность обнаруженных дефектов находятся в допустимых пределах;
• Соответствие бизнес-требованиям — продукт решает задачи, для которых создавался, и приемлем для заказчика;
• Исчерпание тестовых ресурсов — затраты на продолжение тестирования превышают потенциальную выгоду от обнаружения новых дефектов.

Важно понимать, что эти критерии должны быть адаптированы под специфику каждого проекта. То, что является приемлемым для внутреннего инструмента, может быть совершенно неприемлемо для медицинского оборудования или финансового приложения. 📊

Михаил Черепанов, Lead QA Engineer

В моей практике был проект, где мы разрабатывали платёжную систему для крупного банка. Изначально критерии завершения тестирования были стандартными: 90% тест-кейсов пройдено успешно и отсутствие критических багов. Однако после первого релиза на препроде мы столкнулись с несколькими неочевидными проблемами в редких сценариях использования.

После этого случая мы пересмотрели критерии и добавили обязательное выполнение 100% тест-кейсов для критичных бизнес-путей, а также требование к отсутствию регрессий в течение двух последовательных билдов. Это увеличило время тестирования на 20%, но полностью исключило инциденты на продакшене в течение следующего года. Иногда лучше потратить дополнительную неделю на тестирование, чем потерять миллионы из-за простоя системы.

Для структурирования подхода к завершению тестирования рекомендую использовать следующую матрицу принятия решений:

Категория риска определяется характером приложения и последствиями возможных ошибок. Например, видеоигра может относиться к низкому риску, корпоративный сайт — к среднему, а финансовое приложение — к высокому.

Достаточное покрытие тестами: количественные показатели

Тестовое покрытие — один из ключевых индикаторов достаточности тестирования. Оно помогает оценить, какая часть продукта проверена и где могут скрываться необнаруженные дефекты. Существует несколько типов покрытия, каждый из которых даёт представление о разных аспектах качества:

• Покрытие кода (code coverage) — какой процент исходного кода был выполнен во время тестирования;
• Покрытие требований (requirements coverage) — какая доля функциональных и нефункциональных требований была проверена;
• Покрытие функциональности (functionality coverage) — какой процент функций и возможностей продукта был протестирован;
• Покрытие пользовательских сценариев (user story coverage) — какая доля пользовательских историй и сценариев использования была проверена.

Для разных типов приложений и стадий жизненного цикла продукта приоритетными могут быть разные типы покрытия. В идеале следует стремиться к балансу между ними. 🧪

Хотя 100% покрытие может казаться идеальной целью, на практике это часто нецелесообразно и экономически неэффективно. Для большинства коммерческих проектов достаточным считается следующее покрытие:

При оценке тестового покрытия следует руководствоваться законом Парето: 20% кода обычно отвечает за 80% функциональности, используемой пользователями. Сосредоточьтесь на наиболее критичных компонентах системы и сценариях с высоким риском.

Для измерения покрытия кода можно использовать такие инструменты, как JaCoCo, Istanbul или SonarQube. Они интегрируются с вашей CI/CD-системой и дают наглядное представление о том, какие части кода остаются непокрытыми.

Екатерина Соловьёва, QA Automation Lead

Работая над API платформы для онлайн-образования, наша команда придерживалась стратегии 80% покрытия кода автотестами. После двух месяцев стабильной работы мы решили снизить этот порог до 70%, чтобы ускорить разработку. Уже через три недели мы столкнулись с катастрофой: после очередного релиза система стала терять данные о прогрессе пользователей.

Расследование показало, что проблема возникла в редком сценарии синхронизации данных, который выпал из нашего тестового покрытия после снижения требований. Урон репутации был значительным, и нам пришлось срочно восстанавливать данные из бэкапов и возвращать пороговое значение покрытия на прежний уровень.

Этот опыт научил меня, что экономия на тестировании — это всегда ложная экономия. Теперь для всех критичных путей мы требуем 100% покрытия, и это действительно окупается отсутствием инцидентов.

Метрики качества и допустимый уровень обнаруженных дефектов

Для принятия обоснованного решения о завершении тестирования необходимо опираться на объективные метрики качества. Они позволяют количественно оценить состояние продукта и динамику выявления дефектов. Ключевые метрики, на которые стоит обратить внимание:

• Плотность дефектов — количество обнаруженных дефектов на единицу размера продукта (например, на 1000 строк кода);
• Интенсивность обнаружения дефектов — количество новых дефектов, обнаруживаемых за определённый период времени;
• Соотношение закрытых и открытых дефектов — показатель того, насколько быстро команда решает проблемы по сравнению с темпом их обнаружения;
• Эффективность устранения дефектов — процент успешно закрытых дефектов без возвращения их в работу;
• Распределение дефектов по критичности — соотношение критичных, серьёзных, незначительных и косметических дефектов.

Особое внимание следует уделить интенсивности обнаружения дефектов. Если этот показатель снижается и приближается к нулю, это может свидетельствовать об исчерпании тестового потенциала. Графически это выглядит как S-образная кривая, которая выходит на плато. 📉

Допустимый уровень обнаруженных дефектов зависит от типа продукта и его критичности для бизнеса. Однако существуют общие рекомендации по принятию решения о релизе на основе оставшихся дефектов:

• Критичные дефекты (Blocker, Critical) — должны быть устранены все без исключения;
• Серьёзные дефекты (Major) — допустимо не более 2-3 для некритичных систем и 0 для критичных;
• Незначительные дефекты (Minor) — допустимо разумное количество с планом устранения в следующих релизах;
• Косметические дефекты (Cosmetic) — могут быть отложены, если не влияют на пользовательский опыт.

Важный индикатор готовности продукта — стабилизация числа обнаруженных дефектов. Если в течение 2-3 последовательных тестовых циклов количество новых дефектов стремится к нулю, это сигнал о том, что тестирование приближается к завершению.

Для управления дефектами и отслеживания метрик качества рекомендуется использовать специализированные системы, такие как Jira, Bugzilla или TestRail, которые позволяют автоматически генерировать отчёты и анализировать тренды.

Соответствие требованиям заказчика и бизнес-рискам

Техническое совершенство продукта не гарантирует его успеха на рынке. Ключевой критерий завершения тестирования — соответствие требованиям заказчика и допустимый уровень бизнес-рисков. Этот аспект часто недооценивается техническими специалистами, но именно он определяет, насколько успешным будет продукт с коммерческой точки зрения.

Для оценки соответствия требованиям заказчика необходимо:

• Провести демонстрацию продукта ключевым стейкхолдерам и собрать обратную связь;
• Организовать приёмочное тестирование с участием представителей заказчика;
• Проверить соответствие критериям приёмки, зафиксированным в требованиях;
• Убедиться, что все бизнес-сценарии работают как ожидается;
• Оценить общее впечатление пользователей от взаимодействия с продуктом.

Не менее важно проанализировать бизнес-риски, связанные с выпуском продукта. Для этого используется методология оценки рисков, включающая следующие шаги:

1. Идентификация возможных рисков (технических, операционных, рыночных);
2. Оценка вероятности возникновения каждого риска;
3. Определение потенциального ущерба от реализации риска;
4. Расчёт приоритета риска как произведение вероятности на ущерб;
5. Разработка стратегий митигации для наиболее приоритетных рисков.

Продукт можно считать готовым к релизу, когда все высокоприоритетные риски снижены до приемлемого уровня. При этом важно помнить, что полное отсутствие рисков недостижимо — речь идёт о нахождении оптимального баланса между качеством продукта и скоростью его выхода на рынок. ⚖️

Для принятия взвешенного решения о релизе рекомендуется использовать матрицу оценки рисков:

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

Методы определения достаточности тестирования на практике

Теоретические критерии завершения тестирования необходимо адаптировать к реальным условиям проекта. На практике команды используют комбинацию различных методов для определения достаточности тестирования. Рассмотрим наиболее эффективные подходы:

• Метод прекращения по времени (Time boxing) — тестирование продолжается до истечения выделенного времени, после чего принимается решение о релизе на основе обнаруженных дефектов;
• Метод снижения интенсивности (Defect seeding) — в код намеренно внедряются дефекты, и по соотношению найденных искусственных и реальных дефектов оценивается эффективность тестирования;
• Метод тестирования на основе рисков (Risk-based testing) — ресурсы сосредотачиваются на наиболее рискованных компонентах, и тестирование прекращается, когда риски снижены до приемлемого уровня;
• Метод исчерпания тестов (Test exhaustion) — тестирование продолжается до тех пор, пока не будут выполнены все запланированные тесты и проверены все требования;
• Метод стабилизации дефектов (Defect arrival rate) — тестирование завершается, когда скорость обнаружения новых дефектов падает ниже определённого порога.

На выбор метода влияют такие факторы, как методология разработки, доступные ресурсы, временные ограничения и критичность продукта. Например, для agile-проектов характерен метод time boxing с постоянным мониторингом качества, а для критичных систем часто применяется комбинация методов исчерпания тестов и анализа рисков. 🔄

Для эффективного определения достаточности тестирования рекомендуется использовать несколько методов одновременно и регулярно пересматривать их в соответствии с изменениями в проекте и накопленным опытом.

Практические рекомендации по внедрению критериев завершения тестирования:

1. Определите критерии на этапе планирования — они должны быть зафиксированы в тест-плане и согласованы со всеми заинтересованными сторонами;
2. Регулярно пересматривайте критерии — по мере развития проекта и накопления данных критерии могут требовать корректировки;
3. Автоматизируйте сбор метрик — используйте специализированные инструменты для отслеживания покрытия кода, интенсивности дефектов и других показателей;
4. Проводите ретроспективы после релиза — анализируйте, насколько эффективными были критерии завершения, и учитывайте полученный опыт в будущих проектах;
5. Документируйте исключения — если продукт выпускается с отклонениями от критериев, фиксируйте причины такого решения и связанные риски.

Помните, что определение достаточности тестирования — это итеративный процесс, который совершенствуется с каждым проектом. Не бойтесь экспериментировать с различными методами и адаптировать их под специфику вашей команды и продукта.

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