Кто должен выставлять серьёзность

Серьёзность (Severity) в тестировании: кто и почему

В классической модели управления тестированием ПО, серьёзность (Severity) дефекта — это объективная оценка степени его влияния на функциональность компонента или системы в целом. Это атрибут самой ошибки, показывающий, насколько она "серьезна" для продукта.

Кто должен выставлять серьёзность?

Однозначного и универсального ответа нет, так как процесс зависит от зрелости команды, методологии (Agile/Waterfall) и принятых регламентов. Однако можно выделить три основные модели:

1. Ответственность тестировщика (QA Engineer).

    *   **Аргументы "за":** Тестировщик обнаружил дефект, проанализировал шаги воспроизведения и первым увидел его последствия в контексте требований. Он обладает достаточной экспертизой, чтобы оценить масштаб сбоя: блокирует ли тест дальнейшую проверку, приводит ли к падению системы, искажает ли ключевые данные.
    *   **На практике:** Тестировщик выставляет **предварительную/начальную серьёзность**. Это эффективно на старте, так как ускоряет первичную сортировку багов. Например, он сразу пометит падение приложения как `S1-Blocker`, а опечатку в сообщении — как `S4-Trivial`.

```java
// Пример: Тестировщик находит критическую ошибку
// Дефект: Система присваивает отрицательный баланс при успешном платеже.
// Действие: Тестировщик создаёт баг-репорт и выставляет Severity = S1-Critical.
// Причина: Ошибка в бизнес-логике, ведущая к финансовым искажениям.
```

2. Ответственность ведущего тестировщика, тимлида или менеджера проекта.

    *   **Аргументы "за:** Единый центр компетенции обеспечивает **консистентность** оценок. Разные тестировщики могут по-разному трактовать критичность одного и того же дефекта. Руководитель, видя полную картину по проекту, релизам и бизнес-приоритетам, может выставить более **взвешенную** оценку.
    *   **На практике:** Часто работает гибридная модель. Тестировщик предлагает свою оценку, а ответственное лицо на регулярных **bug triage**-митингах (совещаниях по разбору дефектов) утверждает или корректирует её.

1. Коллективное решение команды (Developer, QA, PO/Аналитик).

    *   **Аргументы "за":** Это наиболее зрелый и эффективный подход в Agile-командах. Серьёзность становится не просто технической меткой, а **совместной оценкой влияния на бизнес**.
    *   **Процесс:**
        *   **QA** описывает проблему и её воспроизведение.
        *   **Разработчик** оценивает сложность исправления и технические риски.
        *   **Product Owner или Бизнес-аналитик** оценивает влияние на пользовательский опыт, репутацию и доходы.
    *   **Итог:** Присваивается финальная серьёзность, которая напрямую влияет на приоритет исправления (Priority).

Серьёзность (Severity) vs Приоритет (Priority): ключевое различие

Это разные, но взаимосвязанные понятия.

• Severity — "Что сломано?" Объективная характеристика бага (влияние на систему).
• Priority — "Когда чинить?" Субъективное решение о порядке исправления (влияние на бизнес-процессы).

Пример для иллюстрации:

• Дефект A (Высокая Severity, Низкий Priority): Ошибка на странице "О компании", из-за которой не отображается логотип в редком браузере. Система работает, ключевая функциональность не затронута. Чинить будем "когда будет время".
• Дефект B (Низкая Severity, Высокий Priority): Неправильный цвет кнопки "Купить" на главной странице интернет-магазина по утверждённому дизайну. На функциональность не влияет, но бренд-менеджер и маркетинг настаивают на срочном исправлении к запуску рекламной кампании.

Резюме и лучшие практики

1. Инициирует оценку всегда тестировщик. Он заносит в отчёт свою экспертную оценку серьёзности.
2. Финальную оценку и приоритезацию лучше проводить коллегиально. На регулярных митингах с участием QA, разработки и представителя бизнеса (Product Owner). Это снимает конфликты и выравнивает видение.
3. Чётко задокументируйте критерии. Команда должна иметь согласованную матрицу серьёзности:

    *   **S1/Blocker:** Приложение падает, данные безвозвратно теряются, ключевой сценарий полностью неработоспособен.
    *   **S2/Critical:** Основная функция не работает, но есть обходной путь. Серьёзное искажение данных.
    *   **S3/Major:** Частичная неработоспособность второстепенной функции, несоответствие требованиям.
    *   **S4/Minor/Trivial:** Незначительные проблемы UI/UX, опечатки, не нарушающие функциональность.

Вывод: В идеале, процесс выставления серьёзности — это совместная ответственность команды, где тестировщик выступает основным инициатором и экспертом по воспроизведению, а бизнес- и технические специалисты помогают сделать итоговую оценку максимально адекватной для успеха продукта. Это не вопрос "кто должен", а вопрос налаженного процесса коммуникации.