Какая разница между отслеживанием ошибок и системой отслеживания проблем?

Ответ 1

Системы отслеживания проблем обычно интегрируются с клиентами и проблемами клиентов. Проблема может заключаться в том, чтобы "помочь мне установить это" или "Как я могу получить фуббар в flim flam". Они могут даже быть чем-то вроде "Мне нужен ключ evalutation для вашего программного обеспечения".

Системы отслеживания ошибок помогают отслеживать ошибки или недостатки в программе.

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

Ответ 2

Разница может быть более ясной из следующего примера.

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

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

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

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

Две системы, направленные наружу и внутрь, отслеживающие два разных типа вещей, каждый со своим жизненным циклом.

Ответ 3

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

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

Примеры каждого из них см. в Wikipedia Сравнение систем отслеживания проблем

Ответ 4

Ошибка - это подкласс проблемы. Все ошибки - это проблемы, но не все проблемы являются ошибками.

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

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

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

Почему разница имеет значение? Ну, внутри есть естественное дерево. Разрешение одной проблемы может косвенно завершить (или внести свой вклад в завершение) миллион других вопросов. Это также влияет на решение проблемы. Сами дефекты могут быть устранены с помощью изменения кода, которое его исправляет, или делает его неактуальным. Если это жалоба пользователя, это может быть разрешено путем отправки им работы, а затем оставлено для продолжения, когда исходный дефект будет разрешен.

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

В какой-то момент вы говорите о процессах и методологиях больше, чем о реальных системах продажи билетов, и фактические названия вещей должны начинать становиться неуместными. Решения Mainstream и предприятия ориентированы на популярные системы, такие как ITIL, но вы можете уйти с помощью adhoc, при условии, что каждый в команде хорошо разбирается в потребностях клиентов. Я лично вижу это как ситуация с водопадом (ITIL) против agile (DevOps).

Ответ 5

это просто семантика. Ошибка - проблема, проблема - это что-то делать. Они в остальном почти одинаковы.

Ответ 6

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

От нашего друга Wikipedia

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

Ответ 7

Ошибка найдена в коде

Проблема может быть найдена где угодно, в процессах, в оборудовании, у людей.

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

Ответ 8

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

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

Ответ 9

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

Хорошим примером системы, которая хорошо сочетается с кодом, является Trac.

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

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

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

В любом случае... мои $0,02.

Ответ 10

Ошибки: недостатки в любом месте процесса (приложение, база данных, отчетность и т.д.), что предотвратит появление 100% желаемой функциональности. Также известны и называются дефектами.

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

Ответ 11

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

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

В последнее время также наблюдается рост отслеживания рабочих элементов (например, Visual Studio и IBM/Rational Jazz), который является более низким уровнем, чем "проблемы", - в котором проблема может рассматриваться как требующая некоторого количества N меньших рабочих элементов. На более высоком уровне вы также можете увидеть нечто похожее на Milestone в BugZilla.

Ответ 12

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

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

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

Ответ 13

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

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

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

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

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

Ответ 14

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