Как расставить приоритеты в ошибках?

Question

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

Как классифицируется серьезность / приоритет ошибок? Существуют ли какие-либо стандарты, определяющие порядок определения приоритетов дефектов программного обеспечения на основе потребностей клиентов, сроков и прочего?

Answer 1

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

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

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

Попытка объединить «серьезность» и «приоритет» в одном поле приведет к душераздирающим аргументам и потерянному времени . Специалисту по устранению ошибок необходимо твердое руководство по факту 1034 *, чтобы определить, насколько «плох» ошибка, и это должно быть легко согласовано независимыми сторонами. Приоритет, с другой стороны, является правильной целью для переговоров и планирования игр.

Answer 2

Я работаю над системами центра аварийного управления, так что этот набор уровней ошибок немного, ну ... extreme :

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

Это с моей головы. Если вам интересно, это от крайности к минимуму: -)

Answer 3

Некоторые вещи, которые мы использовали раньше. Мы делим рейтинг дефектов на приоритетность и серьезность.

Серьезность (устанавливается отправителем при отправке дефекта)

• Наивысший (5): потеря данных, возможное повреждение оборудования или сбой, связанный с безопасностью
• Высокий (4): потеря функциональности без разумного обходного пути
• Средний (3): потеря функциональности с разумным решением проблемы
• Низкий (2): частичная потеря функции или набора функций (функция по-прежнему соответствует проектным требованиям)
• Самый низкий (1): косметическая ошибка

Приоритет (корректируется на развитие, управление и обеспечение качества при оценке дефектов)

• Наивысший (5): система практически не работает с этим дефектом.
• Высокий (4): дефект будет серьезно влиять на способность компании продавать и обслуживать эту систему.
• Средний (3): Компания потеряет часть денег, если этот дефект присутствует в системе, но, возможно, более важно соблюдать график. Исправить после выпуска.
• Низкий (2): не откладывайте выпуск, но исправьте эту проблему впоследствии.
• Самый низкий (1): исправить, если позволяют время и ресурсы.

Оба числа вместе создают номер приоритета риска (RPN). Просто умножьте серьезность с приоритетом. Более высокий результат означает более высокий риск. 25 определяет окончательный дефект бомбы. 1 можно сделать во время простоя или если кому-то скучно и нужно что-то сделать.

Первая цель: Дефекты с наивысшим или высоким рейтингом любого вида должны быть исправлены до выпуска. Вторая цель: дефекты с RPN> 8 должны быть устранены перед выпуском продукта.

---

Это, конечно, немного искусственно, но помогает дать всем сторонам (поддержка, контроль качества / тестирование, инжиниринг и менеджеры по продуктам) инструмент для определения приоритетов, не нарушая мнение другой стороны.

Answer 4

Замените свою систему отслеживания ошибок на fogbugz и полностью избавьтесь от поля серьезности.

См. Приоритет против серьезности

Answer 5

«Это было сделано».

Я снова и снова обсуждаю разные проекты. Мы пытались объединить приоритет с серьезностью, но урок, который я усвоил: не объединяйте серьезность с приоритетом !

У нас было много мозговых штурмов и встреч, которые закончились словами " вот оно ". Множество руководящих документов было создано и распространено между разными «сторонами», но через некоторое время мы обнаружили, что в конце это не сработало. Различные «стороны» по-разному думают об ошибках: наша служба поддержки имеет другое понимание приоритетов, чем команда разработчиков или отдел продаж.

Наличие как серьезности, так и уровня приоритета очень быстро станет очень запутанным, потому что:

• при использовании чисел (от 1 до 5) никто не будет знать, что означает каждое число
• что, если проблема имеет наивысший возможный приоритет, но наименьшую возможную серьезность - и я уверен, что это произойдет!
• что, если кто-то уменьшает серьезность, ему также нужно уменьшить приоритет?

«Так что же тогда делать?»:

• Используйте только один тип индикатора для «уровня» проблемы: не имеет значения, как вы его называете.

• Используйте цифры (например, 1 - 5, но они могут быть более или менее в зависимости от ваших потребностей), чтобы четко обозначить важность, но объедините с ключевым словом, чтобы было понятно, что оно означает ( например, «приятно иметь», «показать стопор»). Для некоторых людей значение prio 1 означает наибольшее значение, для других 5 ->, поэтому необходимо ключевое слово, указывающее, что означает число.

• Проведите различие между «нормальной проблемой» или «красным предупреждением». В нашем случае «красное оповещение» должно быть немедленно решено и немедленно запущено в производство. Обычная проблема будет следовать нормальному потоку разработки-тестирования-развертывания. Приоритет / серьезность / как бы вы ни звонили, он должен быть установлен только для обычных проблем и будет игнорироваться для «красных предупреждений». *> На практике «Red Alert» может стать

  «Нормальная проблема»: команда поддержки обнаружил серьезную ошибку и создал 'Красная тревога'. Но после некоторого Исследование мы обнаружили, что данные стал «поврежден» в базе данных так как он был вставлен туда напрямую а не через приложение. *

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

Answer 6

• Тестер сообщает, что сломано
• Разработчик оценивает, сколько работы будет исправлено
• Заказчик определяет стоимость бизнеса, то есть приоритет.

Answer 7

Лично я предпочитаю двухуровневую модель серьезности / приоритета. Я знаю аргументы для одного уровня, но в местах, где я работал, я лучше видел двухуровневую иерархию

Серьезность устанавливается командой поддержки (на основе данных от клиента). Приоритет устанавливается клиентом (с участием команды поддержки).

Для серьезности я использую:

1 - блокировка / показ остановлен
2 - Основная функциональность недоступна (или фактически недоступна), практическое обходное решение невозможно
3 - основная функциональность недоступна (или ...), возможен обходной путь
4 - Незначительная функциональность недоступна (или фактически недоступна), обходной путь невозможен
5 - Незначительная функциональность недоступна (или ...), возможен обходной путь
6 - Косметика или другое тривиальное

Тогда для приоритета я просто использую High, Medium, Low, но все, что от 3 до 5 уровней работает (гораздо больше, чем просто выше).

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

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

Answer 8

1. Должно быть сделано сейчас
2. Должно быть сделано до отправки
3. Незначительное раздражение (не мешает пользователю использовать функциональность)
4. Edge case / Remote / сценарий «от Мордора»

Ну, я только что это выдумал ... моя точка зрения на классификацию ошибок не должна быть еженедельным часом + длинный ритуал ..
ИМХО, расстановка приоритетов в соответствии с блок-схемой тратится впустую времени. Исправьте ошибки в Cat # 1 и # 2 - так быстро, как они появляются. Если вы обнаружите, что забиты ошибками, помедленнее и задумайтесь. Отложите категории 3 и 4, если расписание не разрешает или элементы с более высоким приоритетом переопределяются.
Главное, чтобы у всех вас было общее понимание этой серьезности и ожидаемого качества. Не позволяйте соблюдению святых стандартов X, что мешает вам предоставлять то, что хочет заказчик ... рабочее программное обеспечение.

Answer 9

Один из вариантов - заставить владельца продукта определить приоритет ошибки. Хотя существует некоторая общая интуиция о том, насколько «плохая» ошибка, владелец продукта может быть ответственным за установление порядка точности (т. Е. Ошибка A должна быть исправлена ​​до ошибки B и т. Д.).

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

Answer 10

Что касается стандарта, Руководство IEEE по классификации для программных аномалий , хотя я не уверен, насколько широко это принято. IEEE 1044.1-1995