> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/obshee/sereznost-i-prioritet-defekta-severity-and-priority.md).

# Серьезность и приоритет Дефекта (Severity & Priority)

Bug management включает в себя процесс документирования, категоризации, назначения, воспроизведения, исправления и выпуска исправленного кода. Предлагаемые изменения в программном обеспечении - баги, запросы на улучшения и даже целые [релизы](https://en.wikipedia.org/wiki/Software_bug#:~:text=next%20software%20release.-,Software%20releases,-%5Bedit%5D) - обычно отслеживаются и управляются с помощью баг-трекинговых систем. Добавленные элементы могут называться дефектами, заявками, проблемами или, в соответствии с парадигмой гибкой разработки, эпиками и сторями (stories and epics). Категории могут быть объективными, субъективными или комбинированными, такими как номер версии, область программного обеспечения, серьезность и приоритет, а также тип проблемы, такой как фича-реквест или баг.

*Критичность (severity): Важность воздействия конкретного дефекта на разработку или функционирование компонента или системы. (IEEE 610)*

*Приоритет (priority): Степень важности, присваиваемая объекту. Например, дефекту. (ISTQB)*

Иными словами, серьезность представляет техническое влияние ошибки в контексте работоспособности самого ПО, а приоритет указывает на очередность выполнения задачи или устранения дефекта, т.е. точку зрения бизнеса. Приоритет выставляется любыми business stakeholders, включая project managers, business analysts, product owner, а серьезность сам тестировщик (или в сложных случаях тот, кто лучше разбирается). Разработчик берет таски исходя из приоритета.

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

* Критическая (critical) - существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.;
* Высокая (major) - существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы;
* Средняя (medium) - существование дефекта слабо влияет на типичные сценарии работы пользователей, и/или существует обходной путь достижения цели, например: диалоговое окно не закрывается автоматически после нажатия кнопок «OK»/«Cancel», при распечатке нескольких документов подряд не сохраняется значение поля «Двусторонняя печать», перепутаны направления сортировок по некоему полю таблицы;
* Низкая (minor) - существование дефекта редко обнаруживается незначительным процентом пользователей и (почти) не влияет на их работу, например: опечатка в глубоко вложенном пункте меню настроек, некое окно сразу при отображении расположено неудобно (нужно перетянуть его в удобное место), неточно отображается время до завершения операции копирования файлов.

**Градация Срочности/приоритета** (Priority):

* Наивысшая (ASAP, as soon as possible) срочность указывает на необходимость устранить дефект настолько быстро, насколько это возможно. В зависимости от контекста «настолько быстро, насколько возможно» может варьироваться от «в ближайшем билде» до единиц минут;
* Высокая (high) срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе, или начнёт создавать такие помехи в самом ближайшем будущем;
* Обычная (normal) срочность означает, что дефект следует исправить в порядке общей очередности. Такое значение срочности получает большинство дефектов;
* Низкая (low) срочность означает, что в обозримом будущем исправление данного дефекта не окажет существенного влияния на повышение качества продукта.

**Сочетания Severity и Priority**

* **High Priority and High Severity**: Любой Critical/major сбой бизнес-модели, критическая проблема, при которой полностью не работает большая часть функциональности или основной компонент системы:
  * нажатие на определенную кнопку не запускает саму функцию, например, не работает кнопка отправки на странице входа, и клиенты не могут войти в приложение;
  * выполнение определенной функции постоянно приводит к 500 ошибке сервера и потере данных;
  * система дает сбой после того, как вы совершили платеж или когда вы не можете добавить товары в корзину;
  * функция банкомата, при которой после ввода правильного имени пользователя и пароля автомат не выдает деньги, но списывает их с вашего счета;
  * на веб-сайте банка появляется сообщение об ошибке, когда клиент нажимает кнопку перевода денег.
* **High Priority and Low Severity**: Любые minor severity дефекты, которые влияют на взаимодействие с пользователями / репутацию:
  * ожидается, что функция покажет пользователю конкретную ошибку по коду ответа. В этом случае функционально код выдает ошибку, но сообщение должно быть более релевантным коду;
  * ошибка в логотипе или названии компании на главной странице, или опечатки, бросающиеся в глаза и способные повлиять на репутацию компании;
  * опечатки в контактных данных;
  * важные ошибки в соглашениях и юридических документах.
* **Low Priority and High Severity**: Проблема, которая пока не повлияет на бизнес, но имеет большое влияние с точки зрения функциональности:
  * присутствует серьезный баг, но есть workaround и исправление уже может быть запланировано в следующем релизе или функция будет удалена;
  * функция генерации годового отчета, которая будет использована только через полгода;
  * редкость проявления дефекта/сложность воспроизведения для юзеров.
* **Low Priority and Low Severity**: Любые орфографические ошибки / начертание / несовпадение шрифта в абзаце 3-й или 4-й страницы заявки, а не на главной или титульной странице / заголовке. Эти дефекты возникают, когда это не влияет на функциональность, но все же в небольшой степени не соответствует стандартам. Обычно сюда классифицируются косметические ошибки или, скажем, размеры ячейки в таблице пользовательского интерфейса:
  * в политике конфиденциальности веб-сайта есть орфографическая ошибка;
  * страница часто задаваемых вопросов загружается очень долго;
  * семейство шрифтов, размер шрифта, цвет или орфографическая ошибка в приложении или отчетах.

Источники:

* [Святослав Куликов “Тестирование программного обеспечения. Базовый курс”](https://svyatoslav.biz/software_testing_book/). Раздел 2.5
* [Defect Severity And Priority In Testing With Examples And Difference](https://www.softwaretestinghelp.com/how-to-set-defect-priority-and-severity-with-defect-triage-process/)
* [Difference Between Defect Severity And Priority In Software Testing](https://www.softwaretestingmaterial.com/what-is-the-difference-between-severity-and-priority-in-software-testing/#What-is-Priority)

Доп. материал:

* [Серьезность и приоритет багов - в чем разница?](https://testengineer.ru/sereznost-i-prioritet-bagov-v-chem-raznica/)
* [Про Severity - серьезно и несерьезно](https://www.software-testing.ru/library/testing/testing-for-beginners/2100-severity-)
* [Про баги, алерты и басню «Волки, волки»](https://t.me/shooandendlessagony/90)