Тест-план отвечает на вопрос «что и как будем проверять» — до начала работы. У него есть зеркальный документ с другого конца цикла: отчёт о результатах тестирования отвечает на вопрос «что проверили и что получилось». Планирование и отчётность связаны в кольцо: без внятного плана непонятно, кому что делать; без честного отчёта о сделанном невозможно построить следующий план. Разорвётся одно звено — начинает сыпаться весь процесс.
«Всё нормально» — это не отчёт
Представьте, что заказчик спрашивает, как дела с тестированием. Ответ «в целом всё хорошо» не говорит ничего: это субъективное ощущение, которое может быть сколь угодно далеко от реальности. Сравните: «Реализовано 79 % требований, в том числе 94 % важных; за последние три итерации покрытие выросло с 63 % до 71 %, прохождение кейсов — с 85 % до 89 %. Идём по плану». Вторая версия — это факты и числа, по которым можно принимать решения.
Числа для таких ответов дают метрики — числовые характеристики качества и прогресса. Самые ходовые считаются просто:
- Прохождение тест-кейсов — сколько процентов выполненных кейсов прошло успешно.
- Выполнение тест-кейсов — сколько процентов запланированных кейсов вообще выполнено.
- Покрытие требований — сколько процентов требований проверяется хотя бы одним кейсом.
- Устранение дефектов — сколько процентов найденных багов починено (обычно смотрят в разрезе важности: для критических на финальной стадии ждут 100 %).
Многое из этого трекеры и системы тест-менеджмента считают автоматически, вместе с динамикой во времени — а динамика часто важнее текущего значения: покрытие 71 % «выросшее с 63 %» и покрытие 71 % «упавшее с 80 %» — очень разные новости.
Одна ловушка: метрики ради метрик. Инструмент собирает кучу данных, строит десятки графиков — а как их трактовать, никто не знает. У каждой метрики, которой пользуется команда, должно быть короткое руководство: что это число значит и при каком значении пора беспокоиться.
Из чего состоит отчёт
Единого стандарта нет — форм отчётов десятки. Универсальный каркас такой:
- Краткое описание (summary). Главные достижения, проблемы, выводы и рекомендации — так, чтобы очень занятой человек, прочитав один абзац, получил полное представление. Не путайте с кратким описанием баг-репорта: название одно, содержание и принципы разные.
- Описание процесса — что делали за отчётный период: какие билды, какие виды тестирования, что вручную, что автоматизировано.
- Статистика по дефектам — новые и накопленные, в разрезе статусов и важности; обычно таблицей и графиком.
- Рекомендации — что предлагаете сделать.
- Приложения — значения метрик и их динамика.
Логика: выводы → рекомендации → обоснование → факты
Самая ценная часть отчёта — выводы и рекомендации, и у них есть строгая логика: выводы строятся на основе целей из плана, дополняются рекомендациями, и то и другое обосновывается, а обоснование опирается на факты.
Выводы должны быть краткими, информативными и полезными:
- Плохо: «Результаты обработки файлов с множественными кодировками оставляют желать лучшего». Хорошо: «Обнаружены серьёзные проблемы с библиотекой распознавания кодировок (см. BR-834)».
- Утверждениям вроде «некоторые тесты прошли на удивление хорошо» или «часть команды была в отпуске, но мы справились» в отчёте не место вовсе: из них не следует никакого решения.
Рекомендации должны быть краткими, реально выполнимыми и оставлять пространство для решений. «Использовать механизм обработки слов, аналогичный используемому в Google» — не рекомендация: её нельзя выполнить. «Заменить проблемную библиотеку аналогом (требует исследования) или написать своё решение (надёжно, но долго)» — рекомендация: понятны варианты и их цена.
Обоснование отвечает на вопрос «почему мы так считаем». Сравните: «покрытие требований достаточно» и «покрытие вышло на достаточный уровень: 63 % при заявленном минимуме 60 % для текущей стадии». Второе не вызывает вопроса «а с чего вы взяли?».
Где это применяется
Даже если формальный отчёт пишет лид, отчитываться словами и числами приходится каждому: на летучке, в чате, в комментарии к релизу. Разница между «вроде всё окей» и «выполнено 92 % кейсов, два критических бага в работе, к пятнице успеваем» — это разница между ощущением и информацией. Второму человеку можно доверить решение, первому — нет.
Где спотыкаются начинающие:
- Отчитываются ощущениями — «всё хорошо», «есть проблемки». Стройте ответ на числах, которые уже есть в трекере.
- Приносят числа без трактовки. «Прохождение 78 %» — это хорошо или плохо? Без порога и динамики число бесполезно.
- Пишут рекомендации-пожелания («нужно больше внимания качеству»), по которым нельзя действовать. Рекомендация — это варианты действий с их ценой.
Что учить дальше. Отчёт опирается на план — если ещё не читали, начните со статьи про тест-план. Статистика дефектов приходит из трекера, а числа кейсов — из систем тест-менеджмента. Как оценить работу до её начала — в статье про оценку трудозатрат.