На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?
Конечно, дефекты хранятся в баг-трекинговой системе, которая накладывает свои ограничения и требования, конечно, есть какие-то внутрикорпоративные правила создания отчетов об ошибках, но все же есть и человеческий фактор, в результате чего появляются баги, отвечающие всем правилам оформления, но абсолютно непонятные даже коллегам-тестировщикам. Плохо описанный баг может получить резолюцию Cannot reproduce и оказаться забытым, пока случайно не выплывет у заказчика.
В этой статье я попробую описать основные проблемы отчетов об ошибках, которые я встречала за год работы на большом проекте, а также способы их улучшения.
1. Очень общий заголовок баги
Пример такой баги: Не могу создать аккаунт.
Кажется, система полностью неработоспособна. Что может оказаться при более подробном изучении проблемы:
- Такой аккаунт уже существует (или в имени аккаунта введены недопустимые символы), а проблема в том, что сообщение об ошибке не отобразилось (возможно, что только на определенной версии браузера);
- Аккаунт создался, но не пришло подтверждение по почте;
- Другие варианты.
Кстати, все эти подробности (версия браузера, локализация) в шагах воспроизведения могут быть не указаны.
2. Очень подробные pre-steps, очень краткое описание.
Пример: Я забил гвоздь в стену. Потом работал с болтами, гайками и листовым железом. Проблема: космолет не летает.
Дефект начинают описывать как былину: Все действия, сделанные с самого утра, и с максимальной подробностью. Через пару абзацев это надоедает, и дописывают весьма кратко. Да, описание проблемы есть, оно достаточно большое, но совершенно бесполезное как программисту, который будет фиксить, так и тестировщику, которому попадет на проверку.
3. На каждое проявление ошибки создать отдельный баг-репорт
Да, порой бывает не очевидно, что это действительно одна и та же проблема. Но иногда разные проявления одного и того же дефекта попадают на разных девелоперов и тогда начинается неразбериха.
4. Большое количество аттачей и ссылок
У такой баги обычно есть только заголовок. Шаги воспроизведения представляют собой ссылку на test-case (кстати, возможно у программиста нет прав доступа на такой ресурс), ожидаемый результат — ссылка (или аттач) 50-страничной документации. В комментарии может быть приписка что шаги воспроизведения подробно расписаны в дефекте № NNN. В качестве дополнения — лог. Весь. За все 2 недели тестирования. Все 50 мегабайт. Ну и скриншоты каждого шага бонусом.
5. Не указано, в чем именно ошибка.
Да, бывает и такое. Редко (по-этому и не первое в списке), но бывает
Пример:
Заголовок: Javascript ошибка на странице. Далее идут шаги, как добраться до этой самой страницы, но нигде не указано само сообщение об ошибке и даже нет скриншотов.
6. Использование специфических сокращений и аббревиатур
Сокращенные названия сущностей, специфических для определенной части системы могут быть не понятны даже для людей, достаточно давно работающих на проекте. Также большое количество аббревиатур в тексте делает его трудным для восприятия. Время, потраченное на разбор такого дефекта значительно превышает время, которое было сэкономлено на написании отчета об ошибке. Можно использовать общепринятые аббревиатуры и сокращения, но не стоит этим злоупотреблять.
Мне кажется, данные рекомендации могут улучшить качество описания багов:
1 Правильно настроить обязательные для заполнения поля в баг-трекинговой системе, запретить аттачить большие файлы (если это не видео воспроизведения ошибки)
2. По аналогии с code-review: Просите иногда коллег посмотреть на свежесозданный отчет об ошибке. Возможно, они подскажут, что стоит добавить и/или исключить из описания бага.
3. Проверяйте багобазу перед созданием нового отчета — возможно, такой «зверь» уже записан.
4. Золотая середина нужна везде. Пытайтесь писать не пропуская важных шагов, но и не разжевывая очевидные вещи
5. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать
Автор: Allenary
