Перейти к содержимому

Фотография

Принципиальная разница между Severity & Priority


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 83

#1 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 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? Как выбрать золотую середину?

Жду ваших ответов.
  • 0
Алексей Булат
Про Тестинг

#2 Lugg3r

Lugg3r

    Новый участник

  • Members
  • Pip
  • 13 сообщений
  • ФИО:Воронович Александр

Отправлено 24 июня 2008 - 11:48

Привет!

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

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

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

#3 Green

Green

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 233 сообщений
  • ФИО:Гринкевич Сергей
  • Город:Москва

Отправлено 24 июня 2008 - 12:06

Привет!

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

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

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


:blush:

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

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

Например, слово, напечатанное с ошибкой, может иметь самый низкий уровень severity, но перед выпуском продукта "в свет" эта ошибка может иметь наивысший приоритет и должна быть экстренно исправлена (если вдруг окажется, что на вашем интернет портале имя владельца компании напечатано с ошибкой :dirol: ).
  • 1
Гринкевич Сергей

#4 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 июня 2008 - 12:16

:blush:

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

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

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


Priority - это инструмент менеджера по планированию работ.

:focus: - четко сказано!!!

Становится ясно, что я сильно заморочился на разнице... А все из-за чего? да вот из-за чего:
есть замечательный трекер 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 могут не понимать эту тонкую разницу между понятиями... Т.к. не имели опыта их совместного использования...

Вот...
  • 0
Алексей Булат
Про Тестинг

#5 Lugg3r

Lugg3r

    Новый участник

  • Members
  • Pip
  • 13 сообщений
  • ФИО:Воронович Александр

Отправлено 24 июня 2008 - 12:25

2Green:
да-да, именно это я и сказал. :dirol:

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

#6 Lugg3r

Lugg3r

    Новый участник

  • Members
  • Pip
  • 13 сообщений
  • ФИО:Воронович Александр

Отправлено 24 июня 2008 - 12:25

del
  • 0

#7 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 июня 2008 - 12:42

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


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

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

Вот...
  • 0
Алексей Булат
Про Тестинг

#8 Troubleshooter

Troubleshooter

    Опытный участник

  • Members
  • PipPipPipPip
  • 398 сообщений
  • Город:Киев

Отправлено 24 июня 2008 - 13:56

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

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


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

#9 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 24 июня 2008 - 14:02

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

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

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#10 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 июня 2008 - 15:07

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

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

+1

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

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

А вот на больших проектах, где счет открытых багов идет на сотни, наличие одновременно Severity & Priority облегчает жизнь разработчикам при выборе бага на исправление


  • 0
Алексей Булат
Про Тестинг

#11 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 24 июня 2008 - 15:10

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

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

JIRA рулит :)
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#12 Troubleshooter

Troubleshooter

    Опытный участник

  • Members
  • PipPipPipPip
  • 398 сообщений
  • Город:Киев

Отправлено 24 июня 2008 - 15:16

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

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

#13 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 24 июня 2008 - 15:30

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

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

#14 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 24 июня 2008 - 15:50

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

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

JIRA рулит :)

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

вот...
  • 0
Алексей Булат
Про Тестинг

#15 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 25 июня 2008 - 04:57

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

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

JIRA рулит :)

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

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

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

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

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

#16 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 июня 2008 - 10:32

Severity и Priority - это две отдельные активности.

Это вообще-то не активности, а характеристики issue. А что и как вы на основе этих характеристик настроите зависит уже от вас.
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#17 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 июня 2008 - 10:34

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

Абстрактно нам 100 багов распределять на группы смысла особо-то и нет. На одном девелопере вся 100 не повиснет, верно?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#18 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 июня 2008 - 10:36

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

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

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

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

А если идти всё-таки не от названия, а от понятия таск в проектном управлении? :)
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#19 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

Отправлено 25 июня 2008 - 10:39

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

Зачем?
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#20 Boltick

Boltick

    Специалист

  • Members
  • PipPipPipPipPip
  • 596 сообщений
  • ФИО:Алексей
  • Город:планета Земля

Отправлено 25 июня 2008 - 11:04

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

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


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


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных