TRR Flashcards
TRR
Отчёт о результатах тестирования (Test Result Report, TRR) – часть документации
по тестированию, включающая в себя описание процесса тестирования, итоговую
информацию о протестированной за подотчетный период функциональности системы,
данные о деятельности тестировщиков, планах, возможных проблемах, а также
некоторые статистические данные / метрики.
Цель TRR
Цель написания TRR – проанализировать текущий процесс на проекте и качество
продукта на данном этапе, чтобы выявить возможные проблемы и устранить, а также
предоставить лицам, заинтересованным в проекте, данную информацию, которая
выражается в конкретных фактах и / или цифрах
Характеристики TRR
Test Result Report:
● Должен создаваться по расписанию.
● Заинтересованные лица на проекте должны быть проинформированы о
созданном отчете про результаты тестирования.
● Должен содержать актуальную информацию, не приукрашивая статистические
показатели.
● Составляется ведущим тестировщиком в команде (если Вы – единственный
тестировщик на проекте, то это ваша прямая обязанность).
● Может обсуждаться на митинге (совещании) или носить информативный
характер, если согласно отчету, все идет по плану, процессы в команде
приводят к поставленным целям и качество продукта на данный момент
соответствует ожиданиям.
● Может быть промежуточным (еженедельным, за спринт, ежемесячным и т.д.), а
также финальным, то есть за весь проект.
Части TRR
Test Result Report состоит из следующих секций (некоторые из них могут
отсутствовать для конкретного проекта, так как они могут не нести смысловую
нагрузку, так же могут быть добавлены дополнительные секции):
• Команда по тестированию, которая работала над проектом (Testing Team).
________________________________________________________________________
________________________________________________________________________
• Описание процесса тестирования (Testing Process Description).
________________________________________________________________________
_______________________________________________________________________
● Расписание команды (может включать затраченное время), отражающее
выполненные задачи (Team Timetable / Schedule).
Краткое описание статуса текущего периода (описание процесса и качества)
(Summary).
________________________________________________________________________
________________________________________________________________________
● Проблемы, которые мешают запланированному выполнению задачи (Blockers).
________________________________________________________________________
● Риски (Risks).
________________________________________________________________________
● Рекомендации (Recommendations).
________________________________________________________________________
● Список найденных багов (за текущий период и / или за весь период) (Bugs List).
________________________________________________________________________
● Статистика по ошибкам (распределенная по status, priority, severity и/или
модулям приложения) (Bugs Statistics / Overall Bugs Statistics).
________________________________________________________________________
● Метрики (Metrics) (например, процент “заваленных” билдов; процентное
соотношение найденных багов тестировщиками к багам, найденным заказчиком
во время UAT; процентное покрытие требований тест-кейсами; процент,
показывающий количество пройденных тест-кейсов ко всем созданным тест-
кейсам; процент, показывающий количество переоткрытых багов; процентное
соотношение требований, на реализацию которых ушло ожидаемое время, к
требованиям, на реализацию которых ушло больше запланированного
времени).
