Software Test

Трекинг. Часть II. Критерии хорошего отчета.

Введение
Определение
Документ
Номер
Простота
Понятность
Воспроизводимость
Разборчивость
Беспристрастность

Введение.

Одним из основных результатов работы тестировщика является обнаружение ошибок в тестируемом ПО и составление отчета об обнаруженной проблеме. Эта статья (вторая из цикла "Трекинг") представляет собой попытку дать рекомендации по составлению грамотного отчета о проблеме (bug report).

Определение.

Повторюсь, что отчет о проблеме - это по сути его описание. План такого описания дан в первой статье цикла. Сэм Канер с соавторами в своей книге описывает ряд критериев хорошего отчета. Давайте попробуем дать краткую характеристику каждого из них.

Документ.

Прежде всего отчет о проблеме должен представлять собой реальный оформленный документ. Он может быть бумажным или электронным, но не устным. Отчет на словах недопустим, так как обнаружение и документирование найденных ошибок и есть основная цель работы тестера, что не дает потерять обнаруженный баг, а следовательно повышает шансы на исправление и, в конечном итоге, на повышение качества программы.

Номер.

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

Простота.

Не следует помещать в один отчет несколько проблем сразу. Т.е. по каждой проблеме должен быть составлен отдельный отчет, даже если они связаны между собой. В этом случае лучше поместить перекрестные ссылки на связанные между собой отчеты, а не сливать все в один. Такой подход существенно облегчает отслеживание описанных багов в дальнейшем и не позволяет программисту исправить одну ошибку, но при этом пропустить другую в этом же отчете.

Понятность.

Любой найденный баг должен быть описан просто и понятно. Чем доступнее описание, тем выше вероятность того, что ошибка будет понята программистом и исправлена. Краткое описание проблемы должно отражать его суть, а полное описание не должно содержать вычурных фраз и непонятных терминов. Шаги воспроизведения проблемы должны быть описаны максимально понятно. Кроме того, если в ходе тестирования выяснилось, что для воспроизведения описываемой проблемы можно обойтись без определенного шага, то этот шаг должен быть убран из отчета. Чем меньше шагов для воспроизведения проблемы нужно будет сделать программисту, тем скорее он будет исправлен.

Воспроизводимость.

Прежде чем составлять отчет о найденной проблеме тестировщик должен убедиться в том, то она стабильно проявляется при определенных шагах. Воспроизводимость описываемого бага может служить важным моментном как для его локализации, так и для решения об исправления. Если в системе трекинга не предусмотрена графа с отметкой о воспроизводимости, обязательно следует указать в отчете, воспроизводим ли описываемая ошибка или нет (например, перед описанием шагов при которых проблема была обнаружена).

Разборчивость.

Прежде всего это касается "бумажных" отчетов, написанных от руки. Мне не доводилось участвовать в проектах с такой системой трекинга. Однако, если таковые еще существуют, становится ясно, что чем легче программисту будет разобрать написанное, тем плодотворнее будет Ваше с ним сотрудничество. Но как ни странно это относится и к электронным отчетам. В большинстве электронных систем трекинга есть возможность менять не только шрифт и его размеры, но и цвет. Пестрота в отчете так же не уместна как и "корявый" почерк.

Беспристрастность.

Думаю очевидно, что в любом из видов документации не допустимы выражения несущие эмоциональную окраску. Отчет о проблеме прежде всего является документом. Поэтому, при составлении отчета следует придерживаться нейтрального тона описания, даже если есть основания сомневаться в компетентности Ваших коллег. Ошибки может допустить каждый, в том числе и тестер. Предоставьте начальству решать вопрос о соответствии того или иного сотрудника занимаемой должности. Не провоцируйте других, и не поддавайтесь на провокации сами.

О самих системах трекинга и конкретных ее представителях - в следующих статьях этого цикла.

См. также:
Гущин Павел. Состояния багов.
Михаил Портнов. Классификация багов.
К вопросу о ведении базы.
FAQ. Что такое баг? Синонимы понятия...
Трекинг. Часть I. Основы