Как заполнить отчёт о тестировании: пошаговый пример

Отчёт о тестировании нужен, чтобы читатель понял, что проверено, какие проблемы остались и на каких данных основан вывод. Его можно составить кратко: важнее конкретная сборка, результаты и ограничения, чем количество страниц.

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

Открыть генератор отчётов QANotes — в нём доступны функциональный и регрессионный отчёты, экспорт в Word и пустые шаблоны.

Начните с типа отчёта и цели

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

Запишите цель до заполнения таблиц. Например: «Проверить оформление заказа с промокодом и убедиться, что скидка корректно отражается в итоговой сумме». Формулировка «Проверить систему» не объясняет границы работы.

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

Укажите систему, сборку и период

Заполните полное и краткое названия системы, идентификатор проекта, релиз и сборку, даты тестирования, автора и статус документа. Версия отчёта и версия приложения — разные вещи: отчёт 1.1 может описывать ту же сборку, если вы уточнили выводы.

В генераторе год и дата подставляются автоматически, версия документа начинается с 1.0. Проверьте их перед экспортом. Если отчёт подготовлен позже прогона, дата документа может отличаться от даты окончания тестирования.

Учебный пример:

Поле	Значение
Система	Учебный интернет-магазин
Идентификатор проекта	SHOP
Сборка	2.8.0-rc3
Период проверок	14–16 октября 2026 года
Стенд	staging, тестовый платёжный сервис
Подготовил	Команда QA

Определите область и ограничения

Опишите, что вошло в проверку: оформление заказа, применение промокода, отмена и пересчёт суммы. Отдельно укажите исключения: реальный эквайринг, нагрузка, мобильные браузеры. Для каждого существенного исключения объясните причину и возможное влияние.

Зафиксируйте окружение и данные: браузеры, конфигурацию, роли пользователей, особенности интеграций. «Проверено на тестовом стенде» недостаточно, если на нём используются заглушки и поведение отличается от продуктивной среды.

Не помещайте в отчёт пароли, токены и персональные данные. Для воспроизведения обычно достаточно описания набора данных и ссылки на разрешённое хранилище.

Заполните подход и критерии завершения

В пункте 2.1 укажите фактически применённые подходы: позитивные и негативные проверки, границы, роли, интеграционные сценарии. Если использовали исследовательское тестирование, кратко опишите область исследования.

В пункте 2.2 сопоставьте критерии начала и окончания с реальностью. Например, требование «нет открытых критических дефектов» нельзя считать выполненным только потому, что все тесты запущены. Если критерий не достигнут, это должно быть видно в выводе.

Критерии полезно согласовать заранее. Не меняйте их задним числом ради удобного статуса: отдельно зафиксируйте согласованное изменение и его причину.

Сведите результаты без двойного учёта

Для функционального отчёта заполните тестовые наборы. В регрессионном перечислите кейсы и их итоговые статусы. В генераторе сводка использует следующие правила:

Passed — проверка завершена успешно.
Failed — получен результат, не соответствующий ожиданию.
Blocked — проверку нельзя завершить из-за препятствия.
Not Run — проверка не запускалась.

Каждый тест учитывается один раз по итоговому статусу. Историю повторных прогонов сохраняйте отдельно по ссылке.

Предположим, запланировано 50 тестов: 40 Passed, 3 Failed, 2 Blocked и 5 Not Run. Тогда выполнено 43 теста, а доля успешных среди выполненных — 40 / 43, примерно 93%. Доля успешных от всего плана — 80%. Это разные показатели; всегда указывайте знаменатель.

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

Свяжите дефекты с проверками

В реестре дефектов укажите идентификатор, понятное описание, ссылку и связь с кейсом. Разделяйте влияние проблемы и очередность исправления: серьёзность и приоритет отвечают на разные вопросы.

Например: «BUG-17: при повторном применении промокода сумма заказа уменьшается дважды; выявлено в TC-12». Такая запись полезнее, чем «скидка работает некорректно».

Если проверяете требования по идентификаторам, добавьте связи с тестами. Наличие теста означает покрытие, но ещё не успешное выполнение требования.

Сформулируйте вывод и следующие действия

Хороший вывод содержит факт, ограничение и действие. Для нашего примера:

На сборке 2.8.0-rc3 выполнено 43 из 50 запланированных тестов. Обнаружен дефект повторного применения промокода BUG-17. Два теста заблокированы недоступностью тестового платёжного сервиса, пять не запускались. Рекомендуется исправить BUG-17, повторить связанные проверки и завершить оставшийся набор перед решением о выпуске.

Не подменяйте этот вывод словами «в целом всё хорошо». Если предлагаете выпуск с ограничениями, назовите конкретный риск, временную меру и ответственного за решение. Итог QA предоставляет основания для решения, а порядок согласования релиза определяется проектом.

Проверьте документ и скачайте Word

Перед экспортом убедитесь, что:

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

В генераторе можно включить или исключить незаполненные разделы. Отсутствие данных о важном риске лучше объяснить словами, а не скрывать раздел. Для широких таблиц пунктов 4 и 5 доступен поворот листа. После скачивания просмотрите Word: длинные строки могут повлиять на разбиение страниц.

Заполнить отчёт или скачать пустой шаблон.

О том, как документация помогает в ежедневной работе, читайте в статье «Зачем тестировщику и проекту документация».