Как следует отслеживать ошибки и помогать интегрировать билеты? - PullRequest
4 голосов
/ 27 февраля 2009

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

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

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

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

Есть мысли? Предложения? Подсказки? Совет? To-DOS? Не для того? и т.д ...

Ответы [ 3 ]

3 голосов
/ 27 февраля 2009

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

2 голосов
/ 27 февраля 2009

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

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

Если это последнее, вам вообще не следует интегрироваться.

0 голосов
/ 26 апреля 2010

Ну, это компромисс.

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

Плюсы:

  • Рабочие процессы и требования, вероятно, будут различаться в зависимости от разработчиков и справочной службы. Вы можете выбрать систему для каждой из них, которая соответствует требованиям (например, поля, которые относятся только к dev или для службы поддержки, различные виды интеграции электронной почты).
  • Четкие обязанности: служба поддержки обрабатывает заявки, разработчики - ошибки.

Минусы:

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

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

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

...