Пишем отчёты о дефектах

В большинсве проектов используют те или иные багтрэкинговые сисемы. Это может быть кастомный (например, на базе SharePoint), бесплатный (например, Bugzilla) или платный (например, JIRA) продукт. Однако вне зависимости от выбора такой системы, шаблон, по которому пишутся отчёты о найденных дефектах будет очень похож. Конечно же очень важно выставлять багу правильный приоритет, версию ПО, ответственного разработчика и т.п., но я бы хотел обратить внимание на три поля, информация в которых повлияет на понимание дефекта, его восприятие и потребует от тестировщика некоторых усилий и определённых знаний тестируемой системы.

1. Summary
Резюме бага, оно же саммари (summary) - это лицо бага, это та самая "одёжка", по которой встречают. Очень многое зависит от того, насколько удачно сформулировано саммари. В идеале, прочтя саммари, разработчик должен на 80% понять суть проблемы.
Советую учесть следующие моменты при написании саммари для дефекта:
а) указание платформы (например, test или prod), если на проекте используется несколько платформ
б) указание компонента (например, аdmin, reports, upload и т.п.), если последующее описание может подойти нескольким компонентам
в) указание браузера (например, IE7), если ошибочное поведение наблюдается специфически под определённым браузером
г) указание частоты воспроизведение (например, occasionally или 4 of 10 times), если воспроизводится не на постоянной основе
д) использование терминологии, использующейся в тестируемой системе (например, не photos, а images или не scroll bar, а slider)

2. Description
Описание шагов (description) - по сути самое важное во всём отчёте, поскольку от того, как тестировщик сумеет объяснить суть бага и шаги к его воспроизведению, зависит его (бага) дальнейшая судьба. Слишком кратко - высока вероятность того, что баг вернётся к тестировщику для уточнения. Слишком детально - разработчик скорее всего отложит такой баг на потом, поскольку его даже читать лень, не говоря уже о качественном фиксе. Осюда вывод, что для того, чтобы избежать временных потерь, надо искать оптимальный размер описания.
Лично я, при написании баг репорта, советую выбрать довольно высокую степень детализации шагов, однако, по возможности, группировать несколько простых действий в один шаг.
Помните, что хорошо описанная проблема - проблема наполовину решённая.

3. Attachment
Правилом хорошего тона в данном случае будет добавление к описанию бага визуального подтверждения. Более распространённым видом такой визуализации является снимок экрана, он же скриншот (screenshot), однако с нынешним выбором ПО нет никакой проблемы прикрепить и заархивированное видео. Многие разработчики оценят такого рода апгрейд - ведь, как говорится, "лучше один раз увидеть, чем сто раз услышать два раза прочитать"

Задача тестировщика состоит не только в том, чтобы найти баг, но и в том, чтобы найденный баг был исправлен.
Помните, что если ваш баг вернулся к вам со статусом не Resolved, то скорее всего в этом виноваты вы.


P.S. Если вы не уверены в том, насколько хорошо вы справляетесь с перечисленными тремя пунктами - не стесняйтесь и спросите у тех, кому приходится непосредственно с этой информацией работать - вашу команду разработчиков