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

Question

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

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

Answer 1

Я согласен с людьми из FogBugz, что это должно быть очень простым: http://fogbugz.stackexchange.com/questions/352/priority-vs-severity

Я составил эту схему, которую легко запомнить:

• pS: секунды имеют значение, например, сервер горит
• pM: минуты имеют значение, например, что-то сломано
• pH: часы имеют значение, т. Е. Не ложитесь спать, пока это не будет сделано
• pd: дни имеют значение, т. Е. Обычный приоритет
• pw: недели имеют значение, то есть с более низким приоритетом
• вечера: месяцы имеют значение, т. Е. Не спешите
• py: годы имеют значение, т. Е. Может быть / когда-нибудь, т. Е. Список пожеланий

Это примерно соответствует схеме Debian: http://www.debian.org/Bugs/Developer#severities

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

PS: Вы также можете выбрать промежуточные срочности, такие как «pMH», для промежутков между «значениями минут» и «значениями часов». Или «pHd» находится между «важными часами» и «важными днями» - грубо говоря, «буквально не тяните за это всю ночь, но не работайте ни над чем другим, пока это не будет сделано».

Answer 2

Я думаю, что это шкала, которую мы использовали на предыдущей работе:

1. Вызывает потерю файлов или нестабильность системы.
2. Сбой программы.
3. Функция не работает.
4. Функция не работает, но есть обходные пути.
5. Косметический выпуск.
6. Запрос на улучшение.

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

Answer 3

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

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

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

Answer 4

Я использую следующие категории как для функций, так и для ошибок:

1. Showstopper, программа (или основная функция) не будет работать
2. Должно быть, значительная часть клиентов будет обеспокоена этим
3. Было бы, некоторые клиенты будут беспокоиться
4. Приятно иметь, это хотят несколько клиентов

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

Answer 5

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