Лучшая практика отслеживания ошибок

Ответ 1

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

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

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

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

• Технические выводы отвечают за определение приоритетов ошибок, основанных на требовании этого конкретного исправления.

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

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

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

Ответ 2

Ответ 3

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

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

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

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

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

Ответ 4

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

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

• Проблемы, отмеченные настоящими клиентами (живые ошибки).

• Проблемы с новым программным обеспечением, находящимся в разработке (dev bugs).

• Вещи, которые мы хотим сделать в будущем (функции).

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

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

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

• Программа рушится, и у нас нет работы, но она не разрушает что-либо (кроме того, что оно не работает). Если время простоя в результате чего-то разрушается, используйте строгость № 1.

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

• Программа плохо себя ведет, раздражая, но не влияя на результаты.

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

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

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

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

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

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

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

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

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

Ответ 5

Подождите, вы пишете:

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

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

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

Хорошо ли это для вас или вы смотрите на альтернативы?

Ответ 6

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

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

Другие практики можно найти в Безболезненное отслеживание ошибок от Joel Spolsky.

Ответ 7

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

Ответ 8

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

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

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

У меня есть статья в блоге, которая далее идет в тему: Журналы Ошибок как Pro

Ответ 9

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

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

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

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

Ответ 10

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

• Тестер опубликует все ошибки в открытом состоянии
• Присвоение разработчиков
• Разработчик попытается исправить исправленную ошибку
• Ошибка закрытия
• Восстановить статус ошибки