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

Question

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

Answer 1

Системы отслеживания проблем обычно больше интегрируются с клиентами и проблемами клиентов. Проблема могла бы быть «помоги мне установить это» или «Как я могу получить фубара в огонь». Это может быть что-то вроде «Мне нужен ключ оценки для вашего программного обеспечения».

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

Answer 6

В коде обнаружена ошибка

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

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

Answer 7

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

От нашего друга Википедия

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

Answer 8

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

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

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

Answer 9

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

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

---

WIKIPEDIA LINKS
- Ошибка программного обеспечения
- Отслеживание проблем

Answer 10

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

Хороший пример системы, которая прекрасно интегрируется с кодом: Trac .

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

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

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

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