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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в любом случае... мои $0.02.

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

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

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

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

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

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

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

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

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

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

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

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

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

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