2008-08-30 7 views
7

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

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

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

+0

Как тестер, я согласен с Херши. Ответственность тестировщика заключается в том, чтобы как можно лучше сообщать об ошибках. Если просить тестеров не помогает, спросите своего менеджера.Если это не поможет, более эскалация, объясняя, как это занимает дополнительное время, замедляет выпуск, увеличивает затраты. В конце концов, если люди не могут измениться, вы можете попросить менеджеров изменить людей. – yoosiba 2009-11-03 20:28:36

ответ

3

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

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

Сценарий:

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

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

Примечания:

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

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

+1

+1. Также важно (и подмножество «образования») привести пример. Представляйте и разрабатывайте отчеты об ошибках в системе, которые вы считаете образцовыми из лучших, и отсылайте людей к этим примерам. Хвалите и привлеките внимание общественности к сообщениям об ошибках, которые приходят в том, что вы считаете высоким качеством. – bignose 2010-02-12 03:53:23

0

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

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

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

0

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

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

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

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

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

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

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

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

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

2

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

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

3

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

0

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