Ответ.

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

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

С развитием проектов объем тестируемых функций растет, ручное покрытие всех сценариев остается невозможным. С появлением Agile/инкрементальной разработки роль определения scope значительно возросла.

Проблема

Если границы тестирования размыты, появляется риск:

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

Решение

Scope тестирования должен определяться на основании:

бизнес-приоритетов, пользовательских сценариев и рисков
анализа требований, пользовательских историй и спецификаций
консультаций с командой (аналитики, продуктовые менеджеры, разработчики)

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

Фокусирование на главных функциях и рисковых зонах
Явная фиксация/документирование охвата в тест-плане, чтобы избежать недоразумений
Возможность быстро пересмотреть scope при изменении требований

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

Всегда ли нужно тестировать абсолютно все, что реализовано, даже самые мелкие детали?

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

Может ли тестировщик самостоятельно расширять или сужать scope, когда возникли новые требования без согласования?

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

Достаточно ли полагаться только на техническую документацию для определения scope?

Нет, нужно принимать во внимание и бизнес-контекст, реальные пользовательские задачи, обратную связь от заказчика.

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

Scope не зафиксирован и постоянно меняется
Игнорирование бизнес-приоритетов в пользу второстепенных функций
Отсутствие коммуникации между участниками команды при изменении границ тестирования

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

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

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

Плюсы:

Формально протестировано много сценариев

Минусы:

Критические блокирующие баги остаются незамеченными за счет распыления внимания
Срыв сроков из-за неоправданно большого объема тестирования

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

В начале спринта тестировщик участвует в планировании, фиксирует scope вместе со всей командой, акцентируя внимание на самых важных пользовательских сценариях, согласует объем работ и документирует его в Confluence.