Severity и Priority: как приоритизировать баги
Severity и priority — одна из самых частых тем на собеседованиях и одна из самых частых точек путаницы в реальной работе. Новички нередко считают, что это одно и то же. На самом деле эти два параметра отвечают за разные вещи: severity описывает серьезность технического и пользовательского ущерба, а priority — срочность исправления для бизнеса и команды.
Что такое Severity
Severity показывает, насколько сильно дефект влияет на систему, пользователя или критичный сценарий. Это про масштаб и глубину проблемы. Например, падение приложения, невозможность оформить платеж или потеря данных — это высокая severity. Опечатка в текстовом поле — низкая severity.
- →Severity отвечает на вопрос: насколько больно сломалось?
- →Это характеристика влияния дефекта.
Что такое Priority
Priority показывает, насколько быстро нужно чинить проблему. Это уже не только про технику, но и про бизнес-контекст: релизные сроки, важность функции, репутационные риски, маркетинговые кампании и обязательства перед клиентом.
- →Priority отвечает на вопрос: насколько срочно мы это исправляем?
- →Priority может зависеть от релизного контекста.
Почему severity и priority не всегда совпадают
Многим кажется, что severe bug всегда должен иметь highest priority. Часто так и бывает, но не всегда. Например, критичный дефект в малоиспользуемом старом модуле может получить более низкий приоритет, чем визуальная ошибка на главной странице перед важным запуском. И наоборот: мелкий баг на витрине продукта может быть срочным из-за бизнес-рисков.
- →Severity — про влияние, priority — про очередность.
- →Оценка priority без контекста бизнеса почти всегда неполная.
Типовые комбинации
High severity + high priority — сломан ключевой пользовательский путь. High severity + low priority — редкий, но тяжелый дефект в малозначимом сценарии. Low severity + high priority — заметная мелочь в критически видимой зоне перед релизом. Low severity + low priority — косметический баг без влияния на пользователей и бизнес.
- →Комбинации помогают не мыслить слишком линейно.
- →Самое полезное — уметь объяснить, почему ты выбрал именно такую оценку.
Кто обычно ставит severity и priority
В разных командах практика отличается. Часто QA предлагает severity, а priority обсуждается вместе с product owner, менеджером или лидом. Иногда и severity требует коллективной калибровки. Главное — не превращать эти поля в формальность, а использовать их как инструмент осознанной приоритизации.
- →Severity и priority лучше обсуждать в одном контексте.
- →Если команда не договорилась о шкалах, начинается хаос.
Частые ошибки новичков
Самая частая ошибка — ставить все баги как high/high. Вторая — думать только как пользователь и не учитывать релизный контекст. Третья — путать техническую тяжесть с срочностью. Хороший QA умеет не только поставить оценку, но и объяснить ее понятным языком для команды.
- →Не завышай severity из эмоций.
- →Не занижай priority, если баг реально бьет по релизу или клиенту.
Вывод
Severity и priority — это не дублирующие поля, а две разные координаты дефекта. Severity показывает, насколько серьезна проблема, а priority — насколько срочно ее нужно исправлять. Чем точнее QA понимает разницу между ними, тем легче команде принимать разумные решения по багам.