До выпуска два дня. Вы третий день проверяете оплату бонусами, и в четверг выясняется: в тот же выпуск попала правка доставки, а смотреть её никто не стал — вы считали задачу чужой, разработчик думал, что посмотрите вы. Менеджер спрашивает, можно ли выпускать, а ответить нечем: по какому признаку работа закончена, никто не договаривался. Записанная договорённость о границах проверки и называется тест-планом.
Слева план решает, что вообще берут в проверку: три пункта проходят воронку объёма, два честно остаются за границей. Дальше две пары створок — признаки, по которым видно, что прогон можно начинать и что он закончен. Внизу риск, сработавший ещё до прогона: граница объёма поехала, и это решение плана, а не сюрприз в последний день.
Что проверяем — и что честно не проверяем
«Проверяем оплату бонусами» звучит как ответ, но не решает ни одного спора: это и списание, и возврат при отмене, и нулевой баланс. Объём пишут двумя списками, и второй важнее: что берём — и что в этот раз сознательно не берём, с одной строкой почему. Строка «оплату картой не трогаем, код не менялся» превращает будущее упущение в согласованное решение и ловит ошибку планирования: разработчик отвечает «вообще-то я там поправил округление» — и граница двигается в понедельник, а не в пятницу. «Тестируем всё» — не граница, а её отсутствие.
На чём проверяем: стенд, сборка, данные, заглушки
Двое проверяют одну функцию: у одного работает, у другого нет, и полдня уходит на выяснение, что они были на разных сборках. Поэтому в плане пишут не «на тестовом», а конкретно: адрес стенда и кто ещё им пользуется; номер сборки — без него отчёт «18 пройдено, 2 упали» не к чему привязать, да и баг-репорт без него не воспроизведут; нужные данные и откуда они возьмутся. Отдельной строкой — что заменено заглушкой: платёжный шлюз в тестовом контуре обычно не настоящий, письма уходят в служебный ящик. Без этой строки кто-нибудь двадцать минут ждёт письмо, которого не будет никогда.
Критерий входа и критерий выхода
Сборка пришла, вы бросились проверять, половина падает — а через час выясняется, что сервис бонусов на стенде не поднялся. Чтобы не тратить дни на заведомо неготовое, в плане держат критерий входа: сборка развёрнута, smoke зелёный, данные есть. Не работает вход — прогон приостанавливают, иначе получите двадцать красных отметок по одной причине; признак возобновления пишут там же: «вход починили, сборка 4.19, smoke зелёный».
Критерий выхода отвечает, когда мы закончили, и портят его чаще всего: на «протестировать всё» нельзя ответить «да» или «нет», и работу останавливает не критерий, а пятница. Проверяемый собирают из трёх частей: список закончился («все 18 проверок из сьюта „Оплата бонусами“»), открытых блокирующих дефектов нет, по остальным есть решение команды. Слово «блокирующих» тут ключевое: «никаких открытых дефектов» на живом продукте недостижимо, и от такого критерия быстро отказываются целиком. «Пройдено 90 %» не годится: число молчит, какие десять процентов остались, — а если в них была оплата, оно не значит ничего.
Риск: что ещё не случилось, но сломает план
Раздел «риски» заполняют формально: «сжатые сроки» — и дальше. Но риск — это будущее событие, а текущая проблема уже факт. Пишут его тройкой — что случится, чем ударит, что делаем заранее: «данных для отмены нет; потеряем полдня прогона; запрашиваем в понедельник». Без последней части остаётся жалоба. Сработавший риск двигает границу объёма: данных нет — отмена уезжает в следующий выпуск вместе с критерием выхода. Это и показано на анимации.
План на одну задачу целиком
На обычной задаче план — несколько строк в её описании; отдельный документ нужен, когда участников несколько или в выпуск попали задачи разных команд.
- Задача: BON-7 «бонусами оплачивается не больше половины суммы, 1 бонус = 1 ₽».
- Проверяем: списание, частичное списание, ограничение «не больше половины», возврат при отмене.
- Не проверяем: оплату картой — код не менялся; отчёты в админке — их берёт вторая команда.
- Где: стенд
staging-2, сборка 4.18, покупатель с балансом 500 бонусов, шлюз — заглушка. - Кто: проверки — я, со вторника; данные для отмены готовит команда данных к понедельнику; выпуск разрешает менеджер выпуска.
- Начинаем: сборка на стенде, оформление заказа работает.
- Заканчиваем: 18 проверок пройдены, блокирующих нет, по остальным есть решение.
- Риски: данных может не быть — если к среде нет, отмена уезжает в следующий выпуск.
Меняться плану нормально, менять молча — нет: правка идёт вместе с тем, что поменялось и с кем согласовано.
Тест-сьют и прогон
Проверяет не план, а конкретные тест-кейсы. Когда их больше десятка, кейсы заранее складывают в тест-сьюты — наборы под цель прогона: по функции, по цели (smoke, регресс), по приоритету. Один кейс может лежать сразу в нескольких сьютах. Прогон — это сьют плюс сборка плюс отметки: пройден, не пройден, заблокирован. Последнее не равно «не пройден»: кейс пройти было нечем, это незакрытая работа, а не дефект, — иначе отчёт врёт в обе стороны. Главная грабля со сьютами — собрать один раз и не трогать: регресс образца прошлого года гоняет сорок кейсов про старую корзину и ни одного про бонусы, поэтому сьют пересматривают после каждой крупной задачи.
Коротко
- Тест-план — договорённость о границах, а не бумага для архива; половину пользы даёт разговор, пока его пишут.
- Объём пишут двумя списками, и второй важнее: «что не проверяем» превращает пропуск в согласованное решение.
- Критерий выхода проверяется за минуту: список закончился, блокирующих нет, по остальным есть решение. «Тестируем всё» и «90 %» не подходят.
- Риск пишут тройкой: что случится, чем ударит, что делаем заранее; сработавший риск двигает границу объёма.
- Прогон — сьют плюс сборка плюс отметки; «заблокирован» и «не пройден» — разные строки отчёта.
Что почитать дальше
- Как писать тест-кейс — из чего состоят проверки, которые план считает списком.
- Отчёт о тестировании и метрики — другой конец работы: что проверили и что вышло.
- Оценка трудозатрат — откуда берутся сроки, которые план обещает.
- Тест-менеджмент: TestRail, Qase, Zephyr — где живут сьюты и прогоны.