Зачем это спрашивают
Severity и priority — два поля в каждом баг-трекере, и путаница между ними мешает команде. Если тестировщик ставит всем дефектам «критично», разработчики перестают доверять его оценкам. Если не отличает серьёзность от срочности, на разборе багов он не сможет защитить по-настоящему опасную проблему.
Поэтому вопрос задают почти всегда. На уровне junior ждут чёткого различия и примеров. На уровне middle часто добавляют кейс: «покупатель не может применить промокод, но оформляет заказ без скидки — какая severity?» Здесь проверяют уже рассуждение, а не определение.
Как построить сильный ответ
Определения
Severity (серьёзность) — насколько сильно дефект влияет на работу системы. Это техническая оценка последствий: что сломано и насколько. Severity обычно ставит тот, кто нашёл баг, — тестировщик.
Priority (приоритет) — насколько срочно дефект нужно исправить. Это решение о планировании, которое учитывает бизнес: сроки релиза, число затронутых пользователей, репутацию, договорённости с заказчиком. Priority определяет тимлид, менеджер проекта или владелец продукта, иногда по предложению тестировщика.
Коротко: severity отвечает на вопрос «насколько плохо», priority — «когда чиним».
Типичные шкалы
| Severity | Что означает |
|---|---|
| Blocker | невозможно продолжить работу или тестирование, обхода нет |
| Critical | не работает ключевая функция, есть потеря данных или денег |
| Major | важная функция работает неправильно, но есть обход |
| Minor | небольшое нарушение, на основной сценарий почти не влияет |
| Trivial | косметика: опечатка, смещение элемента |
Priority часто задают как High / Medium / Low или P1–P4. Названия уровней в разных компаниях отличаются — скажите об этом, это показывает опыт работы с реальными трекерами.
Примеры в обе стороны
Интервьюер почти наверняка попросит примеры, где поля расходятся. Подготовьте оба:
- Высокая severity, низкий priority. Падает генерация годового отчёта в разделе, которым пользуются раз в год, а до следующего использования несколько месяцев. Последствия тяжёлые, но время на исправление есть.
- Низкая severity, высокий priority. Опечатка в названии компании на главной странице накануне рекламной кампании. Функциональность цела, но ошибку увидят все.
Как обосновать уровень severity
Сильный ответ — это рассуждение, а не угадывание. Задайте себе три вопроса:
- Что сломано? Ключевой сценарий или второстепенная функция.
- Есть ли обход? Может ли пользователь достичь цели другим путём.
- Какие потери? Деньги, данные, клиенты, безопасность.
Пример ответа
Severity — это серьёзность последствий дефекта, её обычно ставит тестировщик, оценивая, что сломано и насколько. Priority — это срочность исправления, его определяет тимлид или продукт с учётом сроков и бизнеса. Эти поля могут расходиться. Высокая severity и низкий priority — например, падает годовой отчёт, которым пользуются раз в год, и до следующего раза ещё несколько месяцев. Низкая severity и высокий priority — опечатка в названии компании на главной странице перед рекламной кампанией. Когда выбираю severity, я рассуждаю через три вопроса: какая функция сломана, есть ли обход и есть ли потери денег, данных или клиентов.
Частые ошибки
- Описать оба поля одинаково. «Severity — насколько важен баг, priority — насколько он важен для бизнеса» — это одно и то же разными словами.
- Не назвать, кто что ставит. Именно распределение ответственности делает разницу понятной.
- Пример только в одну сторону. Нужны оба расхождения.
- Severity наугад. «Blocker, потому что это деньги» без анализа обхода — слабый ответ.
- Всё критичное. Если каждый баг Critical, шкала теряет смысл. Оценка должна различать дефекты.
Пример на MarketCove
Разберём гипотетический кейс в учебном магазине https://shop.tomiddle.com: сотрудник в админке переводит заказ из PENDING в следующий статус, но покупатель в истории заказов профиля продолжает видеть PENDING. Сами заказы оформляются и обрабатываются нормально.
Рассуждаем по трём вопросам:
- Что сломано? Отображение статуса для покупателя. Основной сценарий — выбрать товар и оформить заказ — работает, и сотрудники видят верный статус.
- Есть ли обход? Только неудобный: узнать статус в поддержке. Самостоятельно покупатель актуальную информацию не получит.
- Какие потери? Лишние обращения в поддержку и тревога покупателей, которые думают, что заказ завис.
Вывод: обычно это Major. Если статус в то же время виден в другом месте, например в письме или на отдельной странице заказа, оценку можно снизить до Minor. Blocker здесь не подходит: ни оформление, ни обработка заказа не заблокированы.
Priority зависит от контекста, который тестировщик может не знать полностью. Если обращения в поддержку уже идут потоком — вероятно, высокий. Если история заказов пока доступна узкому кругу пользователей — ниже. Хорошая практика — указать в баг-репорте severity с обоснованием и предложить priority, оставив финальное решение команде. О том, что происходит с багом дальше, — в статье про жизненный цикл бага.
Задание для практики
Придумайте пять гипотетических дефектов для страниц https://shop.tomiddle.com: каталог, карточка товара, вход, профиль с историей заказов, страница успешного заказа. Для каждого выберите severity и одной строкой обоснуйте через функцию, обход и потери. Затем для двух из них придумайте контекст, в котором priority резко отличается от severity. Отработать оформление полей можно в тренажёре баг-репортов.
