Добрый день
Решил поднять вопрос о таких полях в баг репорте, как Severity & Priority.

В чем принципиальное отличие этих полей, а также аспекты использования их?

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

В недавней дискуссии с моим коллегой я пришел к выводу, что для небольших проектов можно и не заморачиваться на счет использования совместно Severity & Priority. Достаточно одно из них, но какое? А вот на больших проектах, где счет открытых багов идет на сотни, наличие одновременно Severity & Priority облегчает жизнь разработчикам при выборе бага на исправление. НО по какому полю ему ориентироваться в первую очередь? Или есть смысл ввести еще одно поле, показывающее нечто среднее - "коэффициент критичности"?

Вопросы задал, теперь скажу, что в данный момент я думаю сам.

Мне симпатична следующая система координат (допускаю, что я запутался в этих понятиях, но лучше меня переубедят чем я буду думать неправильно):
Severity: S1-blocker, S2-critical, S3-major, S4-minor, S5-trivial
Priority: P1-High, P2-medium, P3-low

Так же я считаю, что Severity это поле, характеризующее именно баг, а Priority характеризует критичность функционала, на который этот баг написан. Т.е. в этом случае, разработчик делает фильтр по Priority и Severity и сначала решает проблемы P1->P2->P3, но тут же неувязка, что будет важнее бага с P1&S5 или с P2&S1? Как выбрать золотую середину?

Жду ваших ответов.

Привет!

вот что я могу сказать по этому поводу:
сам раньше работал с багтреккером в котором было только severity, этим полем задавалась и критичность бага (импрувмента, ЦРа и т.п.), и его приоритет. теперь же я на проекте, где эти поля разделены. честно говоря, поначалу я не въезжал что к чему и какая между ними разница (раньше ведь я с таким разделением не сталкивался). но понаблюдав как работает моя проектная команда с этими понятиями, я чётко усвоил вот что: severity - это критичность бага, именно критичность по отношению к самому приложению; а вот priority - это приоритетность выполнения (фикса, имплементации, инвестигейшна...), т.е. приорити относится не к приложению, а к процессу работы.

пример:
я в ходе тестирования нашёл дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу сиверити "критикал". ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити - "медиум" или ниже.
а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очерёдности выполнения тасков.

вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!

(IMG:style_emoticons/default/good.gif)

Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.

Priority - это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.

Например, слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой (IMG:style_emoticons/default/acute.gif) ).

(IMG:style_emoticons/default/good.gif) - четко сказано!!!

Становится ясно, что я сильно заморочился на разнице... А все из-за чего? да вот из-за чего:
есть замечательный трекер JIRA. Там по умолчанию, начиная с какой-то древней версии вместо одновременного использования Severity & Priority, оставили только Priority, которое собрало в себе свойства обоих полей: Originally, JIRA did have both a Priority and a Severity field. The Severity field was removed for a number of reasons...

Т.е. те кто привык работать с JIRA могут не понимать эту тонкую разницу между понятиями... Т.к. не имели опыта их совместного использования...

Вот...

2Green:
да-да, именно это я и сказал. (IMG:style_emoticons/default/dirol.gif)

2Boltiсk:
я тож раньше с Джирой работал, скажем так - мы вместе с ней работали!.. ;)
но меня нисколько не смущало то, что в Джире эти понятия совмещены в приорити. просто этот параметр мог меняться несколько раз за жизненный цикл бага.

del

В этом то и основная путаница, что оперируя одним параметром, приходится менять Severity (уровень "влияние дефекта на работоспособность приложения") вместо приоритета данного бага... Т.е. минорный баг вдруг становится мажорным или критичным... по-моему это не очень правильно, но т.к. нет другого рычага, то все именно так и делают.

А используя оба параметра? такая величина, как Severity, остается неизменной, меняется лишь приоритет!!! Т.е. управление происходит правильными рычагами...

Вот...

Не может severity в статусе критикал иметь приоритет "медиум" или ниже. Конечно, если оценка severity действительно правильная.

Может, если у вас есть куча багов с важностью "blocker/critical" вам придется отсортировать эту кучу по приоритету.

+1

Сорвали аналогичный ответ с языка :)

