пример бага с высоким северити и низким приорити
Тестирование
Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Серьезность и Приоритет Дефекта
Серьезность и Приоритет Дефекта
Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как Atlassian 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 не всегда понимают разницу между этими понятиями, так как не имели опыта их совместного использования. Исходя из личного опыта, я настаиваю на разделении этих понятий, а точнее на использовании обоих полей Severity и Priority, так как смысл, вкладываемый в них, различный:
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
Требования к количеству открытых багов
Хотим предложить вам следующий подход к определению требований к количеству открытых багов:
Что такое Severity и Priority? Примеры из жизни
Решил поделиться своими наблюдениями по поводу Severity и Priority в баг-репортах. Забавно, но мало где встретишь Priority, все как-то обходятся Severity, а приоритет упускают. Поэтому захотелось рассказать о некоторых жизненных примерах, где и в каких ситуациях можно использовать «серьёзность (Severity)» и «приоритет» (Priority) в багрепортах.
Что такое Severity и Priority?
Severity
Серьезность (Severity) — это степень негативного влияния дефекта на продукт. Выставляет тестировщик, показывает влияние дефекта на работоспособность приложения.
Градация Серьезности дефекта (Severity)
Priority
Приоритет (Priority) — это порядок в котором дефекты должны быть исправлены. Определяются разработкой и бизнесом (выставляют программисты, PM, TeamLead проекта). Чем выше стоит приоритет, тем скорее нужно исправить дефект.
Градация Приоритета дефекта (Priority)
Зачастую в багтрекинге используется только 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». В данном случае достаточно будет просто назначить высокий северити и низкий приоритет.
Идеальное решение
Если внедрение Priority повысит эффективность работы команды и внесет ясность в воркфлоу, в багрепорты — смело добавляйте. Если внесет путаницу — оно того не стоит…
Может у вас есть какие-то мысли по этому поводу?
Серйозність та пріоритет. Приклади багів з високою серйозністю та низьким пріоритетом і навпаки
Серйозність та пріоритет. Приклади багів з високою серйозністю та низьким пріоритетом і навпаки
Через те,що організації використовують різні види інструментів для відслідковування дефектів і пов’язаних з ними процесів, ці інструменти стають спільною системою відслідковування між різними рівнями керування та технічним персоналом. Кожен баг має такі атрибути,як наприклад «Серйозність(Severity)» та «Пріоритет(Priority)». Іноді буває так, що на перший погляд різниці між цими двома поняттями немає, або ж вона не є очевидною. Проте серйозність відноситься більше до технічної частини, а пріоритет до організаційної.
Серйозність (Severity)
Ступінь серйозності дефекту більше відповідає функціональності, саме тому вона присвоюється тестувальником. Іноді розробники впливають на серйозність бага, але частіше за все, це залежить від тестувальника. Він оцінює,наскільки конкретна функція може впливати на загальне функціонування.
Один із різновидів класифікацій серйозності бага:
Blocker. Блокуюча помилка. З її появою, уся наступна робота з програмою стає неможливою. Для подальшої роботи необхідно усунути помилку.
Critical. Критична помилка. Порушує роботу основного функціоналу продукту,що тестується. Це дефекти які постійно відтворюються і роблять неможливим використання основних функцій програми.
Major. Значний дефект. Він ускладнює роботу основного функціоналу або робить неможливим використання додаткових функцій.
Minor. Незначний дефект. Цей дефект впливає на функціонал системи у відносно малому ступені або має очевидні обхідні шляхи, ускладнює використання додаткових функцій.
Trivial. Тривіальний дефект. Не впливає на функціонал проєкту, але погіршує загальне враження про роботу з продуктом.
Пріоритет (Priority)
Пріоритет (Priority) – це атрибут, який визначає швидкість усунення бага.
Коли йде справа про призначення пріоритету дефекту, хоч ініціатор дефекту призначає його спочатку, фактично він визначається менеджером по продукту. Останній має загальне уявлення про систему,що тестується і про те,як швидко необхідно усунути баг.
Top. Найвищий пріоритет. Призначається екстренним ситуаціям, які дуже негативно впливають на продукт або навіть бізнес компанії, і тим, що вимагають негайного усунення.
High. Високий пріоритет. Призначений для багів,які мають бути усунені у першу чергу.
Normal. Звичайний пріоритет,що визначається за замовчуванням. Призначається багам, які варто усунути у другу чергу, у робочому порядку.
Low. Низький пріоритет. Призначається багам, які не впливають на функціонал. Їх виправлення відбувається у останню чергу за наявності ресурсів та часу.
Частота (Frequency) – це показник кількості клієнтів, які зіштовхуються з цією помилкою. Визначається на основі аналізу алгоритмів і способів взаємодії користувачів:
Як встановити глобальний пріоритет бага (Global Severity)
Для встановлення алгоритму глобального пріоритету необхідно дізнатись частоту,що впливає на пріоритет. А пріоритет і серйозність, у свою чергу, впливають на глобальний пріоритет бага:
Global Severity = F(Priority, Severity), відповідно
Priority = F(BasePriority, Frequency)
Алгоритм визначення глобального пріоритету:
Визначення глобального пріоритету:
| Пріоритет/Серйозність | Blocker | Critical | Minor | Trivial |
| High | Critical | Critical | Minor | Trivial |
| Medium | Critical | Critical | Minor | Trivial |
| Low | Trivial | Trivial |
Відповідно, якщо глобальний пріоритет «Critical», то баг необхідно обов’язково виправити. Дефекти з пріоритетом «Minor» так само необхідно виправити до релізу, проте їх незначна кількість може бути в проєкті. «Trivial» баги можуть зовсім не виправлятись.
Високий пріоритет і низька серйозність
Будь які незначні дефекти серйозності, які можуть безпосередньо впливати на досвід користувача, автоматично переносяться в цю категорію. Сюди ж потрапляють баги, які мали бути виправлені, але які не впливають на додаток.
Кнопки трохи перекривають одна одну. Хоча вони, як і раніше клікабельні, але візуальне уявлення про продукт деформується.
Логотип компанії на головній сторінці містить орфографічну помилку. З точки зору функціональності, це ні на що не впливає, але це впливає на досвід користувача. Цей баг необхідно усунути з високим пріоритетом,навіть якщо він мінімально впливає на продукт.
Висока серйозність і низький пріоритет
Дефект, який виникає у функціональності додатку ( для якого немає обхідного шляху) і не дозволяє користувачу використовувати систему, але рідко використовується кінцевим користувачем.
Домашня сторінка сайту виглядає жахливо у старих браузерах. Перекривається текст або не завантажується логотип. Це перешкоджає функціонуванню продукту і пересуванню користувача, тому серйозність дефекту буде високою. Тим не менш, так як браузер застарілий і кількість відвідувачів незначна,то баг можна розглядати з низьким пріоритетом.
Припустимо, що існує додаток для банкінгу,який правильно вираховує щоденний, щомісячний, квартальний звіти, але з розрахунком річного виникають проблеми. Це помилка високого ступеню серйозності, але з низьким пріоритетом, так як на даний момент функція формування річної звітності не є актуальною. Цей баг може бути виправлений у наступному випуску.
Такі дефекти необхідно виправляти,але не відразу. Це може статись, зокрема у випадку спеціального тестування. Такі помилки зазвичай впливають на функціональність, але спостерігається таке лише при використанні деяких незвичних вхідних параметрів.
Підсумки
Дефекти та розробка програмного забезпечення рухають у тандемі, по мірі росту продукту росте і список його дефектів. Пріоритет і серйозність бага є його ключовими значеннями, у відповідності з якими і призначається виправлення. Тому стає дійсно важливим,щоб тестувальники, розробник і вся команда розуміли правильне визначення та використання обох термінів. У випадку неправильного присвоєння дефекту значень пріоритету і серйозності весь процес виправлення помилки втратить свою ефективність. Це, у свою чергу, може нанести значну шкоду бізнесу та призвести до фінансових втрат. Таким чином, глибоке розуміння пріоритету та серйозності дуже важливе для команди,щоб процвітати та приймати ефективні рішення.
Рекомендовані курси
Онлайн-курс
Про нас
Контакти
Соціальні мережі
Privacy Overview
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
| Cookie | Duration | Description |
|---|---|---|
| cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Analytics». |
| cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category «Functional». |
| cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category «Necessary». |
| cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Other. |
| cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category «Performance». |
| viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.
Принципиальная разница между 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, тем масштабнее негативные последствия данного дефекта.
Выставляя severity тестировщик оценивает влияние дефекта на работоспособность приложения. Чем выше severity, тем масштабнее негативные последствия данного дефекта.
Становится ясно, что я сильно заморочился на разнице. А все из-за чего? да вот из-за чего:
есть замечательный трекер 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 могут не понимать эту тонкую разницу между понятиями. Т.к. не имели опыта их совместного использования.
В этом то и основная путаница, что оперируя одним параметром, приходится менять Severity (уровень «влияние дефекта на работоспособность приложения») вместо приоритета данного бага. Т.е. минорный баг вдруг становится мажорным или критичным. по-моему это не очень правильно, но т.к. нет другого рычага, то все именно так и делают.
А используя оба параметра? такая величина, как Severity, остается неизменной, меняется лишь приоритет. Т.е. управление происходит правильными рычагами.
вот такая практика используется сейчас на моём текущем проекте.
на мой взгляд довольно рационально и гибко!
Не может severity в статусе критикал иметь приоритет «медиум» или ниже. Конечно, если оценка severity действительно правильная.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
Не может severity в статусе критикал иметь приоритет «медиум» или ниже. Конечно, если оценка severity действительно правильная.
Может, если у вас есть куча багов с важностью «blocker/critical» вам придется отсортировать эту кучу по приоритету.
Сорвали аналогичный ответ с языка 🙂
Именно это я имел ввиду, говоря в первоначальном посте:
А вот на больших проектах, где счет открытых багов идет на сотни, наличие одновременно Severity & Priority облегчает жизнь разработчикам при выборе бага на исправление
Может, если у вас есть куча багов с важностью «blocker/critical» вам придется отсортировать эту кучу по приоритету.
По-моему, так. во всяком случае, это выглядит как работающий процесс.
Отчеты о дефектах. Приоритет и Серьезность.
Для начала рассмотрим каждый атрибут в отдельности.
Серьезность
Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.
Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).
Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.
Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.
1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.
Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.
У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.
Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.
Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.
2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.
Как вы могли понять, Серьезность относится к технической части приложения и указывает на то, как сильно ошибка влияет на работоспособность приложения.
Приоритет
Приоритет отличается от Серьезности тем, что указывает когда необходимо исправить ошибку.
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.
На первый взгляд можно подумать, что Приоритет и Серьезность одинаковы, ведь чем серьезней ошибка, тем быстрее её нужно исправить. Но, если глубже рассмотреть эти атрибуты, то можно найти различия.
Например, мы нашли опечатку в слове. Из названия видно, что это ошибка с Незначительной серьезностью и, вроде бы, ее не стоит исправлять в приоритете. Но если это слово находится на главном экране и является частью названия приложения, то, очевидно, что ее необходимо исправить как можно раньше.
Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:
Матрица определения приоритета
Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:
Различия Серьезности и Приоритета
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.