# Серьезность и приоритет Дефекта (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)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/obshee/sereznost-i-prioritet-defekta-severity-and-priority.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.