Для чего нужен багтрекер?
Багтрекер (англ. bugtracker) нужен для учета и контроля дефектов программы или сайта. За всей кажущейся сложностью, багтрекер предоставляет уйму преимуществ перед своими конкурентами — электронной табличкой и прямыми письмами разработчику.
| Багтрекер | Табличка в Google Spreadsheet | Письмо разработчику напрямую | |
| Возможность отслеживания статуса проблемы |
5 Предоставляет статусы для каждой проблемы, которые можно отслеживать, как лично, так и используя оповещения на почту или RSS. |
2 Отслеживания статусов сменой цветов ячеек. Нет оповещений. |
0 В случае мелких проблем и большой загруженности, отслеживать конкретные проблемы просто невозможно. |
| Качество описания проблемы |
5 Обязательные поля для категорий, воспроизводимости, системы, описания и шагов повторения. |
3 Можно реализовать дополнительные поля в колонках, но нет гарантии их заполнения. |
2 В большинстве случаев сводится до «поломались отчеты, выручай».
|
| Возможность прикрепления файлов |
5 Можно прикреплять любые файлы в любое время. |
0 Нельзя прикреплять файлы вообще. |
3 Нельзя прикрепить файлы после отсылки сообщения. |
| Комментирование проблем |
5 Можно комментировать проблему, как, например, обычные записи в блогах. |
2 Комментирование доступно в виде создания новых колонок и раздувания таблицы. |
1 Доступ извне возможен только с вовлечением другого человека в переписку, при том, что он не будет знать, о чем говорили до него. |
| Совместная работа над проблемами |
5 Система ролей и прав доступа. |
2 Все видят все, и никто конкретно ни за что не отвечает. |
1 Обсуждение проблем приватное. |
| Всего очков | 25 | 9 | 7 |
Хорошим примером багтрекера является Mantis — свободный и бесплатный багтрекер с открытым кодом и русским переводом в наличии. В нашей компании он принят на вооружение, поэтому дальнейшее рассуждение будет опираться на примеры из него.
С чего начинается багрепорт
Процесс создания первого отчета о проблеме занимает не более пяти минут. После входа в систему, вам нужно выбрать в основном меню пункт «создать инцидент»:
что приведет нас на форму введения деталей проблемы:
После создания багрепорта, ему назначается статус «новый» и он попадает в общую очередь. Что происходит дальше:
- Менеджер или разработчик знакомится с проблемой и если проблема понятна и существует, устанавливает задачу в статус «назначено» (выбрав предварительно на кого назначена задача).
- Если проблему не удается повторить, или же требуются дополнительные детали, задача устанавливается в статус «нужен отклик». В этом случае, создателю задаче необходимо внести дополнительные данные или закрыть задачу совсем, если она оказалась ложная.
- После того, как разработчик решает проблемы в «назначенной» задаче, он устанавливает ее статус в «решена». Это дает повод создателю задачи проверить результат, и если он положителен, закрыть задачу. Если проблема решена не до конца, создатель переоткрывает задачу, устанавливая ее статус в «новая» или «назначена».
В процессе, нужно изменить или добавить какие-то детали задачи:
Эффективное описание проблем
Не нужно ставить себе целью просто обратить внимание на проблему, на сам факт ее существования. Важно, чтобы наш собеседник понял, в чем именно ее суть и чтобы на фоне его сознания сразу же закрутился поиск решения.
Формула идеального багрепорта состоит из трех простых пунктов:
1. Что сделал?
(Steps required to reproduce the problem)
2. Что получил?
(Actual results)
3. Что ожидал получить?
(Expected results)
Кроме того, нужно сообщить, где именно произошла проблема, при каких условиях а также дать ошибке название.
Еще о написании отчетов об ошибках можно почитать здесь »
Реальные отзывы счастливых клиентов
И в завершение, несколько слов о том, как кленты ведут себя по прошествию двух дней внедрения багтрекера в процесс:
- «Спасибо, это действительно оказалось просто.»
- «Да, вы были правы, теперь видно над чем идет работа.»
- «I've just uploaded the screenshot, what a nice thing.»