Когда проверок мало, их держат в голове. Когда их сотни, а команда не одна, нужен порядок. Два инструмента порядка — тест-план (что, как и в какие сроки тестируем) и тест-сьют (сгруппированный набор тест-кейсов).

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

Что такое тест-план

Тест-план — это документ, который отвечает на вопросы «что мы тестируем, как, кто и когда». Он не про конкретные шаги (это кейсы), а про общую картину. Обычно в нём есть:

  • Что тестируем (scope). Какие функции входят в проверку, а какие — нет. Например: «проверяем оформление и оплату заказа; доставку в этот раз не трогаем».
  • Как тестируем. Каким образом и на чём: браузеры, устройства, ручное или автоматизированное, какие виды.
  • Критерии готовности. Когда считаем, что протестировали достаточно: например, «все критичные кейсы пройдены, открытых блокеров нет».
  • Риски и сроки. Что может пойти не так, сколько времени закладываем.
  • Кто что делает. Роли и ответственность, если тестировщиков несколько.

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

Что такое тест-сьют

Тест-сьют (test suite) — это просто набор тест-кейсов, объединённых по смыслу. Кейсов много, поэтому их складывают в сьюты, как файлы в папки.

Группируют обычно:

  • По функции: сьют «Регистрация», сьют «Корзина», сьют «Оплата».
  • По цели прогона: сьют «Smoke» (быстрая проверка, что живое), сьют «Регресс» (полная проверка перед релизом).
  • По приоритету: сьют критичных проверок, которые гоняют всегда.

Пример: перед релизом вы запускаете сьют «Регресс. Оплата» — и проходите все кейсы про оплату разом, ничего не забывая.

Тест-ран: прохождение сьюта

Когда вы берёте сьют и проходите его на конкретной сборке, отмечая по каждому кейсу результат (прошёл / не прошёл / заблокирован) — это тест-ран (test run), прогон. Один и тот же сьют прогоняют много раз: на каждой новой версии — свой ран.

По результатам рана видно картину: «из 40 кейсов 35 прошли, 3 упали (заведены баги), 2 заблокированы». Это уже понятный отчёт для команды — можно ли выпускать. Хранят и запускают раны в системах тест-менеджмента.

Зачем всё это, если можно «просто потестить»

Соблазн новичка — открыть продукт и тыкать без плана. На маленькой задаче так и делают (разведочное тестирование полезно). Но на продукте побольше без организации начинается хаос: непонятно, что уже проверено, а что нет; при регрессе половину забывают; при передаче задачи коллеге всё приходится объяснять на словах.

Тест-план и сьюты решают это: работа становится видимой и повторяемой. Любой в команде видит, что покрыто, а что нет, и может пройти проверки без автора.

Где это применяется

На реальном проекте вы почти всегда работаете внутри чьего-то плана и сьютов: берёте сьют «Регресс», прогоняете, отмечаете результаты, заводите баги на упавшее. Со временем начнёте сами группировать кейсы и предлагать, что войдёт в регресс. Умение организовать проверки отличает того, кто «тыкает», от того, кто системно закрывает качество.

Где спотыкаются начинающие:

  • Тестируют без плана даже там, где он нужен — и в итоге что-то забывают проверить, а что-то проверяют по три раза.
  • Не отмечают результаты прогона. «Вроде всё прошёл» — это не отчёт. Команде нужны цифры: сколько прошло, сколько упало.
  • Сваливают все кейсы в одну кучу без группировки — и не могут быстро собрать нужный набор под регресс или smoke.

Что учить дальше. План и сьюты — про организацию. А как придумывать сами кейсы умно, чтобы их было не слишком много и они ловили баги, — это техники тест-дизайна.