Тест-план и отчёт о тестировании: что писать и зачем
Два документа, которые новички считают бюрократией, пока не попадают в проект, где их нет. Разберём, что в них действительно нужно, а что можно не писать.
Зачем нужен тест-план
Тест-план отвечает на вопрос «как мы будем это проверять» — до того, как начали. Его ценность не в самом документе, а в разговоре, который приходится провести, чтобы его написать.
Когда вы садитесь описывать, что тестируем и что не тестируем, немедленно всплывают вопросы: а мобильная версия входит? а на каких браузерах? а платёжную интеграцию проверяем на песочнице или на боевой? Каждый такой вопрос, заданный заранее, экономит день.
Обязательные разделы
| Раздел | Что в нём | Почему важен |
|---|---|---|
| Объект тестирования | Что именно проверяем, какая версия | Без этого спорят о границах задачи |
| В объёме / вне объёма | Что проверяем и что не проверяем | Самый ценный раздел документа |
| Подход | Уровни, виды, ручное и автоматизированное | Задаёт ожидания по глубине |
| Окружения | Стенды, браузеры, устройства, данные | Половина недоразумений — отсюда |
| Критерии входа | Когда начинаем: сборка готова, smoke пройден | Защищает от тестирования сломанного |
| Критерии выхода | Когда закончили: кейсы пройдены, критичных нет | Иначе тестирование не кончается никогда |
| Риски | Что может пойти не так и что делать | Показывает зрелость подхода |
| Роли и сроки | Кто что делает и когда | Кому задавать вопросы |
«Вне объёма». Записанное «производительность и локализацию в этот раз не проверяем» превращает потенциальную претензию в осознанное решение команды. Ненаписанное — оборачивается вопросом «а почему вы это не проверили» после релиза.
Чем тест-план отличается от стратегии
Путаница частая, а разница простая. Тест-стратегия — общий подход к тестированию в компании или продукте: какие уровни используем, что автоматизируем, как относимся к рискам. Она живёт годами и меняется редко.
Тест-план — конкретный: на релиз, на функцию, на проект. Он опирается на стратегию и отвечает на вопросы «здесь и сейчас». Их часто объединяют в один документ, и в небольших командах это нормально.
Насколько подробным должен быть план
Ответ зависит от цены ошибки. Для функции в две недели хватит одной страницы: что проверяем, что нет, на чём, когда закончили. Для проекта с интеграциями и деньгами — полноценный документ с рисками и матрицей окружений.
Признак, что план слишком подробный: его никто не читает, а вы обновляете его по два часа в неделю. Признак, что слишком короткий: команда регулярно спорит о границах задачи.
Отчёт о тестировании: что в нём главное
Отчёт читают люди, которые принимают решение о выпуске. Им не нужен пересказ вашей недели — им нужен ответ на вопрос «выпускаем или нет и чем рискуем».
Рабочая структура на одну страницу:
- Вывод в первом абзаце. «Основные сценарии работают, выпускать можно с оговоркой по СБП» — а не в конце после десяти абзацев.
- Что проверено. Коротко: области, окружения, объём.
- Что не проверено и почему. Обязательно. Это не признание слабости, а информация для решения.
- Найденные дефекты. Числом по уровням серьёзности, со ссылками на критичные.
- Риски. Что может выстрелить после релиза и насколько это вероятно.
Про то, как оценивать серьёзность найденного, — в разборе severity и priority.
Метрики: какие имеют смысл
Соблазн — засыпать отчёт цифрами. Проблема в том, что большинство метрик легко подделываются и мало о чём говорят.
- «Найдено 47 багов» — почти бесполезно. Сорок семь опечаток и сорок семь падений оплаты — разные новости.
- «Пройдено 120 из 150 кейсов» — полезно, если понятно, какие 30 остались и насколько они важны.
- «Критичных дефектов: 0, серьёзных: 2» — уже разговор по делу.
- «Дефекты, найденные после релиза» — самая честная метрика качества тестирования, но она про процесс, а не про отчёт к релизу.
Хороший отчёт можно пересказать одним предложением. Если нельзя — он ещё не дописан.
Критерии входа и выхода подробнее
Два раздела, которые чаще всего пишут формально, хотя именно они защищают от бессмысленной работы.
Критерии входа — условия, без которых начинать нет смысла: сборка установлена на стенд, номер версии известен, smoke пройден, тестовые данные подготовлены, требования согласованы. Если они не выполнены, тестирование начинать не нужно — и это нормальный аргумент, а не саботаж.
Критерии выхода — когда мы считаем, что закончили: все запланированные проверки выполнены, критичных дефектов нет, известные дефекты приняты командой, отчёт готов. Без этого раздела тестирование заканчивается не по факту, а по сроку — то есть в момент, когда время вышло.
Критерий выхода «нет открытых дефектов» недостижим почти никогда. Работающая формулировка звучит иначе: «нет открытых дефектов уровня Blocker и Critical, остальные приняты как известные». Это оставляет решение команде, а не превращает релиз в ожидание идеала.
Как это выглядит в жизни
В небольших командах формальные тест-планы часто не пишут — и это нормально, если границы всё равно проговариваются. Тогда роль плана выполняет чек-лист с разделом «не проверяем», а роль отчёта — сообщение в чате перед релизом.
Важен не документ, а два вопроса, на которые кто-то должен ответить: что мы проверяем и когда считаем, что закончили. Если ответы есть — формат вторичен. Если нет — не спасёт и тридцатистраничный план.
Нужен ли тест-план в Agile?
В облегчённом виде — да. Он умещается в несколько строк на спринт: что в объёме, на чём проверяем, когда считаем готовым. Отказ от документа не означает отказ от договорённостей.
Кто пишет тест-план?
Тестировщик или лид тестирования, согласуют с командой. На небольших проектах — тот, кто будет проверять.
Что спрашивают про тест-план на собеседовании?
Обычно перечислить разделы и объяснить критерии входа и выхода. Сильный ответ добавляет: «самый важный раздел — что мы не тестируем, потому что он снимает половину будущих претензий».