пример бага с низким приоритетом и высокой серьезностью
Что такое 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) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. Проставляется специалистом по тестированию.
Серьезность имеет несколько параметров в зависимости от типа дефекта. Ее степень зависит от того, как она влияет на бизнес-логику (реализацию правил программы).
Из описания видно, что с помощью Серьезности мы указываем как найденная ошибка влияет на тестируемое приложение. Если из-за ошибки приложение полностью не работает, то Серьезность высокая. Если найденный дефект мало влияет на функционал и больше относится к визуальной части (например, опечатка в слове), то Серьезность низкая.
Давайте рассмотрим несколько примеров проблем и попробуем правильно определить их Серьезность. Чтобы было понятно, представим, что мы тестируем приложение по заказу такси.
1.Приложение «падает» при попытке найти свободное такси.
Чтобы правильно поставить Серьезность, необходимо определить влияние ошибки на дальнейшую работу функционала. Из названия видно, что после появления ошибки приложение перестает работать. Значит, влияние высокое.
Сразу же отбрасываем Тривиальную и Незначительную Серьезность, так как из их описания понятно, что ошибка не должна сильно влиять на приложение.
У нас остается только три варианта: Значительная, Критическая и Блокирующая серьезности.
Подходит ли нам Значительная Серьезность? Очевидно, что нет. Во-первых, ошибка достаточно критична. Во-вторых, другим способом найти такси мы не можем, т.е. нет возможности работы с тестируемой функцией, используя другие входные точки. Более того, функционал работает не некорректно, а не работает вообще.
Остаются Критическая и Блокирующая серьезности. В нашем случае Блокирующая подходит больше, так как часть функционала не работает и нет других возможностей найти такси. Следовательно, мы выставляем Блокирующую Серьезность.
2. Невозможно указать адрес назначения с помощью “Указать на карте”.
Снова начинаем рассуждать. Тривиальная и Незначительная не подходят, потому что ошибка в какой-то мере нарушают бизнес логику работы приложения. Блокирующую можно не брать, т.к. функционал в целом работает и его можно использовать через другую точку входа, а именно ввести адрес вручную. Остается только два варианта: Критическая и Значительная. Мы уже сказали, что проблема не приводит к полной неработоспособности части функционала. Тем не менее это значительная ошибка, т.к. функционал частично не работает, следовательно остается только вариант Значительная. Его мы и укажем.
Как вы могли понять, Серьезность относится к технической части приложения и указывает на то, как сильно ошибка влияет на работоспособность приложения.
Приоритет
Приоритет отличается от Серьезности тем, что указывает когда необходимо исправить ошибку.
Приоритет (Priority) – это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Проставляется руководителем или менеджером проекта.
С помощью приоритета менеджер проекта говорит, когда стоит исправить найденную проблему.
На первый взгляд можно подумать, что Приоритет и Серьезность одинаковы, ведь чем серьезней ошибка, тем быстрее её нужно исправить. Но, если глубже рассмотреть эти атрибуты, то можно найти различия.
Например, мы нашли опечатку в слове. Из названия видно, что это ошибка с Незначительной серьезностью и, вроде бы, ее не стоит исправлять в приоритете. Но если это слово находится на главном экране и является частью названия приложения, то, очевидно, что ее необходимо исправить как можно раньше.
Приоритет определяется исходя из масштабности проблем для пользователей и продукта. Для понимая можно использовать матрицу:
Матрица определения приоритета
Теперь, когда мы разобрались что означает каждый атрибут, давайте посмотрим в чем их различие:
Различия Серьезности и Приоритета
Если остались вопросы по определению параметров Серьезность и Приоритет, то задавайте их в комментариях к статье.
Серьезность и приоритет: обзор дефектов высокого и низкого приоритета
Так как все продуктовые компании могут и, скорее всего, используют совершенно разные инструменты для отслеживания и фиксирования багов и связанных с ними процессов, такое программное обеспечение со временем становится общепринятой системой мониторинга между различными уровнями менеджмента и техническим персоналом.
Каждый дефект содержит набор определенных атрибутов, к примеру «серьезность» и «приоритет». Порой, понять различие между этими терминами бывает не совсем просто, но разбираться в этом должен каждый уважающий себя QA-инженер.
Серьезность и приоритет
Что такое серьезность бага и как ее правильно определить?
Severity (серьезность) — это специальный атрибут, по которому можно быстро охарактеризовать уровень технического влияния дефекта на суммарную функциональность проверяемого программного обеспечения.
Каждая степень серьезности бага в большей мере соответствует функциональности ПО, а значит, ее дефекту присваивает исключительно тестировщик.
Порой, программисты могут принимать непосредственное участие в степени определения серьезности дефекта, но в целом, данный процесс — исключительно на совести QA-инженеров. Именно тестировщик должен оценивать, насколько конкретная функция продукта может влиять на общую работоспособность системы.
Серьезность бага можно классифицировать по следующим критериям:
Понятие приоритета
Priority (приоритет) — атрибут, который может определить скорость разрешения проблемы (исправление бага).
Когда говорится об установке приоритета бага, подразумевается, что данной работой занимается исключительно менеджер проекта.
Есть несколько классификаций видов приоритизации:
Рекомендации о том, как установить глобальный приоритет дефекту
Чтобы смело выполнять работы по приоритизации багов, стоит понимать в частоте, которая, в первую очередь, влияет на приоритет. А вот серьезность и приоритет непосредственным образом влияют на глобальный приоритет найденного дефекта.
Формула определения выглядит следующим образом:
Global Severity = F(Priority, Severity)
Priority = F(BasePriority, Frequency)
В форме таблицы это можно отобразить таким образом:
| Частота | Изменение приоритета |
|---|---|
| Высокая | Низкая = Средняя Средняя = Высокая |
| Средняя | Низкая = Средняя |
| Низкая/Очень низкая | Остается без изменений |
Выводы
Баги и процесс создания программного обеспечения движутся всегда в тандеме; по мере продвижения запуска продукта разрастается и перечень найденных дефектов.
Серьезность и приоритет ошибки являются наиболее ключевыми значениями, на основе которых строится методология и процесс исправления ошибок.
Это означает, что проектная группа и отдел тестирования должны правильно понимать и применять данные термины.
Неверное присвоение багу значения по приоритету или серьезности может снизить общий процесс эффективности исправления ошибок.
Студия готового дизайна GS studio
Login
В статье поговорим о процедуре определения приоритетности дефекта (бага) и влияние этой характеристики на:
— приоритизацию работ над проектом в целом;
— проведение и завершение приемо-сдаточных работ;
— завершение проекта и сопутствующие активности.
Замечу сразу, приведенная процедура не является универсальной для практического применения.
На что влияет приоритет бага
Приоритет — это один из ключевых атрибутов бага, который в первую очередь влияет на:
1) Качественный показатель продукта в целом и/или его компонентов. Оперируя нижеприведенными свойствами, возможен сбор необходимых метрик, которые определяют показатели качества продукта на текущей стадии его жизненного цикла:
— количество багов соответствующих приоритетов;
— показатели комплексности/сложности функционала;
— статистика распределения багов по функциональным модулям;
— временные характеристики процесса тестирования (например, для формализации Zero Bug Bounce, Code Freeze etc);
— прочие аналогичные данные.
2) Готовность продукта на текущей стадии разработки. Отталкиваясь от показателей качества продукта (см. пункт выше), могут формализироваться метрики или критерии, определяющие готовность продукта на текущей стадии разработки.
3) Готовность завершения работ по тестированию. Для определения этой метрики нужны показатели качества продукта, в основе которых лежит информация о приоритетности существующих багов.
4) Приоритизацию текущих задач по разработке. В зависимости от профиля текущих багов (их приоритетности и количеству в отношении к существующим ресурсам), необходимо корректировать последовательность задач на ближайшие этапы разработки.
5) Готовность к проведению приемо-сдаточных работ, демонстраций, сдачи проекта в производственную эксплуатацию.
Для разных моделей разработок (аутсорс, продукт, freelance) подходы к определению приоритетности багов будут существенно отличаться, как и степень фактического их влияния на ключевые аспекты разработки, которые перечислены выше. Данное влияние будет рассмотрено далее.
Глобальный приоритет (Global Severity)
Глобальный приоритет (Global Severity) бага определяется составляющими:
— Серьезность (Severity) — свойство тестового артефакта, характеризующее влияние артефакта на работоспособность приложения. Является характеристикой, определяемой с точки функциональности.
— Приоритет (Priority)— свойство тестового артефакта, влияющее на очередность выполнения задачи или устранения дефекта. Является характеристикой, определяемой с точки зрения бизнеса.
— Частота (Frequency) — свойство тестового артефакта, характеризующее частоту (%) возникновения при использовании приложения конечными пользователями. Является характеристикой, определяемой с точки зрения пользовательских сценариев использования продукта.
Таким образом, глобальный приоритет определяется на основании значений трёх свойств:
globalSeverity = F(Priority, Severity, Frequency).
Далее рассмотрим более подробно данную зависимость и уточним ее.
Принцип определения составляющих свойств
1) Серьезность (Severity)
Определяется QA специалистом, Lead QA или Team Lead после анализа требований, программного продукта и специфики конкретной проблемы:
Blocker — дефект относится к критичной (с точки зрения работоспособности) функциональности или критичным данным. У пользователя нет возможности выполнить целевое действие другими способами.
Примеры:
— Нет возможности залогиниться, зарегистрироваться;
— Нет возможности получить доступ как целевым данным, целевым разделам приложения;
— Происходит краш приложения на конкретном окружении.
Critical — дефект относится к важной (с точки зрения работоспособности) функциональности или важным данным. Пользователь может выполнить целевое действие обходным путем, но он (путь) не очевиден.
Примеры:
— Падения (crash) приложения;
— Исключения (exeptions) в процессе работы с приложением;
— Не работоспособность функционала на одном из доступных пользователю окружениях;
— Несанкционированный доступ к данным/функциональности.
Major — дефект относится к не приоритетной (с точки зрения работоспособности) функциональности или не приоритетным данным. Есть очевидный и простой обходной путь выполнения целевой функциональности.
Примеры:
— Дефекты имеющие вероятностный характер возникновения;
— Исключения (exceptions) не влияющие на результат выполнения целевого действия;
— Проблемы, влияющие на скорость использования приложения и продуктивность целевых действий пользователя;
— Визуальные несоответствия;
— Ошибки важного (например, продающего) контента и/или графической информации.
Trivial — дефект не относится напрямую к функциональности и данным. Нет необходимости в обходных путях для выполнения целевого действия. Не влияет на продуктивность, скорость использования приложения.
Пример:
— Небольшие расхождения верстки с макетами;
— Орфографические ошибки в не приоритетном контенте;
— Несущественые улучшения UI, UX.
В данной методике рассматривается модель Severity. В зависимости от специфики вашего проекта или процессов, могут быть использованы альтернативные модели. Например, данную модель Severity можно расширить такими уровнями градации, как average (normal) и minor.
2) Приоритет (Priority)
Определяется менеджером (PM/PO) проекта на основании влияния проблемы на бизнес задачи/цели программного продукта:
— Высокий (High): дефект должен быть исправлен как можно скорее, так как он влияет на наиболее критичный с точки зрения бизнеса функционал.
— Средний (Medium): дефект должен быть обязательно исправлен, так как он влияет на важный с точки зрения бизнеса функционал. Однако исправление может быть отложено до ближайших этапов/спринтов разработки.
— Низкий (Low): дефект не обязателен к исправлению, так как он не влияет на важный с точки зрения бизнеса функционал и ее исправление может быть отложено до момента появления ресурсов.
3) Частота (Frequency)
Определяется специалистом по маркетингу или заказчиком проекта на основании анализа поведенческих паттернов конечных пользователей:
— Высокая (High): более 80% конечных пользователей сталкиваются с проблемой.
— Средняя (Medium): менее 80%, но более 30% конечных пользователей сталкиваются с проблемой.
— Низкая (Low): менее 30%, но более 10% конечных пользователей сталкиваются с проблемой.
— Незначительная (Very low): менее 10% конечных пользователей сталкиваются с проблемой.
Алгоритм определения глобального приоритета
1. Первоначально изолировано от других факторов определяем серьезность дефекта (Blocker, Critical, Minor, Trivial).
2. Независимо от серьезности, определяем приоритет дефекта (High, Medium, Low).
3. Независимо от серьезности и приоритета, определяем частоту дефекта (High, Medium, Low, Very low).
4. Далее рассчитываем влияние частоты на первоначально определенный приоритет:
| Частота | Изменение приоритета |
| High | Medium —> High Low —> Medium |
| Medium | Low —> Medium |
| Low | не изменяется |
| Very low | не изменяется |
5. Наконец, рассчитываем глобальный приоритет:
| Приоритет/Серьезность | Blocker | Critical | Minor | Trivial |
| High | Critical | Critical | Minor | Trivial |
| Medium | Critical | Critical | Minor | Trivial |
| Low | Trivial | Trivial |
— Critical — обязательно к исправлению. Сдача проекта не возможна с наличием данных дефектов.
— Minor — допустимо в небольшом количестве. Сдача проекта не желательна с наличием данных дефектов, однако возможна с некоторым их наличием.
— Trivial — сдача проекта возможна с наличием данных дефектов.
Процедура определения приемо-сдаточных критериев
Традиционно, в разных методологиях управления проектами существуют понятия Acceptance Criteria и Done Criteria — как для продукта в целом, так и для его отдельных релизов. Работа с баг-репортом как документом, несущим основную информацию о качественных характеристиках программного продукта, именно на конечном этапе итерации (sprint, milestone и т.п) несет особое значение:
— Acceptance Criteria являются основой для написания тестовых сценариев (чеклистов, тест-кейсов, end-to-end сценариев etc);
— Done Criterias активно использует баг-репорты для формирования оценки, характеризующей степень соответствия продукта ранее заявленным требованиям.
В вышеописанной методике приоритизации дефектов приводится основная теоретическая модель. Очевидно, что в явном виде она не пригодна для практического применения, и ее стоит расценивать как основу для построения наиболее подходящего прикладного решения на том или ином проекте.
Основная цель данной модели — показать, что приоритизация багов зависит от достаточно большого количества факторов. И, к примеру, подход в ранжировании потенциальных и существующих проблем в SaaS проекте продуктового формата в области e-commerce должен отличаться от подхода в аутсорсинг-проекте по расширению или поддержке существующего бизнеса клиента. Так, для первого проекта будут существенно больший вес иметь факторы маркетинг-составляющей в приоритизации проблем, нежели для второго проекта.
Статья написана в соавторстве с Юлией Колесник.
Степень серьезности дефекта
Что такое серьезность?
Серьезность определяется как степень влияния дефекта на разработку или работу тестируемого приложения компонента.
Более высокий эффект на функциональность системы приведет к более высокой степени серьезности ошибки. Инженер по обеспечению качества обычно определяет степень серьезности дефекта
Что такое приоритет?
Приоритет определяется как порядок, в котором дефект должен быть исправлен. Чем выше приоритет, тем скорее дефект должен быть устранен.
Дефектам, которые оставляют программную систему непригодной для использования, предоставляется более высокий приоритет по сравнению с дефектами, которые приводят к сбою небольшой функциональности программного обеспечения.
Степень серьезности и приоритетность дефекта
В тестировании программного обеспечения серьезность дефекта можно разделить на четыре класса
Приоритет дефекта можно разделить на три класса
Советы по определению серьезности дефекта
Приоритет против серьезности: ключевое различие
Пример серьезности и приоритета дефекта
Давайте посмотрим на пример низкой серьезности и высокого приоритета и наоборот
Дефект Triage
Дефектная сортировка — это процесс, который пытается перебалансировать процесс, когда группа тестирования сталкивается с проблемой ограниченной доступности ресурсов. Таким образом, при наличии большого количества дефектов и ограниченных тестировщиков для их проверки сортировка дефектов помогает попытаться решить как можно больше дефектов на основе таких параметров дефектов, как серьезность и приоритет.
Как определить дефект дефектов:
Большинство систем используют приоритет в качестве основного критерия для оценки дефекта. Тем не менее, хороший процесс сортировки учитывает серьезность.
Процесс сортировки включает в себя следующие этапы
Рекомендации, которые должен учитывать каждый тестер, прежде чем выбирать уровень серьезности
Параметр серьезности оценивается тестером, а параметр приоритета — менеджером продукта или командой по сортировке. Для определения приоритета дефекта крайне важно, чтобы тестировщик выбрал правильную серьезность, чтобы избежать путаницы с командой разработчиков.