Как оформляется отчет по тестированию и фиксируются результаты
Что проверяют
Умеете ли вы превратить результаты прогона в документ, по которому примут решение о релизе, а не просто выгрузить таблицу из системы управления тестами. Следом спрашивают, что вы напишете, если открытые баги остались, а релиз завтра.
Как отвечать
Разделите два уровня фиксации.
Результаты по ходу работы:
- прогоны (test runs) в TestRail, Qase, Test IT, Zephyr или Xray: у каждого кейса статус passed, failed, blocked, skipped и привязка к сборке и окружению;
- дефекты в баг-трекере со ссылкой из упавшего кейса: шаги, ожидаемый и фактический результат, логи, скриншоты;
- автотесты: Allure Report с историей, вложениями и разбивкой по фичам, результаты из CI попадают в систему управления тестами автоматически.
Итоговый отчёт (в ISO/IEC/IEEE 29119 это отчёт о статусе или о завершении тестирования) короткий, на одну или две страницы:
- что тестировали: версия сборки, окружение, объём, что осознанно не проверяли и почему;
- цифры: сколько кейсов выполнено, прошло, упало, заблокировано, не запускалось;
- дефекты: найдено и исправлено за цикл, открытые по серьёзности, отдельно блокеры и критичные со ссылками;
- риски и отклонения от плана: не успели нагрузочное, стенд лежал два дня, поменялись требования;
- вывод: выпускать, выпускать с оговорками или не выпускать, с обоснованием.
Формат подстраивайте под читателя: разработчикам нужны ссылки на баги, продакту вывод и риски в первом абзаце.
Где спотыкаются
Отчёт без вывода. Сорок строк статистики, и читатель сам гадает, можно ли выпускать.
Показывают «98% тестов пройдено» без контекста. Если упавшие 2% это оплата, выпускать нельзя, а если прогнали половину плана, процент ничего не значит.
Не указывают версию сборки и окружение. Через месяц такой отчёт не сопоставить ни с релизом, ни с жалобой пользователя.