Як класифікувати серйозність помилок, щоб доповнити нашу пріоритетну класифікацію?

14

На моїй теперішній роботі у нас є помилки низького, середнього та високого пріоритету.

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

bug issue-tracking

— Ерін
джерело

13

Чому у вас неможливо зрозуміти назви, такі як "низький", "середній" та "високий"? Чому б не використовувати просто реальні слова, такі як "аварія", "корупція", "відомий спосіб вирішення" та "роздратування"?

— С.Лотт

1

Тому що я не маю нічого спільного з називанням пріоритетних рівнів. Я просто отримую використовувати те, що мені дано. Мені подобаються твої імена.

— Ерін

2

У нас 4-й рівень, "Критичний". Це гірше того, що ви класифікуєте як "високий" (наприклад, раптовий збій сервера виробництва).

— FrustratedWithFormsDesigner

1

Я вважаю, що Низький ніколи не використовується ... всі кажуть, що середній, високий або терміновий

— Рейчел

1

@ Thorbjørn Коли помилка потребує більше часу, щоб поставити під відстеження, ніж просто виправити там, коли я помітив це, я схильний просто виправити це. (Майте на увазі, у нас немає формального процесу забезпечення якості, тому ні в кого іншого немає завдання вводити помилки в трекер. Це більше списку "робити пізніше" для нас, ніж черги на роботу від когось іншого.)

— CodexArcanum

23

Ми класифікуємо наші помилки та дефекти відповідно до їх пріоритетності та тяжкості.

Рівень пріоритету - це показник того, наскільки терміново потрібно усунути / виправити проблему (терміново, високо, середньо, низько, немає).

Рівень ступеня тяжкості допомагає нам визначити, яка чи яка шкода може бути заподіяна дефектом (небезпечний / руйнівний, деградуючий та не вирішений, постраждалий, але вирішення існує, неприємність / косметичний, без впливу).

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

— Іскристі
джерело

10

Суворість дійсно є суб'єктивною щодо того, який продукт ви робите, і вашої покупки. На моїй останній роботі ми створили автопілоти для великих контейнерних / круїзних суден, тому наша суворість була

Дуже високо - Айсберг попереду! О, зачекайте, схоже на те, що контроль над судном може бути втрачений або може бути заплутаним хто має контроль! Хтось придумає, як повернути цей корабель !!!
Високий - скарги клієнтів на прийняття, круїзне судно надто швидко обертається, клієнти розливають свої напої. Ми не можемо використовувати ваші речі, поки це не буде виправлено!
Середній - функціональність, яка б покращила простоту використання для клієнтів / польових техніків. Речі, які економить людям час.
Низько - косметичні речі

Я думаю, що рівень серйозності / пріоритетності буде різко різним, якщо ви робите веб-додаток і у вас є зовсім інша модель бізнесу / клієнтська база. Це в кінцевому рахунку про те, що очікують ваші клієнти і як вони сердиться щодо цього питання :)

— Дуг Т.
джерело

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

— gnasher729

@ gnasher729: Яка ваша конкретна незгода? Ви хочете сказати, що косметичну помилку, яка не впливає суттєво на те, скільки часу витрачає клієнт на отримання програмного забезпечення для роботи, слід віднести до категорії важливіших, ніж помилка, яка впливає на це, а не є косметичною? Або те, що? Пріоритети відносні, не абсолютні, і завжди потрібно зробити більше.

— Натан Туггі

0

Критерії суворості, якими я користуюся:

Чи заважає користувачеві отримати те, що він хоче від програми?
Чи це видно, якщо користувач виконує типові завдання?
Чи розкриває вона обґрунтовану інформацію чи дозволяє виконувати несанкціоновані дії?

Тяжкість конкретної помилки - це поєднання цих моментів.

— Микита Барсуков
джерело

1

Також важливою є кількість користувачів, на яких впливає вплив. А які користувачі, якщо ви користуєтеся програмою, мають функції, доступні не всім.

— FrustratedWithFormsDesigner

-1

Класифікуйте помилки за їх фактором роздратування, який може заважати людям купувати програмне забезпечення. Помилка, яка не впливає на доставку або не викликає реальних проблем у користувачів, може дратувати **** кожного разу, коли я натрапляю на помилку. І врешті ви втратили користувача та частину свого доходу.

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

Не дозволяйте цього статися. Не надсилайте помилок, які змушують клієнтів думати, що ви не даєте ****.

— gnasher729
джерело

це навіть не намагається відповісти на поставлене запитання: "Як класифікувати серйозність помилок, щоб доповнити нашу класифікацію пріоритетів?" Дивіться, як відповісти

— gnat