Как вы обеспечиваете или поддерживаете качество отчетов об ошибках в вашем трекере ошибок?

Question

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

В действительности, однако, сообщения об ошибках могут сильно различаться по качеству. Они могут быть встроенными («функция X не работает, исправьте это!»), Запросами функций, PEBKAC или непонятными.

Как вы обеспечиваете или поддерживаете качество отчетов об ошибках в вашем трекере ошибок, чтобы оставаться эффективными?

Answer 1

Раньше я думал, что качество отчета об ошибке равносильно. Я все еще думаю, что ... ошибки, о которых я сообщаю, содержат гораздо больше полезной информации, чем те, которые были введены QA или Operations. Тем не менее, я пришел к восхищению моделью FogBugz. Это очень просто ввести ошибку. Полезно просто знать, что есть условие ошибки, даже если не так много вспомогательной информации. Кроме того, пользователи чувствуют, что что-то делается.

Answer 2

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

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

Сценарий:

Ожидаемые результаты:

Фактические результаты:

Примечания:

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

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

Answer 3

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

У меня есть справочная копия для редактирования страниц справочника Docbook, и, используя ее несколько раз, я уже знаю большую часть синтаксиса наизусть.

Answer 4

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

Answer 5

Сложный вопрос. Я бы попробовал проверить, есть ли в системе способ принудительного ввода определенных полей, которые вам требуются, попробуйте и у вас появятся какие-либо критические ошибки (email, rss), чтобы вы могли быстро наброситься, но в основном это Ваша команда знает о стандарте качества и придерживается его, руководящие принципы публикуются и публикуются, и все в таком роде.

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

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

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

Предполагая, что это пользователи: Вы не можете в высокой степени, но я постараюсь - если возможно, задавать вопросы в любой форме так, чтобы люди могли их понять.

Не совсем по этой теме, но в стиле «как вы задаете вопросы», этот пост в блоге 37 Signals - текст ссылки

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

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

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

Answer 6

Это зависит от того, говорите ли вы о закрытом обзоре QA и публичной бета-версии.

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

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