какую серьезность severity необходимо присвоить отчету о дефекте

Что такое 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 необходимо присвоить отчету о дефекте

Что пишут в блогах

I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:

Онлайн-тренинги

Что пишут в блогах (EN)

Introduction

Разделы портала

Про инструменты

Автор: Андрей Петров

У каждого дефекта (несоответствие между реальным и ожидаемым поведением системы) есть атрибуты: «Серьезность» и «Приоритет» с указанием цифрового или буквенного значения. Однако, разница между этими двумя понятиями бывает не до конца ясна. Так, серьезность относится к технической стороне вопроса, а приоритет – к менеджерской. Чтобы внести ясность, предлагаю посмотреть на формальные определения, которые на данный момент приняты в стандартах тестирования и используются повсеместно.

На сегодняшний день, приоритет принято разделять на три уровня, а серьезность – на пять:

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

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

Но зачем нужно это деление, разве нельзя обойтись только одним атрибутом, например, серьезностью? Предположим, в некой системе не работает модуль отчетности. Это –дефект с уровнем серьезности «Блокирующий». Однако этот модуль потребуется только в конце отчетного периода (перед Новым Годом). Если сейчас лето, то данная функциональность не будет использоваться еще несколько месяцев. Как следствие, руководитель проекта или лицо, принимающее решение, может проставить низкий приоритет исправления.

Обратная ситуация: на лицевой странице сайта (или интерфейса приложения) неправильно отображается какая-то важная надпись/логотип (например, название Компании). Данный дефект способен сильно ударить по доверию пользователей к продукции, которую им предлагают: потенциальные клиенты могут подумать, что качество услуг весьма сомнительно, раз даже в названии компании присутствует дефект – и отказаться от использования продукта. С точки зрения подхода к качеству, даже нефункциональные дефекты с уровнем серьезности «Тривиальный» способны отрицательно повлиять на репутацию Компании. Поэтому такому дефекту может быть проставлен высокий приоритет исправления.

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

Источник

Тестирование

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Серьезность и Приоритет Дефекта

Серьезность и Приоритет Дефекта

Разные системы баг трекинга предлагают нам разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. Все знают такой баг-трекер, как 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) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.

Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).

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

Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.

1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.

Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.

У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.

Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.

Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.

2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.

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

Приоритет

Приоритет отличается от Серьезности тем, что указывает когда необходимо исправить ошибку.

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

С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.

На первый взгляд можно подумать, что Приоритет и Серьезность одинаковы, ведь чем серьезней ошибка, тем быстрее её нужно исправить. Но, если глубже рассмотреть эти атрибуты, то можно найти различия.

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

Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:

Матрица определения приоритета

Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:

Различия Серьезности и Приоритета

Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.

Источник

Серьезность и приоритет багов — в чем разница?

Для отслеживания багов в программах используются различные инструменты. В крупных компаниях эти инструменты объединяются в общую систему, которой пользуется много сотрудников. И все эти люди должны как-то ориентироваться в срочности работы над багами.

Поэтому баги, внесенные в системы отслеживания (bug-tracking системы), дифференцируются.

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

Серьезность (Severity) бага

Severity — это атрибут, характеризующий влияние бага на общую функциональность тестируемого продукта.

Степень серьезности бага больше касается функциональности, поэтому она присваивается тестировщиком. Именно он чаще всего оценивает, насколько конкретная функция может влиять на общую работу тестируемого продукта.

Пример классификации серьезности багов:

Приоритет (Priority) бага

Приоритет — атрибут, определяющий скорость устранения бага.

Приоритет бага сперва определяет инициатор, но в дальнейшем он корректируется менеджером продукта. Именно менеджер имеет общее представление о тестируемой системе и понимает, насколько срочно нужно исправить тот или иной баг.

Также нужно упомянуть о частоте проявления бага.

Частота (Frequency) — это показатель количества пользователей, которые сталкиваются с ошибкой. Определяется при анализе алгоритмов.

Глобальный приоритет бага (Global Severity)

Для определения глобального приоритета необходимо определить частоту проявления бага. Частота влияет на приоритет, а приоритет и серьезность влияют на глобальный приоритет бага.

Таким образом, для определения глобального приоритета бага нужно:

Если частота у бага высокая, приоритет возрастает на одну позицию. Скажем, если изначально приоритет был Normal, но частота высокая, приоритет определяется как High.

Средняя частота бага меняет приоритет только с низкого на обычный.

Низкая или незначительная частота вообще не меняет приоритет бага.

Для определения глобального приоритета можно пользоваться следующей таблицей:

Если глобальный приоритет — Critical, значит, баг нужно непременно исправить. Баги с приоритетом Minor тоже желательно исправить до релиза, хотя некоторое количество таких дефектов может остаться в проекте. Баги с приоритетом Trivial могут вообще не исправляться.

Высокий приоритет и низкая серьезность

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

Высокая серьезность и низкий приоритет

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

Итоги

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

Источник