что такое priority в тестировании

24.12.202322.09.2023 admin 0 Comments

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

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

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

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

Порядок исправления ошибок по их приоритетам:

Требования к количеству открытых багов

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

Источник

Серьезность и приоритет дефекта: в чем различие?

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

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

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

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

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

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

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

Источник

Thinking in Tests

Notes about Software Testing and more

Severity vs Priority

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

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

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

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

P1 Высокий (High)

Severity 2 – Critical bug in important function. No reasonable workaround.

Severity 3 – Major bug but has viable workaround.

Severity 4 – Minor bug with trivial impact.

High severity, low priority – Critical impact on user: nuclear missiles are launched by accident. Factor influencing priority: analysis reveals that this defect can only be encountered on the second Tuesday of the first month of the twentieth year of each millennium, and only then if it’s raining and five other failsafes have failed.

Business decision: the likelihood of the user encountering this defect is so low that we don’t feel it’s necessary to fix it. We can mitigate the situation directly with the user.

High severity, low priority – Critical impact on user: when this error is encountered, the application must be killed and restarted, which can take the application off-line for several minutes. Factors influencing priority: (1) analysis reveals that it will take our dev team six months full-time refactoring work fix this defect. We’d have to put all other work on hold for that time. (2) Since this is a mission-critical enterprise application, we tell customers to deploy it in a redundant environment that can handle a server going down, planned or unplanned.

Business decision: it’s a better business investment to make customers aware of the issue, how often they’re likely to encounter it, and how to work through an incidence of it than to devote the time to fixing it.

Low severity, high priority – Minimal user impact: typo. Factors influencing priority. (1) The typo appears prominently on our login screen; it’s not a terribly big deal for existing customers, but it’s the first thing our sales engineers demo to prospective customers, and (2) the effort to fix the typo is minimal.

Источник

Серьезность и приоритет бага – есть ли разница?

У любой ошибки (очевидное несоответствие между реальностью и ожидаемым результатом в поведении ПО) есть определенные атрибуты: «серьезность» и «приоритет» с цифровым или буквенным обозначением.

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

Так, серьезность это больше относится к технической интерпретации вопроса, а приоритетность – к управленческой (менеджерской).

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

Разделение приоритетов и серьезности по уровням

Сегодня приоритеты принято делить на три уровня, а серьезность – на пять.

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

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

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

Допустим, в определенной системе перестал функционировать модуль отчетности. Это баг с номинальным уровнем серьезности – «Блокирующий».

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

Как итог, менеджер проекта запросто устанавливает самый низкий приоритет исправления подобного функционала.

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

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

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

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

Ставьте атрибуты серьезности и приоритетности верно и да пребудет ваше ПО в «добром здравии» и оптимальном функционировании!

Источник