Search
  • Marinka Shevchenko

Test Summary Report



ПОЧЕМУ МЫ НАПИСАЛИ ЭТУ СТАТЬЮ?

   

После проведения Test UA Startups уже в 6 раз (как для джунов, так и для участников мидл+) мы заметили, что Test Summary Report является самой трудной частью соревнования. Некоторые команды даже не беруться пробовать написать его, а кое-кто даже подходил к нам после ивента с просьбой дать темплейт.


Поскольку отчет составляется с учетом специфики проекта и ожиданий / требований заказчика, мы остановимся на главных вопросах, направленных на формирование общего понимания Test Summary Report: зачем он нужен и какие элементы мы рекомендуем включить. Также мы приведем несколько примеров для разных проектов. Это поможет сформировать фундамент для последующего комбинирования разных метрик в зависимости от задачи.


ЧТО ТАКОЕ TEST SUMMARY REPORT?

 

ISTQB: A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria.


В этом документе мы описываем все тестовые активности и результаты, которые были получены после проделанной работы за определенный период времени на проекте (за спринт, за релиз, после регрессии и тд) или же на определенном тестовом уровне. 


Как пример мы возьмем наш ивент, где участники тестируют стартапы на протяжении пяти часов. Соответственно в Test Summary Report стоит указать информацию о том, чем они занимались все эти пять часов и какие результаты были получены.


ДЛЯ ЧЕГО ОН НУЖЕН?


Данный артефакт имеет огромную важность для принятия решения о продолжении тестирования или изменения его стратегии. Test Summary Report чаще всего пишутся после регрессии продукта или в конце спринта. 


Написание репорта: 

  • Дает информацию о качестве продукта “на данный момент” как самим тестировщикам, так и заказчику;

  • Наглядно демонстрирует проблемы продукта. Эта статистика поможет принять решение о том, чему уделить больше вниман я в следующем спринте. Как гласит принцип тестирования №4 Defects clustering;

  • Показывает какие процессы на проекте следует улучшить, чтобы повысить качество продукта.

ЧТО ДЕЛАТЬ, ЕСЛИ ЗАКАЗЧИК НЕ ХОЧЕТ ТРАТИТЬ ВРЕМЯ?

 

“Если вы не любите Test Summary Reports, то вы просто не знаете как их готовить.”


Часто слышу от участников ивента Test UA StartUps, что “мой менеджер не дает времени на Test Summary Report” или “заказчика репорты не интересуют”. Как показывает опыт, если заказчик / PM не хочет получать репорты, чаще всего он не понимает их ценности. Поэтому задача тестировщика в том числе донести до заказчика, каким образом данный артефакт поможет улучшить качество продукта или даже всего процесса тестирования. 


Чтобы было легче понимать назначение определенных частей отчета - важно знать что: За качество продукта несет ответственность не только команда/отдел тестирования, а вся команда. 


Ведь мы помним, что согласно “пирамиде тестирования” (https://s.dou.ua/storage-files/MyPyramide1.jpg ) первые тесты должны быть - unit tests. 

Тестировщики должны “рекомендовать” или наоборот “не рекомендовать” заказчикам или ПМам релизить билды. Но тестировщики не решают будет релиз или нет.


ЧТО ДОЛЖНО БЫТЬ В БАЗОВОМ TEST SUMMARY REPORT ?


Для примера мы рассмотрим только базовые составные Test Summary Report, которые судьи нашего ивента хотят видеть как результат трудов участников. Любые дополнения к последующей информация приветствуется.

Итак, в Test Summary Report мы вносим следующую информацию:


PRODUCT DETAILS:

Application under test. Для начала стоит указать название продукта. Ведь иногда тестированию на ивенте подвергается не один продукт, а несколько. В таком случае нужно разделять их и результаты их тестирования.


Purposes of the testing. Указываем цель тестирования: регрессивное тестирование продукта, проверка нового функционала и тд.


SPRINT / DATE / BUILD

Чтобы через какое-то время не забыть, что тестировалось и в каком билде были найдены баги стоит указывать хотя бы минимальную информацию о времени тестирования или версии продукта. 


SUMMARY

Это, пожалуй, самая важная часть Test Summary Report, о которой чаще всего забывают. Одна из основных задач тестирования и тестировщика - это не просто искать баги, а давать информацию о качестве продукта! Девелоперы/PM/PO или заказчик не знают общей картины качества, они могут не знать о проблемных составляющих продукта или о том, насколько он готов к релизу. 


Поэтому именно ради этой части и пишется весь артефакт для заказчика, где мы указываем GO / NOT GO - готов ли продукт к релизу (учитывая DOD критерии). Именно об этой части я упоминала в ремарке. Мы должны дать рекомендацию, стоит ли этот билд вообще сабмитить или он не “met DOD criterias”.


ENVIRONMENT 

 В этом разделе мы указываем системы / браузеры / девайсы и другую информацию о том, на чем вы тестировали.


TEST APPROACH DETAILS или WHAT WAS TESTED:

 Описываем что и как мы тестировали. Было ли все тестирование сделано “exploratory” или же исользовали регрессионные тестсьюты, только функциональное тестирование или же не-функциональное тоже, инструменты, техники тестирования и тд.


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


TIME SPENT:

 Указываем сколько времени заняли все виды тестовых активностей.

  • Environment setup

  • Bug submission

  • Regression testing / Exploratory testing / и тд. 


STATISTICS

А вот тут мы и будем добавлять крутые таблички, pie и другие диаграммы с тестовыми метриками. Какие же метрики можно измерять? 

Например:

  • Test Coverage

  • Test cases statistics by covered areas

  • Issues Severity

  • Issues by components 




BUGS:

Советуем еще добавлять список найденных дефектов и импрувментов.

Конечно, как я уже писала, пункты в Test Summary Report могут варьироваться в зависимости от проекта, нужд и метрик, которые вы измеряете. Выше мы перечислили минимальный набор, который поможет составить полную картину о проделанной работе.


В качестве иллюстрации приведу несколько примеров с Test UA Startups и моих проектов.


автор

Марина Шевченко

2,712 views

2015 - 2018  © All Rights Reserved

  • Black Facebook Icon
  • Black LinkedIn Icon