Зачем использовать программное обеспечение для отслеживания ошибок? [закрытый]

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

У меня есть некоторые основы

  1. отслеживать ошибки (ок, это легко)
  2. дефекты не теряются и не забываются
  3. мониторинг тенденций может рассказать вам много о вашем продукте
  4. можем получить лучшее представление о состоянии вашего товара

Я знаю, что есть другие, возможно, лучшие причины, так что они?

14 ответов


багтрекер, это также полезно для постановки вех и принимает пожелания.


Статистика, Подотчетность, Отслеживание Прогресса, Автоматизация.

мы используем наши базы данных ошибок для отслеживания статистики, такой как:

  • найти скорость (на тестер) - насколько хороши ваши тестеры x, насколько багги ваш код.
  • Fix rate (per dev) - насколько хороши ваши разработчики x насколько неприятны ваши ошибки.
  • Bucketing-какие функции являются самыми багги / кто пишет больше всего ошибок?
  • оценка того, когда вехи будут поражены на основе ошибки склон.
  • рабочие элементы и предложения-мы помещаем этот материал в наши базы данных, а не только ошибки.

другие хорошие биты данных, которые вы можете получить из своей БД:

  • что тестируется?
  • список исправленных проблем для выполнения регрессионного тестирования.
  • исторические данные! Мы отслеживаем все наши проекты и сравниваем их соответствующие склоны ошибок.
  • один источник для всего сообщения о жуки.

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


какова альтернатива, которую вы планируете использовать? Электронная почта? Белая доска? Ваша кратковременная память? Это поможет, если вы сравните с альтернативой, а не в вакууме.

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

  • все желающие могут посмотреть на программное обеспечение, чтобы понять, сколько ошибок осталось исправить.
  • люди, видящие проблемы, могут посмотреть, есть ли у них уже его нашли.
  • общий источник данных об ошибках может упростить сортировку ошибок как группы.
  • программное обеспечение для отслеживания ошибок позволяет людям на всех уровнях продукта (dev, test, pm, management) видеть общий взгляд на мир.

Я не могу представить себе работу над нетривиальной частью программного обеспечения без какой-либо формы отслеживания ошибок.


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


в то время как другие дали ответ enterprisey/servicey, причина, по которой я использовал программное обеспечение для отслеживания ошибок в своем личном проекте, просто потому, что у меня есть что-то, чтобы насмехаться надо мной. Каждый из билетов напоминает мне, что еще многое нужно сделать, и не время уходить, потому что программное обеспечение не "завершено"."

О, и это бьет post-its и комментарии в коде в качестве напоминаний todo.


  • проверка прогресса вашего программного обеспечения
  • есть измеримый способ решить статус вашего программного обеспечения (например: Альфа: высокоприоритетные ошибки все еще открыты, бета: только незначительные ошибки открыты, RC: нет сообщений об ошибках открыты)
  • назначение ошибок соответствующему разработчику/команде / отделу

отношений с клиентами

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


  • возможно, вы сможете определить шаблон в багах, который предполагает более широкое исправление, чем просто исправление отдельные ошибки. Рефакторинг может быть указан.
  • Это может помочь определить, какой разработчики создают больше всего ошибки, которые могут привести к предложениям о наставничестве или поощрении больше тестирование собственной работы теми, индивидуумы. И наоборот, разработчики с несколькими ошибками, очевидно, делают лучше проверить их работу.

построили TrackJumper в качестве помощи для фрилансеров, чтобы помочь им общаться с клиентами. Когда проект является новым и разрабатывается, "Bug Tracker" действительно неправильное название - это больше список дел. НО... мы обнаружили, что полезно относиться к новым функциям, запросам, вещам, оставленным сломанными так же, как мы относимся к ошибкам. То есть они назначаются кому-то, они могут быть низкого или высокого приоритета, и они могут быть открыты или закрыты. Они также являются предметом обсуждения.

Так Что Я добавит "помощь в разработке проекта" в список причин использования трекера ошибок.


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


см. статью Джоэла Спольски о Безболезненное Отслеживание Ошибок.


Это отличный способ для обратной связи с пользователями. Они сообщают, что они действительно считают важным о вашем программном обеспечении (не всегда точно, что вы бы).

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


лучшие трекеры ошибок прекрасно интегрируются с вашим контролем версий, и они действительно дополняют друг друга. Журналы VC commit говорят вам, кто и что, комментарии к баг-трекеру говорят вам, почему.

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

Я использую и рекомендую в Redmine кстати .. очень хорошая интеграция CVS и Subversion.


теперь понятно, почему мы должны говорить о котором!!!!

Я рекомендую инструмент отслеживания ошибок Assembla. Это очень простой в использовании (так же просто, как с помощью системы Gmail stars) и имеет много интересных функций!

http://www.assembla.com/features/bug-tracking