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

### Содержание:

* [Что такое серьезность и приоритет дефекта?](#chto-takoe-sereznost-i-prioritet-defekta)
* [Разница между серьезностью и приоритетом](#difference-between-severity-and-priority)
* [Классификации серьезности дефекта](#gradaciya-sereznosti-defekta)
* [Классификации приоритета дефекта](#gradaciya-prioriteta-defekta)
* [Сочетания приоритета и серьезности](#sochetaniya-severity-i-priority)

### Что такое серьезность и приоритет дефекта?

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

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

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

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

### Разница между серьезностью и приоритетом <a href="#difference-between-severity-and-priority" id="difference-between-severity-and-priority"></a>

Приоритет связан с планированием, а серьезность — со стандартами.

Скорость исправлений основывается на приоритетах проекта и серьезности дефекта.

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

### Классификации серьезности дефекта

**Критическая (critical)** - существование дефекта приводит к масштабным последствиям катастрофического характера, например: потеря данных, раскрытие конфиденциальной информации, нарушение ключевой функциональности приложения и т.д.;

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

*Например, в почтовом сервисе Yahoo или Gmail после ввода правильного имени пользователя и пароля вместо входа в систему происходит сбой или выдается сообщение об ошибке, такой дефект классифицируется как критический, поскольку он делает все приложение непригодным для использования.*

**Высокая (major)** - существование дефекта приносит ощутимые неудобства многим пользователям в рамках их типичной деятельности, например: недоступность вставки из буфера обмена, неработоспособность общепринятых клавиатурных комбинаций, необходимость перезапуска приложения при выполнении типичных сценариев работы;

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

Major дефект возникает тогда, когда функциональность работает совершенно не так, как ожидалось, или делает не то, что должна делать.&#x20;

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

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

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

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

### Классификации приоритета дефекта

**Наивысший или критический (ASAP, as soon as possible)** приоритет указывает на необходимость устранить дефект настолько быстро, насколько это возможно. Этот дефект должен быть исправлен как можно скорее, в течение 24 часов. Обычно это происходит в тех случаях, когда блокируется вся функциональность и из-за этого невозможно провести тестирование, или если имеются значительные утечки памяти. Иными словами, программа/функция в текущем состоянии является непригодной для использования.

**Высокая (high)** срочность означает, что дефект следует исправить вне очереди, т.к. его существование или уже объективно мешает работе. Обычно такой приоритет выставляется, когда функция не может быть использована так, как должна, из-за дефекта программы, или когда необходимо написать новый код, а иногда даже из-за того, что через код необходимо решить какую-либо проблему окружения. Это проблема, без решения которой выпуск нового релиза невозможен.

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

**Низкая (low)** дефект с низким приоритетом указывает на то, что проблема определенно существует, но ее не обязательно исправлять в текущем билде. Как правило, сюда можно отнести некоторые опечатки или косметические ошибки.

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

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

#### **1. High Priority and High Severity - Высокий приоритет и высокая серьезность:**

Любой Critical/major сбой бизнес-модели, критическая проблема, при которой полностью не работает большая часть функциональности или основной компонент системы. Это дефекты, из-за которых тестирование не может быть продолжено. **Например**, при нажатии на определенную кнопку не загружается сама функция. Или выполнение определенной функции приводит к последовательному падению сервера и потере данных.

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

#### **2. High Priority and Low Severity - Высокий приоритет и низкая серьезность**:&#x20;

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

Любые minor severity дефекты, которые влияют на взаимодействие с пользователями / репутацию:

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

#### **High Severity and Low Priority - Высокая серьезность и низкий приоритет**:&#x20;

Проблема, которая пока не повлияет на бизнес, но имеет большое влияние с точки зрения функциональности.

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

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

#### **Low Priority and Low Severity - Низкая серьезность и низкий приоритет**:&#x20;

Любые орфографические ошибки / начертание / несовпадение шрифта в абзаце 3-й или 4-й страницы заявки, а не на главной или титульной странице / заголовке. Эти дефекты возникают, когда это не влияет на функциональность, но все же в небольшой степени не соответствует стандартам. Обычно сюда классифицируются косметические ошибки или, скажем, размеры ячейки в таблице пользовательского интерфейса:

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


---

# 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://qabook.gitbook.io/start/teoriya-testirovaniya/bagi-defekty/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.