rlabs, мне тоже приходилось, я ж не спорю что так не бывает - именно что бывает и не редко. Вопрос только насколько он нужен? А вот торговли вокруг "мажор+визибилити2" или "минор+визибилити8"?! видеть приходилось. Аналогично и про "северити" и про "импакты" :)
Хорошо. Давайте разберемся.
Берем типового тестировщика. Его задача - узнать, как себя ведет продукт. Он в большинстве случаев взаимодействует с ним "снаружи", то есть без особых технических подробностей. Исходя из знания продукта и особенностей его применения, он оценивает важность обнаруженной проблемы. По большому счету, можно ограничиться тремя степенями: а) юзабилити проблема (надписи в диалоге съехали, комбо-бокс смотрится отвратно), б) функциональная проблема (участок функционала работает неправильно), в) шоустопер (кусок функциональности отвалился).
Теперь проследим путь багрепорта. Мне никогда не приходилось встречаться с продуктами класса "выстрелил и забыл" (один релиз) или "тяни кота за хвост" (веб-приложение, регулярно обновляемое без всяких планов, просто по факту появления нового билда). Так что, за типовой пример принимаем продукт с несколькими релизами. Цель релиза всегда установлена. Я достаточно просто делю релизы на maintenance (подправить немножко продукт, выпустить сервис-пак) и feature (новые возможности, с большой вероятностью будет продаваться отдельно от предыдущего).
Предположим, у нас maintenance релиз. Цель - сделать продукт немножко лучше, и не сделать его хуже. И вот у нас есть, гм, ну, скажем, "менеджер релиза" (здесь реально пересекаются роли configuration manager, release manager, product owner). Я сейчас буду цепляться за упомянутую мной выше схему трех параметров, но, в общем, она хорошо применима. Итак, у нас есть параметры: важность (severity), частота повторения (насколько часто на эту проблему будет наталкиваться "типовой" пользователь), и риск внесения новых проблем. Ответственное лицо смотрит на баг-репорт с важностью "функциональная проблема". Важности достаточно высокая. Анализ на regression (извините, не знаю, как нормально перевести) показывает, что проблема существовала всегда (просто предыдущие раунды тестирования её не выявили). Быстрый анализ записей саппорта показывает, что никто из пользователей за все это время не столкнулся с проблемой. Анализ кода показывает, что для исправления ошибки нужно переписать некоторую подсистему целиком, и это инвалидирует, допустим, 40% функциональности продукта. Какая в этом случае будет оценка приоритетности? Да никакая, можно выставить статус "исправим в следующей пятилетке". Получаем баг-репорт с высокой важностью и низким приоритетом.
Я тут заметил, что ушел куда-то не туда от темы. Так вот, торговли тут быть не может. Есть отдельная объективная оценка проблемы, есть оценка приоритетности в контексте текущих работ.