Именно это я имел ввиду, говоря в первоначальном посте:

ВОт для того чтобы не торговаться что выше "северити2+приоритет1" или "северити4+приоритет3" и должен остаться только один показатель - Приоритет.

Баг по факту является таской на исправление верно? Так вот у таска должен был только один чёткий и понятный до невозможности всем-всем-всем показатель "в какую очередь чиним" - Приоритет.

JIRA рулит :)

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

Severity и Priority - это две отдельные активности.
Первая - это оценка важности бага в контексте приложения в целом, и определяется тестировщиком.
Вторая - это неоходимость исправления этого бага в контексте текущего релиза (или мейлстоуна), и устанавливается лицом, отвечающим за релиз, исходя из кучи факторов (популярная оценка состоит из трех факторов - severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).

По-моему, так. во всяком случае, это выглядит как работающий процесс.

То что JIRA рулит, я даже не буду оспаривать, т.к. сам ее очень ценю и уважаю :)
Но, я не согласен, что одной величины Приоритет достаточно. Как я писал, ее может достаточно для небольшого проекта, а вот для очень большого с предполагаемым большим кол-вом багов - НЕТ. Т.к. мы опять получим 100 мажорных багов и неопределенную последовательность их фиксов. Тогда как используя 2 величины мы сужаем очередность, имея теже 100 мажоров, но из них будет 20 high, 30, medium и 50 low...

вот...

Не рулит. Именно потому, что подаёт себя как "средство управления проектами", мешая всё в какой-то безумный компот -- баги, таски, северити, приоритеты, всё едино.

Баг-репорт нисколько не таск. Это прямо из названия видно: баг-репорт -- это рапорт, донос, констатация наличия проблемы. Для устранения проблемы может потребоваться серия изменений, которые должны сделать разные люди в разных местах, так что придётся сделать несколько тасков. Северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска.

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

Но даже если пойти на уступки и считать, что баг-репорт и таск объединены в один артефакт -- зачем же "склеивать" атрибуты? Ещё раз повторю -- северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска. Если уж очень хочется объединить их в один артефакт -- пусть хотя бы останутся разные поля для разных атрибутов.

Уже не раз мне приходилось сталкиваться у наших заказчиков с трекинговыми системами, где не было этого разделения. Изменение этой "приоритетосеверити" его может происходить по двум причинам -- либо пересмотрели степень критичности (например, нашли воркэраунд и понизили критичность), либо пересмотрели степень срочности (падает при нажатии на эту кнопку и фиг с ним, всё равно этой фичей никто пока ещё не пользуется). И эти два разных типа изменений делают разные люди -- эксперт и менеджер. Когда они меняют одно и то же поле -- возникает между ними возня и разборки. Когда разные поля -- всё упрощается, зоны ответственности разделены.

Это вообще-то не активности, а характеристики issue. А что и как вы на основе этих характеристик настроите зависит уже от вас.

Абстрактно нам 100 багов распределять на группы смысла особо-то и нет. На одном девелопере вся 100 не повиснет, верно?

Знал же, что нельзя влазить в эту тему :)

Так в этом весь компот и вся прелесть, Леш.

А если идти всё-таки не от названия, а от понятия таск в проектном управлении? :)

Зачем?

Может и не повиснут, но вот пример из жизни... Проект конечно не лучший с позиции качества, но он был на самом деле:
на проекте - 70 разработчиков, 15 тестеров, длительность всего проект - 2 года. В первом релизе, расчитанном на пол года, выходило порядка 250 ЮзКейсов. Для прохождения было более 2000 тест кейсов. За один прогон всех тест кейсов открывалось примерно 200-300 багов, девелоперы выдавали еженедельные билды с фиксом порядка 100-150 багов, при условии, что не все были задействованы на багфиксы (многие имплементили новые фичи). Получалось, что на каждом разработчике постоянно висело порядка 20-30 багов. Многим везло и у них накапливалось больше 30-ти :)
Согласен, что все это звучит жутко, но такое было... Конечно в итоге, когда имплементация нового заканчивалась, то процесс фикса багов шел быстрее открытия новых... НО всеже, в этой ситуации очень сложно пользоваться одним лишь приоритетом, или я что-то не так понял?