Что такое Severity и Priority? Примеры из жизни

Решил поделиться своими наблюдениями по поводу Severity и Priority в баг-репортах. Забавно, но мало где встретишь Priority, все как-то обходятся Severity, а приоритет упускают. Поэтому захотелось рассказать о некоторых жизненных примерах, где и в каких ситуациях можно использовать «серьёзность (Severity)» и «приоритет» (Priority) в багрепортах.

Что такое Severity и Priority?

Severity

Серьезность (Severity) — это степень негативного влияния дефекта на продукт. Выставляет тестировщик, показывает влияние дефекта на работоспособность приложения.

Градация Серьезности дефекта (Severity)

  • S1 Блокирующая (Blocker) — тестирование заблокировано
  • S2 Критическая (Critical) — важная функция не работает
  • S3 Значительная (Major) — менее важная функция не работает
  • S4 Незначительная (Minor) — проблема несущественна
  • S5 Тривиальная (Trivial) — косметические правки

Priority

Приоритет (Priority) — это порядок в котором дефекты должны быть исправлены. Определяются разработкой и бизнесом (выставляют программисты, PM, TeamLead проекта). Чем выше стоит приоритет, тем скорее нужно исправить дефект.

Градация Приоритета дефекта (Priority)

  • P1 Высокий (High) — исправить немедленно
  • P2 Средний (Medium) — попозже
  • P3 Низкий (Low) – в следующей пятилетке

Зачастую в багтрекинге используется только Severity, что не очень правильно, потому что в ходе анализа бизнесом сроков и времени на разработку, баги с Severity – «Major» могут перейти в «Critical» или даже «Blocker», но по факту такими не являются. К примеру, опечатка может стать блокером, из-за того, что продукт будет вскоре релизиться. Хотя достаточно ввести приоритет и выставить такой баге наивысший приоритет перед релизом.

Почему стоит внедрять Priority?

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

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

Примеры из жизни

Пример 1:

Представим, что у нас не используется приоритет. На проекте есть один мобильный разработчик и два веб-разработчика. В багтрекинге у нас есть два Blocker (для веб разработчиков) и 2 Major (для мобильного разработчика), но у веб-разработчиков есть еще 5 других объемных задач, в то время, как мобильный разработчик сидит в фейсбуке или на ДОУ

По логике вещей, тестировщик будет тестировать сначала блокеры, а потом уже Major. Хотя достаточно ввести приоритетность и каждому из тасков раздать соответствующие приоритеты. Для mobile-разработчика — Major + Hight, для веб разработчиков — Blocker + Medium. В таком случае тестировщик протестует баги с наивысшим приоритетом для mobile-разработчика, а затем уже для веб-разрабочтиков, все будет при деле.

Пример 2:

В ходе тестирования тестировщик нашел дефект, довольно критичный для системы, который закрывает доступ к 10% функционала. Ставит такому багу серьёзность — «Critical». PM видит баг-репорт, анализирует ситуацию (функционал будет рефакториться, сроки поджимают) и ставит приоритет — «Medium» или ниже, а тем вещам, которые будут релизиться уже завтра — приоритет повыше — «High».

Разработчик конечно же при работе с багтрекингом видит приоритет и фиксит багу исключительно по приоритету.

Пример 3:

Представим, что слово или фраза, напечатанное с ошибкой, может иметь один из низких уровней «Severity», но перед выливкой продукта на прод, такая ошибка может иметь наивысший приоритет и должна быть мгновенно пофикшена. Яркий тому пример: на сайте написано «porn» (для SEO — это не очень хорошо), а заменить надо на «adult content».

Такая бага в багтрекинге может даже северити — Blocker получить, хотя по факту такой не является.

Пример 4:

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

Пример 5:

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

По логики вещей такая бага получит скорее всего северити — «Trivial», хотя должен быть «Blocker». В данном случае достаточно будет просто назначить высокий северити и низкий приоритет.

Идеальное решение

  • P1 High
    • S1 Blocker
    • S2 Critical
    • S3 Major
    • S4 Minor
    • S5 Trivial
  • P2 Medium

    • S1 Blocker
    • S2 Critical
    • S3 Major
    • S4 Minor
    • S5 Trivial

Если внедрение Priority повысит эффективность работы команды и внесет ясность в воркфлоу, в багрепорты — смело добавляйте. Если внесет путаницу — оно того не стоит…

Может у вас есть какие-то мысли по этому поводу?

Похожие заметки
Последние заметки
Если вам понравилась статья, вы можете подписаться на RSS или e-mail рассылку. Для получения обновлений по электронной почте, введите ваш e-mail адрес в эту форму (доставка от SmartResponder):

6 комментариев

  1. Александр,
    1

    Интересная информация, надо будет узнать об этом больше...

  2. В нете есть куча видосиков интересных по данной теме, если будут вопросы, пишите :-)

  3. Onlynew,
    3

    Теперь попробую все структурировать-))

  4. Уже все структурировал :-) берите и пользуйтесь...

  5. Александра,
    5

    Информация уникальная и интересная, прошу добавить схемку (скрин из визио или иной) для наглядности взаимодействия процессов , а то читаю и приходится на листике рисовать

  6. Евгений Москаленко,
    6

    Тут больше акцент сделан на вранье в баг-трекинге с Severity и Priority. Тут нет смысла показывать визуально взаимодейстие процессов.

    Скиньте я посмотрю, что такого нарисовали, возможно мне придет в голову что-то интересно и статью дополню...

Оставить комментарий