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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A bug is a subclass of issue. All bugs are issues, but not all issues are bugs.

Typically a bug is a defect in the codebase. This is different from an incomplete/yet-to-be implemented feature, or something more hard to pin down like a developer putting in a ticket to deal with a piece technical debt, or a concern with the UI. All of these are 'issues' semantically speaking.

A generic issue, when not falling under those other categories, is more often than not a representation of something reported by the end-user. In most systems, this reported issue is handled as a bug-report in itself. I'd venture to say this is a mistake.

The tricky part is that sometimes multiple issues may be related to other issues. It could be concerning the same bug, multiple bugs, or actually be a feature request. That is to say, there can be a many-to-many relationship between issues.

Why does the distinction matter? Well, there is a natural tree internally - Resolving one issue can indirectly complete (or contribute to completing) a million other issues. It also makes a difference in how an issue is resolved. Defects themselves may be resolved with a code change that fixes it, or makes it irrelevant. If it's a user complaint, it may be resolved by sending them a work around, and then left to be followed up on when the original defect is solved.

Features that work better at representing and working with these nuances in a useful way is really what to look for in a ticket tracking system.

At some point, you are talking about processes and methodologies more than actual ticketing systems, and the actual names of things should start to become irrelevant. Mainstream and enterprise oriented solutions tend to run on a popular systems like ITIL, but you can get away with adhoc stuff provided everyone on the team has a good understanding of customer service needs. I personally see it as a waterfall (ITIL) vs agile (DevOps) situation.

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

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

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

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

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

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

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

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

Две системы,

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

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

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