Рекомендации по отслеживанию ошибок [закрыто]

в моей компании применяются следующие правила:

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

какой поток отслеживания ошибок вы используете? Хорошо ли это работает для тебя?

10 ответов


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

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

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

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

  • технические руководства отвечают за приоритизацию ошибок на основе спроса на это конкретное исправление.

  • тестеры / QAEs отвечают за присвоение серьезности ошибке, т. е. критической/крупной/малой и т. д.

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

таким образом, мы гарантируем, что мы отслеживаем все изменения одновременно в нашей системе управления версиями (которая является TFS btw) и Bugzilla, чтобы любые изменения могли быть прослежены до исходного кода-изменения/владельца, если это необходимо в будущем.


alt text


звучит довольно сложно. Мы используем примерно следующий процесс:

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

Это легкий процесс, который подталкивает застройщиков брать на себя ответственность за свои проблемы.

помимо этого, у нас есть несколько мер по обеспечению качества для процесса изменения чего-либо в программном обеспечении, независимо от источника и типа запросов на изменение. Это включает в себя особенно:

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

Я использовал большое количество систем отслеживания проблем, включая комаров (тьфу!), Бугзилла (чуть меньше тьфу), Трак, Джира, а теперь Фогбагз. Мне больше всего нравится Trac, но это, вероятно, потому, что я не администратор FogBugz, и он, к сожалению, ужасно неправильно используется в своем нынешнем воплощении.

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

  1. проблемы, отмеченные реальными клиентами (живые ошибки).

  2. проблемы с новым программным обеспечением в настоящее время в разработке (ошибки dev).

  3. что мы хотим сделать в будущем (особенности).

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

серьезность проблемы описывает, насколько ужасны побочные эффекты. По моему опыту, это сводится к:

  1. программа что-то испортила. Данные, неправильно выставленные счета клиентам, неправильно выписанные лекарства. Хуже не бывает. Я когда-то работал над системой, где команда программного обеспечения втянул гидравлическую руку прямо в середину военнослужащего. Хуже не бывает.

  2. программа рушится, и у нас нет обходного пути, но это ничего не разрушает (кроме того, чтобы быть вниз) в то же время. Если время простоя результатов в чем-то разоряется использовать тяжести #1.

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

  4. программа плохое поведение, которое раздражает, но не влияет на результаты.

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

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

в небольших и средних командах, с которыми я тесно работал, этот общий набор правил работал хорошо:

  • любой может создать проблему. Создатель может назначить проблему любому (или большинству) получателей по мере ее создания. Получателем по умолчанию является команда сортировки вопросов. Разработчики могут отметить ошибки, которые они нашли, работая над кодом таким образом, и назначить ошибку себе, чтобы отслеживать, почему они меняются код.

  • команда сортировки встречается (укажите интервал здесь), чтобы оценить и назначить проблемы. Команда сортировки специально ищет дубликаты отчетов, в этом случае новая проблема "сворачивается" в существующую цепочку проблем; для непродуктивных проблем из поля, которые назначаются QA для воспроизведения; и для проблем высокой степени серьезности от клиентов.

  • создатель ошибки-единственный человек, который может ее закрыть. Сообщения об ошибках инициированы по QA или по CSR не может быть закрыт разработчиком. Да, это означает, что ошибки, с которыми CS и команда разработчиков не согласны, остаются неразрешенными. Почему трекер проблем сообщает о проблеме как решенной, когда люди не согласны? Если вам нужен цифровой репозиторий лжи, у вас есть C-SPAN.

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

процесс сортировки является ключевым. Команда сортировки-это, по сути, тот, кто в вашей организации решает, кто над чем работает и над чем будет работать дальше. Регулярное собрание команды помогает удостовериться, что действительно важные вещи не пропущены, и что мирские вещи не будут отброшены из-за невнимательности. Если нет ничего в очереди сортировки, конференц-зал (concall, программа netmeeting, независимо от реализации) может быть отменено руководителем совещания.

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


подожди, ты пишешь:

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

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

похоже, что ваша система отслеживания ошибок действительно является системой отслеживания дефектов пользователя.

Это хорошо работает для вас или вы ищете альтернативы?


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

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

другие практики можно найти в Безболезненное Отслеживание Ошибок Джоэл Спольски.


за последние 10 лет я использовал несколько различных типов систем отслеживания ошибок, включая nothing, документ word, FogBugz, Bugzilla и Remedy. FogBugz, безусловно, лучший. На этой работе каждому разрешалось вводить ошибки, и каждый мог назначить ошибку кому угодно. Я обнаружил, что это работает хорошо, особенно если я нашел небольшую ошибку в своем коде. Вместо того чтобы тратить час на написание электронных писем, заполнение форм и привлечение нескольких других людей, я мог бы быстро зарегистрировать, что я нашел и исправил ошибку. Это побудило меня ввести все ошибки, которые я нашел, и исправить их быстро. Если ошибка требовала много работы, я назначал ее своему менеджеру, чтобы он мог расставить приоритеты с другой моей работой.
На работе, где я использовал Bugzilla, каждый раз, когда ошибка была создана, назначена или изменена, всем разработчикам и менеджерам отправлялось электронное письмо. Это имело противоположный эффект, это обескуражило меня от поиска и ввода ошибок в систему.


ошибки регистрации - это скорость - только минимальный объем информации, необходимой для исследования / репликации ошибки

для веб-проектов, это сводится к: 1) Название ошибки, 2) страницы, где произошла ошибка, 3) Описание проблемы + скриншот или пошаговые инструкции по репликации проблемы (если скриншот не предоставлен)

скриншоты очень мощные по двум причинам: 1) изображение говорит тысяча слов, 2) это дает кредитоспособность отчету об ошибке (когда-либо исследовать ошибку, которую вы не могли бы реплицировать и думать, что "похоже, что клиент снова делает вещи"?)

У меня есть статья в блоге, которая идет в теме далее: Регистрация ошибок, как Pro


мой маленький магазин использует довольно простой рабочий процесс:

  • любой может создать проблему (я думаю, что это излишне ограничительно, чтобы не допустить этого), это включает клиентов и пользователей наших проектов с открытым исходным кодом.
  • плата управления изменениями (звучит причудливо, но это просто QA lead и head of engineering, plus product manager) рассматривает новые проблемы и назначает версию исправления и приоритет
  • любой может переназначить ошибку, задать репортеру вопрос или передать другой человек, чтобы исправить или проверить
  • любой может отметить ошибку решена
  • только QA может закрыть ошибку - мы делаем это, чтобы обеспечить проверку каждого исправления ошибки.

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

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


какой поток отслеживания ошибок вы используете?

  • тестер опубликует все ошибки в открытом состоянии
  • назначение разработчику
  • разработчик попытается исправить ошибку-исправлена
  • Ошибка Закрыта
  • открыть состояние ошибки