Серьёзность и приоритет

Updated Jul 2026

Это независимые оси. Баг может быть высокой серьёзности, но низкого приоритета, или низкой серьёзности, но высокого приоритета. Путаница между ними — одна из наиболее распространённых ошибок QA-инженеров, и она приводит к неправильно управляемым бэклогам, раздражённым разработчикам и срыву сроков.

Определения

Серьёзность (Severity)

Серьёзность измеряет техническое воздействие дефекта. Насколько сильно он повреждает функциональность? Серьёзность — это фактическое наблюдение о том, что баг делает с системой.

Приоритет (Priority)

Приоритет измеряет бизнес-срочность исправления дефекта. Как быстро он должен быть исправлен? Приоритет — это бизнес-решение о планировании.

Двухосевая матрица

Анализ каждого квадранта

Высокая серьёзность + Высокий приоритет (верхний левый): очевидные чрезвычайные ситуации. Production не работает, пользователи теряют данные, безопасность нарушена. Все согласны, что это исправляется немедленно.

Высокая серьёзность + Низкий приоритет (верхний правый): серьёзные баги, возникающие редко. Падение, которое происходит только при вводе 10 000 символов, технически критично, но затрагивает почти никого. Запланируйте исправление, но не прерывайте текущий спринт.

Низкая серьёзность + Высокий приоритет (нижний левый): косметические или незначительные проблемы с непропорционально большим бизнес-влиянием. Имя генерального директора, написанное с ошибкой на главной странице, — тривиальный баг, но его нужно исправить до завтрашнего заседания совета директоров. Нерабочая ссылка на посадочной странице во время маркетинговой кампании.

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

Кто принимает решения?

Серьёзность: оценивает QA

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

При оценке серьёзности спросите:

• Баг вызывает падение приложения или повреждение данных? (Критический)
• Мешает ли он пользователю завершить основной рабочий процесс? (Высокий)
• Снижает ли он функциональность, но допускает обходные пути? (Средний)
• Это косметическая проблема или затрагивает только крайние случаи? (Низкий)

Приоритет: решает руководство продукта/разработки

Приоритет — это бизнес-решение, учитывающее факторы помимо самого бага:

• Сколько пользователей затронуто?
• Есть ли регуляторный дедлайн?
• Затронут ли крупный клиент?
• Зависит ли маркетинговая кампания от этой функции?
• Какова альтернативная стоимость исправления сейчас по сравнению с позже?

Когда QA и руководство расходятся во мнениях

Иногда QA оценивает баг как критической серьёзности, но владелец продукта устанавливает приоритет P2. Это происходит, когда:

• Баг серьёзный, но затрагивает очень мало пользователей
• У команды есть работа с более высоким приоритетом (дедлайн запуска)
• Существует обходной путь, смягчающий последствия

Это нормально. Задача QA — точно сообщать о серьёзности. Задача руководства — приоритизировать бэклог. QA должен отстаивать исправление, но уважать решение о приоритизации — если только речь не идёт о потере данных, безопасности или соответствии нормативным требованиям, в этом случае необходима эскалация.

Типичные ошибки

1. Использование «серьёзности», когда имеется в виду «приоритет»

«Это баг серьёзности 1, исправьте немедленно!»

Серьёзность 1 означает, что баг технически разрушителен. Исправлять ли его немедленно — зависит от приоритета, который зависит от бизнес-контекста. Баг серьёзности 1 в функции, используемой 3 внутренними пользователями, может быть P2.

2. Завышение серьёзности для привлечения внимания

Пометка каждого бага как «Критический» для гарантии исправления контрпродуктивна. Когда всё критично — ничто не критично. Команда перестаёт доверять оценкам серьёзности, и действительно критичные баги теряются в шуме.

3. Использование единой шкалы

Некоторые команды используют только одно поле («Высокий/Средний/Низкий») для серьёзности и приоритета одновременно. Это вынуждает идти на компромиссы, скрывающие информацию. Баг может одновременно быть «высокой серьёзности» и «низкого приоритета» — одна шкала не может это отразить.

4. Никогда не обновляют приоритет

Баг P3, оформленный три месяца назад, может стать P1, потому что на него пожаловался крупный клиент. Приоритет должен переоцениваться на совещаниях по триажу.

Серьёзность/приоритет в инструментах баг-трекинга

Конфигурация Jira

Jira имеет отдельные поля «Priority» и «Severity» (severity необходимо добавить как настраиваемое поле). Используйте оба:

• Priority: Blocker / Critical / Major / Minor / Trivial
• Severity (настраиваемое): Critical / High / Medium / Low

GitHub Issues

Используйте метки для представления обоих измерений:

• severity:critical, severity:high, severity:medium, severity:low
• priority:p0, priority:p1, priority:p2, priority:p3

Linear

Встроенный приоритет Linear (Urgent / High / Medium / Low / No priority) соответствует приоритету. Добавьте группу меток «Severity» для второго измерения.

Совещания по триажу

Триаж багов — это регулярное совещание, на котором команда просматривает новые баги и назначает приоритет. Эффективный триаж:

1. QA представляет баг с оценкой серьёзности
2. Владелец продукта оценивает бизнес-влияние и устанавливает приоритет
3. Разработка оценивает трудозатраты на исправление
4. Команда решает: исправить сейчас, запланировать на этот спринт или добавить в бэклог

Вопросы для триажа

• Кто затронут? (Все пользователи, часть, только внутренние?)
• Есть ли обходной путь? (Если да, приоритет может снизиться)
• Каков радиус поражения? (Одна функция, несколько функций, всё приложение?)
• Это регрессия? (Регрессии часто получают более высокий приоритет, потому что что-то, что работало, перестало работать)
• Есть ли последствия для соответствия нормативным требованиям или безопасности? (Автоматическое повышение приоритета)

Практическое упражнение

Для каждого из следующих багов назначьте уровень серьёзности и уровень приоритета и обоснуйте свой выбор:

1. Ссылка в письме «Forgot Password» ведёт на неправильный URL — пользователи не могут сбросить пароль
2. Дашборд администратора показывает неправильный часовой пояс для временных меток логов
3. Обнаружена уязвимость SQL-инъекции в строке поиска
4. Мобильное приложение падает при повороте экрана во время воспроизведения видео
5. Логотип компании на странице входа — старая версия до ребрендинга 2023 года

Ключевые выводы

• Серьёзность — это техническое воздействие (оценивает QA). Приоритет — это бизнес-срочность (устанавливает продукт/руководство).
• Храните их как отдельные поля в баг-трекере — никогда не сводите к одной шкале
• Высокая серьёзность автоматически не означает высокий приоритет, и наоборот
• QA-инженер, путающий серьёзность и приоритет, будет неправильно приоритизировать бэклог
• Совещания по триажу — это место, где серьёзность встречается с приоритетом — представляйте свои находки чётко и позвольте команде принять решение

Тезис для собеседования: «Я отношусь к ручному тестированию как к мыслительной дисциплине, а не задаче, которую можно автоматизировать. Я использую сессионное исследовательское тестирование с хартиями и тайм-боксами для систематического поиска проблем, которые пропускают скриптовые тесты. Когда я оформляю баг, я включаю минимальное воспроизведение, детали окружения и чёткое разделение серьёзности и приоритета — потому что баг-репорт, который разработчик может воспроизвести менее чем за две минуты, исправляется за часы, а не за недели.»