Баг который повреждает записи базы данных при массовом импорте: Critical severity. Но если этот импорт выполняется один раз при онбординге единственным администратором и существует обходное решение, он вполне может подождать следующего спринта, пока опечатка в имени партнёра на главной странице уходит как хотфикс сегодня. Severity и priority: разные измерения. Статья разбирает как применять оба: четырёхуровневую шкалу severity, что движет решениями по priority, и два квадранта матрицы 2×2 которые стропорят большинство джуниор QA-инженеров.
Что такое severity на самом деле
Severity измеряет техническое воздействие бага. Насколько серьёзно этот дефект повреждает систему? Потеря данных, крэш, сломанный платёжный флоу: высокий severity. Съехавший лейбл кнопки, опечатка в тултипе: низкий severity.
Severity живёт исключительно в техническом домене. Ему нет дела до расписания релиза, маркетинговой кампании или количества людей которые это увидят. Он отвечает на один вопрос: насколько это сломано объективно?
Классическая четырёхуровневая шкала severity которую использует большинство команд.
Critical: баг делает что-то полностью нефункциональным, повреждает данные, создаёт уязвимость безопасности или крэшит приложение. Пользователь не может продолжить. Обходного решения нет. Пример: клик по "Разместить заказ" показывает экран успеха, но заказ никогда не записывается в базу данных. Major: значимая фича сломана или серьёзно нарушена. Обходное решение существует, но неудобное или неочевидное. Пример: экспорт отчёта в CSV выдаёт файл с искажённой кодировкой для любого имени содержащего не-ASCII символ. Minor: функциональность работает, но что-то не так влияя на пользовательский опыт без блокировки задачи. Пример: письмо подтверждения "Сброс пароля" говорит "Ваш пароль был сброшн" вместо "сброшен". Trivial: косметическое, незначительное функциональное воздействие. Ни один пользователь не заблокирован. Пример: год в подвале сайта читается как 2024 вместо 2026.Severity устанавливаешь ты как QA. Это твоё профессиональное суждение, и оно должно быть обоснованным на основе наблюдаемого воздействия, а не ощущений.
Что такое priority на самом деле
Priority измеряет бизнес-срочность. Как скоро это нужно исправить относительно всего остального в бэклоге?
Priority не только твоё решение. Продукт-менеджер, тимлид или владелец проекта обычно управляют priority, потому что это требует знания расписания релиза, бизнес-обязательств и толерантности к риску которых у QA часто нет полного видения.
При этом твоя оценка severity напрямую влияет на их решение по priority. Неверная метка severity: плохие данные для бизнес-решения.
На практике в небольших командах эти границы размыты. QA-лид может устанавливать оба для бага. Это нормально. Главное держать рассуждения раздельно: "это технически плохо по этим причинам" и "это нужно отправить к пятнице по этим причинам".
Матрица 2×2: где становится интересно
Очевидные случаи просты. Крэш чекаута на основном платёжном пути? Высокий severity, высокий priority, исправляй сейчас. Сдвинутый пиксель на admin-странице которую никто не использует? Низкий severity, низкий priority, подождёт.
Интересные случаи: два угла которые все упускают.
Высокий severity, низкий priority. Представь: тестируешь enterprise-приложение с функцией массового импорта данных используемой администраторами баз данных для миграции легаси-данных. Находишь баг: если импортный файл содержит столбец с null-значениями в конкретной позиции, импортируемый набор данных повреждается.Это Critical severity. Повреждение данных: хуже некуда.
Но фичу используют один раз при начальном онбординге единственным техническим пользователем, всегда под контролем, и обходное решение существует (удали null-значения из того столбца перед импортом). Следующий релиз через месяц, и пять флоу с более высоким трафиком имеют активные баги конкурирующие за время разработчиков.
Priority? Средний, может даже низкий для этого конкретного спринта.
Severity не меняется. Повреждение данных всё ещё Critical. Но бизнес-решение запланировать его позже чем Major-баг в пользовательском чекаут-флоу полностью рационально.
Низкий severity, высокий priority. Твоя компания только что запустила кобрендинговый продукт с крупным партнёром. На главной странице имя партнёра написано с ошибкой. Одна буква переставлена.Severity? Trivial. Ни один пользователь не заблокирован. Данные не под угрозой. Приложение работает идеально.
Priority? Critical для этого релиза. Юридический отдел, партнёрский отдел и маркетинг: все обращают на это внимание раньше чем продукт-менеджер допивает утренний кофе. Он попадает в очередь хотфиксов впереди Major-бага во второстепенном флоу.
Это случай который чаще всего стропорит джуниор QA. Видят "Trivial severity" и предполагают низкий priority, потом удивляются когда это исправляется за два часа пока их Major-баг стоит нетронутым.
Реальные примеры всех четырёх квадрантов
Высокий severity + Высокий priority. При регрессионном тестировании обнаруживаешь что отправка формы сброса пароля с валидным email возвращает 500 ошибку и письмо сброса никогда не отправляется. Пользователи заблокированы без пути восстановления. Это выходит в понедельник. Исправляй сегодня. Высокий severity + Низкий priority. Экспорт журнала аудита приложения, используемый офицерами по compliance для квартальных отчётов, выдаёт некорректный файл если период дат превышает 18 месяцев. Это реально плохо (риск целостности данных), но следующее окно экспорта через 10 недель, обходное решение существует (запусти два экспорта и объедини), и compliance-команда уведомлена. Попадает в бэклог следующего спринта, не этого. Низкий severity + Высокий priority. За три недели до публичного запуска приложения замечаешь что мета-заголовок на лендинге читается "Untitled Document": плейсхолдер шаблона который никогда не обновляли. Ноль функционального воздействия. Но это появится в результатах поиска Google и превью соцсетей с первого дня запуска. SEO, маркетинг и CEO обеспокоены. Исправляется этим вечером. Низкий severity + Низкий priority. Тултип на панели расширенных фильтров говорит "Кликните для розкрытия" вместо "раскрытия". Он там шесть месяцев. Исправится при следующем UI-проходе в следующем квартале. Ничего срочного.Кто что устанавливает и почему это важно
Распределение ответственности стоит сформулировать чётко.
QA устанавливает severity. Ты наблюдал баг, тестировал воздействие, знаешь как система должна работать. Ты в лучшей позиции чтобы судить насколько что-то технически сломано. Владей этим решением. Если разработчик возражает против твоей метки severity: будь готов объяснить рассуждение. "Я пометил это Critical потому что это приводит к потере данных в затронутом сценарии, что по нашим определениям severity ставит это в эту категорию."
Продукт или менеджмент устанавливает priority. У них есть контекст которого нет у тебя: какие клиенты затронуты, какие обязательства существуют, какое конкурентное давление, что позволяет ёмкость спринта. Уважай что это их решение.
Где всё идёт не так: QA которые ставят низкий severity на всё чтобы избежать конфликта, или которые предполагают что раз они нашли это, значит это Critical. Оба паттерна разрушают доверие. Точный severity: часть твоего профессионального вывода, относись к нему серьёзно.
Как аргументировать priority когда кто-то возражает
Ты залогировал Major-баг в основном пользовательском флоу. PM отвечает: "Посмотрим в следующем спринте." Ты думаешь что нужно отправить на этой неделе.
Как выстраивать аргумент: формулируй через воздействие на пользователей и бизнес, а не через техническую гордость.
Слабый аргумент: "Но это Major-баг, его нужно исправить сейчас."
Более сильный аргумент: "Это ломает флоу экспорта для любого пользователя с более чем 500 элементами. По нашим данным это примерно 30% активных аккаунтов. Если мы выйдем в пятницу без исправления, получим тикеты в поддержку. Лучше зафлажить сейчас чем разбираться после релиза."
Дай PM что-то для взвешивания. Они принимают компромисс рисков. Твоя задача: положить правильную информацию на стол, а не принимать финальное решение. Если они услышали бизнес-кейс и всё равно решили отложить: это законное продуктовое решение. Задокументируй что баг был известен и прошёл триаж, залогируй, двигайся дальше.
Пятиуровневая vs четырёхуровневая шкала
Некоторые команды используют пять уровней severity: Critical, High, Medium, Low, Trivial. Другие четыре (Critical, Major, Minor, Trivial). Некоторые три (High, Medium, Low).
Используемая шкала важна меньше чем последовательное применение внутри команды. Проблема больших шкал не в количестве уровней. В том что команды в итоге спорят является ли что-то High или Medium вместо того чтобы проводить триаж багов. Если команда тратит 20 минут споря является ли баг Minor или Trivial: шкала имеет больше детализации чем поддерживает процесс.
Для большинства команд четыре уровня работают хорошо. Пять уместны при большой QA-организации где severity питает автоматизированные SLA-таймеры (например, Critical-баги должны быть подтверждены в течение 2 часов, High в течение 24 часов). Три уровня работают в быстро двигающихся ранних командах где нюансы роскошь.
Выбери шкалу, задокументируй что означает каждый уровень с конкретными примерами, применяй последовательно. Последовательность важнее точности.
Как писать severity в баг-репорте который не оспаривают
Причина по которой severity оспаривается на встречах по триажу почти всегда одна: метка severity есть, а обоснования нет.
"Severity: Critical" приглашает дискуссию. "Severity: Critical: клик по Submit молча сбрасывает отправку формы без обратной связи; пользователи считают что действие выполнено, но ничего не сохраняется" не приглашает дискуссию.
Пиши severity как короткий вердикт с доказательствами. Одно-два предложения. Укажи воздействие, объясни почему это попадает в эту категорию.
Паттерн: [Уровень severity]: [что система делает неправильно] [кто затронут и как] [почему эта категория а не ниже].
Применение:
Плохо: Severity: Major
Лучше: Severity: Major. Флоу сброса пароля падает для всех пользователей пытающихся сбросить через мобильный браузер. Пользователи заблокированы от восстановления аккаунта на мобильных; на десктопе всё работает, что является обходным решением.
Эта формулировка делает три вещи: обосновывает метку через воздействие, очерчивает кто затронут, и признаёт что делает это Major а не Critical (обходное решение существует). Любой читающий тикет понимает решение о severity без необходимости просить объяснений.
Как применять это с понедельника
Когда логируешь следующий баг: притормози на полях severity и priority вместо того чтобы кликать первую опцию которая кажется правильной.
Спроси себя: что реально ломается здесь и для кого? Если пользователь встретит этот баг, сможет ли он выполнить цель другим способом? Затрагивает ли это всех пользователей или конкретный сегмент? Портит ли данные или просто создаёт неудобство?
Ответ: твой severity. Напиши одно предложение обоснования рядом с меткой.
Потом посмотри на бэклог тикетов. Что выходит в этом спринте? Кто затронут этим багом относительно остальных багов в очереди? Набросай предложение по priority в комментарии, не как требование, а как вводную: "Учитывая что это затрагивает основной платёжный путь и мы выпускаем в пятницу, предлагаю сделать это спринт-приоритетом."
Со временем эта практика даёт видимый результат: твои решения по триажу перестают отменяться. PM перестают переопределять твои метки. Разработчики перестают оспаривать твои Critical-вызовы. Не потому что повезло. Потому что ты разделил два концепта которые большинство джуниор QA сваливают в один и начал чётко коммуницировать это различие.
Именно этот навык триажа замечают.
→ See also: Анатомия баг-репорта, который исправят: структура и примеры | Как писать тест-кейсы: формат, примеры и частые ошибки
