Принципиальная разница между Severity & Priority
#1
Отправлено 24 июня 2008 - 11:10
Решил поднять вопрос о таких полях в баг репорте, как 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? Как выбрать золотую середину?
Жду ваших ответов.
Про Тестинг
#2
Отправлено 24 июня 2008 - 11:48
вот что я могу сказать по этому поводу:
сам раньше работал с багтреккером в котором было только severity, этим полем задавалась и критичность бага (импрувмента, ЦРа и т.п.), и его приоритет. теперь же я на проекте, где эти поля разделены. честно говоря, поначалу я не въезжал что к чему и какая между ними разница (раньше ведь я с таким разделением не сталкивался). но понаблюдав как работает моя проектная команда с этими понятиями, я чётко усвоил вот что: severity - это критичность бага, именно критичность по отношению к самому приложению; а вот priority - это приоритетность выполнения (фикса, имплементации, инвестигейшна...), т.е. приорити относится не к приложению, а к процессу работы.
пример:
я в ходе тестирования нашёл дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу сиверити "критикал". ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити - "медиум" или ниже.
а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очерёдности выполнения тасков.
вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!
#3
Отправлено 24 июня 2008 - 12:06
Привет!
вот что я могу сказать по этому поводу:
сам раньше работал с багтреккером в котором было только severity, этим полем задавалась и критичность бага (импрувмента, ЦРа и т.п.), и его приоритет. теперь же я на проекте, где эти поля разделены. честно говоря, поначалу я не въезжал что к чему и какая между ними разница (раньше ведь я с таким разделением не сталкивался). но понаблюдав как работает моя проектная команда с этими понятиями, я чётко усвоил вот что: severity - это критичность бага, именно критичность по отношению к самому приложению; а вот priority - это приоритетность выполнения (фикса, имплементации, инвестигейшна...), т.е. приорити относится не к приложению, а к процессу работы.
пример:
я в ходе тестирования нашёл дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу сиверити "критикал". ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити - "медиум" или ниже.
а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очерёдности выполнения тасков.
вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!
Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority - это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.
Например, слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой ).
#4
Отправлено 24 июня 2008 - 12:16
Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Priority - это инструмент менеджера по планированию работ. Чем выше priority, тем быстрее нужно исправить дефект.
Например, слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой ).
- четко сказано!!!Priority - это инструмент менеджера по планированию работ.
Становится ясно, что я сильно заморочился на разнице... А все из-за чего? да вот из-за чего:
есть замечательный трекер 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 могут не понимать эту тонкую разницу между понятиями... Т.к. не имели опыта их совместного использования...
Вот...
Про Тестинг
#5
Отправлено 24 июня 2008 - 12:25
да-да, именно это я и сказал.
2Boltiсk:
я тож раньше с Джирой работал, скажем так - мы вместе с ней работали!.. ;)
но меня нисколько не смущало то, что в Джире эти понятия совмещены в приорити. просто этот параметр мог меняться несколько раз за жизненный цикл бага.
#6
Отправлено 24 июня 2008 - 12:25
#7
Отправлено 24 июня 2008 - 12:42
2Boltiсk:
я тож раньше с Джирой работал, скажем так - мы вместе с ней работали!.. ;)
но меня нисколько не смущало то, что в Джире эти понятия совмещены в приорити. просто этот параметр мог меняться несколько раз за жизненный цикл бага.
В этом то и основная путаница, что оперируя одним параметром, приходится менять Severity (уровень "влияние дефекта на работоспособность приложения") вместо приоритета данного бага... Т.е. минорный баг вдруг становится мажорным или критичным... по-моему это не очень правильно, но т.к. нет другого рычага, то все именно так и делают.
А используя оба параметра? такая величина, как Severity, остается неизменной, меняется лишь приоритет!!! Т.е. управление происходит правильными рычагами...
Вот...
Про Тестинг
#8
Отправлено 24 июня 2008 - 13:56
я в ходе тестирования нашёл дефект, довольно критичный для приложения на мой взгляд т.к. этот дефект закрывает доступ к 20% функционала. ставлю такому багу сиверити "критикал". ПМ видит багрепорт, анализирует ситуацию (поджимающие сроки, этот функционал будет рефакториться или вообще выкидываться в следующей итерации и т.п.) и ставит приорити - "медиум" или ниже.
а девелопер при работе с баг- тасктреккером руководствуется исключительно приорити, т.к. приорити и существует для регулирования очерёдности выполнения тасков.
вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!
Не может severity в статусе критикал иметь приоритет "медиум" или ниже. Конечно, если оценка severity действительно правильная.
#9
Отправлено 24 июня 2008 - 14:02
Может, если у вас есть куча багов с важностью "blocker/critical" вам придется отсортировать эту кучу по приоритету.Не может severity в статусе критикал иметь приоритет "медиум" или ниже. Конечно, если оценка severity действительно правильная.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#10
Отправлено 24 июня 2008 - 15:07
+1Может, если у вас есть куча багов с важностью "blocker/critical" вам придется отсортировать эту кучу по приоритету.Не может severity в статусе критикал иметь приоритет "медиум" или ниже. Конечно, если оценка severity действительно правильная.
Сорвали аналогичный ответ с языка :)
Именно это я имел ввиду, говоря в первоначальном посте:
А вот на больших проектах, где счет открытых багов идет на сотни, наличие одновременно Severity & Priority облегчает жизнь разработчикам при выборе бага на исправление
Про Тестинг
#11
Отправлено 24 июня 2008 - 15:10
Баг по факту является таской на исправление верно? Так вот у таска должен был только один чёткий и понятный до невозможности всем-всем-всем показатель "в какую очередь чиним" - Приоритет.
JIRA рулит :)
Редактор портала www.it4business.ru
#12
Отправлено 24 июня 2008 - 15:16
Кучи критикалов не бывает, а если у вас такая ситуация значит процесс тестирования спланирован не правильно или тестируется та часть приложения которая не готова или не должна тестироваться. Если даже есть несколько критикал багов у них у всех будет приоритет наивысший (например 1).Может, если у вас есть куча багов с важностью "blocker/critical" вам придется отсортировать эту кучу по приоритету.
#13
Отправлено 24 июня 2008 - 15:30
Первая - это оценка важности бага в контексте приложения в целом, и определяется тестировщиком.
Вторая - это неоходимость исправления этого бага в контексте текущего релиза (или мейлстоуна), и устанавливается лицом, отвечающим за релиз, исходя из кучи факторов (популярная оценка состоит из трех факторов - severity, частоты проявления и рисков появления новых проблем при исправлении, плюс цели релиза).
По-моему, так. во всяком случае, это выглядит как работающий процесс.
#14
Отправлено 24 июня 2008 - 15:50
То что JIRA рулит, я даже не буду оспаривать, т.к. сам ее очень ценю и уважаю :)ВОт для того чтобы не торговаться что выше "северити2+приоритет1" или "северити4+приоритет3" и должен остаться только один показатель - Приоритет.
Баг по факту является таской на исправление верно? Так вот у таска должен был только один чёткий и понятный до невозможности всем-всем-всем показатель "в какую очередь чиним" - Приоритет.
JIRA рулит :)
Но, я не согласен, что одной величины Приоритет достаточно. Как я писал, ее может достаточно для небольшого проекта, а вот для очень большого с предполагаемым большим кол-вом багов - НЕТ. Т.к. мы опять получим 100 мажорных багов и неопределенную последовательность их фиксов. Тогда как используя 2 величины мы сужаем очередность, имея теже 100 мажоров, но из них будет 20 high, 30, medium и 50 low...
вот...
Про Тестинг
#15
Отправлено 25 июня 2008 - 04:57
Не рулит. Именно потому, что подаёт себя как "средство управления проектами", мешая всё в какой-то безумный компот -- баги, таски, северити, приоритеты, всё едино.ВОт для того чтобы не торговаться что выше "северити2+приоритет1" или "северити4+приоритет3" и должен остаться только один показатель - Приоритет.
Баг по факту является таской на исправление верно? Так вот у таска должен был только один чёткий и понятный до невозможности всем-всем-всем показатель "в какую очередь чиним" - Приоритет.
JIRA рулит :)
Баг-репорт нисколько не таск. Это прямо из названия видно: баг-репорт -- это рапорт, донос, констатация наличия проблемы. Для устранения проблемы может потребоваться серия изменений, которые должны сделать разные люди в разных местах, так что придётся сделать несколько тасков. Северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска.
Предположим, что тестировщик обнаружил дефект, написал баг-репорт, выставил там высокую северити, потому что приложение падает, если какое-то поле в форме не заполнено. Эксперт рассмотрел этот рапорт, принял решение добавить в приложении проверку поля. Итого -- надо внести изменения в функциональность, а потом ещё и исправить документацию. По факту одного доноса (баг-репорта) менеджер делает два таска и выдаёт первый разработчику, выставляя достаточно высокий приоритет, а второй текрайтеру с низким приоритетом (потому что на форме и так уже будет написано, что поле обязательное, а документацию один фиг никто не читает, но исправить всё таки надо, скриншоты там типа переснять и всё такое).
Но даже если пойти на уступки и считать, что баг-репорт и таск объединены в один артефакт -- зачем же "склеивать" атрибуты? Ещё раз повторю -- северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска. Если уж очень хочется объединить их в один артефакт -- пусть хотя бы останутся разные поля для разных атрибутов.
Уже не раз мне приходилось сталкиваться у наших заказчиков с трекинговыми системами, где не было этого разделения. Изменение этой "приоритетосеверити" его может происходить по двум причинам -- либо пересмотрели степень критичности (например, нашли воркэраунд и понизили критичность), либо пересмотрели степень срочности (падает при нажатии на эту кнопку и фиг с ним, всё равно этой фичей никто пока ещё не пользуется). И эти два разных типа изменений делают разные люди -- эксперт и менеджер. Когда они меняют одно и то же поле -- возникает между ними возня и разборки. Когда разные поля -- всё упрощается, зоны ответственности разделены.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#16
Отправлено 25 июня 2008 - 10:32
Это вообще-то не активности, а характеристики issue. А что и как вы на основе этих характеристик настроите зависит уже от вас.Severity и Priority - это две отдельные активности.
Редактор портала www.it4business.ru
#17
Отправлено 25 июня 2008 - 10:34
Абстрактно нам 100 багов распределять на группы смысла особо-то и нет. На одном девелопере вся 100 не повиснет, верно?Но, я не согласен, что одной величины Приоритет достаточно. Как я писал, ее может достаточно для небольшого проекта, а вот для очень большого с предполагаемым большим кол-вом багов - НЕТ. Т.к. мы опять получим 100 мажорных багов и неопределенную последовательность их фиксов. Тогда как используя 2 величины мы сужаем очередность, имея теже 100 мажоров, но из них будет 20 high, 30, medium и 50 low...
Редактор портала www.it4business.ru
#18
Отправлено 25 июня 2008 - 10:36
Так в этом весь компот и вся прелесть, Леш.Не рулит. Именно потому, что подаёт себя как "средство управления проектами", мешая всё в какой-то безумный компот -- баги, таски, северити, приоритеты, всё едино.
А если идти всё-таки не от названия, а от понятия таск в проектном управлении? :)Баг-репорт нисколько не таск. Это прямо из названия видно: баг-репорт -- это рапорт, донос, констатация наличия проблемы. Для устранения проблемы может потребоваться серия изменений, которые должны сделать разные люди в разных местах, так что придётся сделать несколько тасков. Северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска.
Редактор портала www.it4business.ru
#19
Отправлено 25 июня 2008 - 10:39
Зачем?Но даже если пойти на уступки и считать, что баг-репорт и таск объединены в один артефакт -- зачем же "склеивать" атрибуты? Ещё раз повторю -- северити -- это атрибут дефекта, описанного в баг-репорте, приоритет -- это атрибут таска. Если уж очень хочется объединить их в один артефакт -- пусть хотя бы останутся разные поля для разных атрибутов.
Редактор портала www.it4business.ru
#20
Отправлено 25 июня 2008 - 11:04
Абстрактно нам 100 багов распределять на группы смысла особо-то и нет. На одном девелопере вся 100 не повиснет, верно?Но, я не согласен, что одной величины Приоритет достаточно. Как я писал, ее может достаточно для небольшого проекта, а вот для очень большого с предполагаемым большим кол-вом багов - НЕТ. Т.к. мы опять получим 100 мажорных багов и неопределенную последовательность их фиксов. Тогда как используя 2 величины мы сужаем очередность, имея теже 100 мажоров, но из них будет 20 high, 30, medium и 50 low...
Может и не повиснут, но вот пример из жизни... Проект конечно не лучший с позиции качества, но он был на самом деле:
на проекте - 70 разработчиков, 15 тестеров, длительность всего проект - 2 года. В первом релизе, расчитанном на пол года, выходило порядка 250 ЮзКейсов. Для прохождения было более 2000 тест кейсов. За один прогон всех тест кейсов открывалось примерно 200-300 багов, девелоперы выдавали еженедельные билды с фиксом порядка 100-150 багов, при условии, что не все были задействованы на багфиксы (многие имплементили новые фичи). Получалось, что на каждом разработчике постоянно висело порядка 20-30 багов. Многим везло и у них накапливалось больше 30-ти :)
Согласен, что все это звучит жутко, но такое было... Конечно в итоге, когда имплементация нового заканчивалась, то процесс фикса багов шел быстрее открытия новых... НО всеже, в этой ситуации очень сложно пользоваться одним лишь приоритетом, или я что-то не так понял?
Про Тестинг
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных