Основы bug tracking-a

(В оригинале - How to Use a Bug Tracker)

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

Хороший отчет об ошибке должен содержать три вещи:

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

Объем и качество информации, содержащейся в отчете об ошибке, так же хорошо говорит о качествах того, кто этот отчет создал, как и о самой ошибке. Злобное «Эта функция – полное дерьмо» сообщит разработчику лишь о том, что у нашедшего был тяжелый день, и ничего более. Описание ошибки, содержащее достаточно информации, чтобы ее легко воспроизвести, вызывает уважение, даже если из-за него приходится отложить релиз.

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

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

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

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

И главное – помните, что попытка стандартизировать работу с ошибками примерно столь же эффективна, как и измерение работы программиста числом строк написанного кода.

Автор оригинала - Matt Doar