Ответ.

История вопроса:

Проблема достаточности тестов появилась, когда проекты стали большими, а времени — мало. Стало необходимо понимать, что пора останавливать тестирование, чтобы эффективно использовать ресурсы. Тестировщик должен объяснить бизнесу, что протестировано «достаточно», и риски минимальны.

Проблема:

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

Решение:

Использовать метрики покрытия: процент пройденных требований, покрытие кода (если есть доступ), соотношение уникальных сценариев/модулей.
Внедрять практики traceability matrix для соответствия тест-кейсов требованиям.
Проводить совместные ревью тест-кейсов и дефектов с командой.

Ключевые особенности:

Harmonization между требованиями, тест-кейсами и функциональными модулями.
Оценка рисков для постановки приоритетов.
Возможность четко аргументировать, почему тесты завершены.

Вопросы с подвохом.

Можно ли ориентироваться только на покрытие тест-кейсами без учета рисков?

Нет. Нужно учитывать приоритеты функциональности: какие области наиболее критичны для бизнеса.

Всегда ли количество тест-кейсов говорит о качестве покрытия?

Нет. Много необоснованных или дублирующих тест-кейсов — не признак высокого покрытия.

Нужно ли включать в метрику покрытия exploratory testing?

Да, обязательно. Исследовательское тестирование выявляет неожиданные дефекты, которые не нашли формальные тест-кейсы, и оно должно быть частью общей картины покрытия.

Типовые ошибки и анти-паттерны

Ориентация только на формальные показатели, игнорируя важные рисковые зоны.
Сокрытие недостатков покрытия (неучтенные требования, неотработанные сценарии).
Срыв дедлайна из-за стремления "покрыть всё".

Пример из жизни

Негативный кейс

Тестировщик считает покрытие только по количеству тест-кейсов без учета зоны влияния багов или пользовательских сценариев.

Плюсы:

Легко представить красивые отчеты.

Минусы:

Критичные баги могут остаться вне поля зрения.

Позитивный кейс

Тестировщик совместно с аналитиком уточняет риски, корректирует покрытие и акцентирует усилия на наиболее важных компонентах.