7 мая 2026 г.·3 мин чтения

Severity vs Priority на собеседовании системного аналитика

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Содержание:

Зачем спрашивают на собесе SA

SA участвует в triage багов. На собесе SA: «отличие severity и priority», «когда low severity high priority». Классический trick question.

Severity: степень дефекта

Severity — насколько дефект ломает функциональность.

Уровни:

  • Critical (Blocker). Система не работает / падает / недоступна. Crash, data loss.
  • Major (High). Важная функция не работает, но система в целом доступна.
  • Moderate (Medium). Функция работает с проблемами, есть workaround.
  • Minor (Low). UI / косметика, не влияет на функциональность.
  • Trivial. Опечатки, мелкие cosmetic.

Назначается тестировщиком / автором bug report'а. Зависит от природы бага.

Priority: срочность

Priority — насколько срочно надо чинить.

Уровни:

  • P0 (Highest). Срочно, в production, drop everything.
  • P1 (High). В этом спринте.
  • P2 (Medium). В ближайшем релизе.
  • P3 (Low). Когда будет время.
  • P4 (Lowest). Может быть никогда.

Назначается PO / PM / SA. Зависит от business impact, срока, частоты.

Комбинации

High severity, high priority. Production crash. Очевидный case.

High severity, low priority. Функция критичная, но используется раз в год (annual report). Можно подождать.

Low severity, high priority. Опечатка в названии компании на homepage. Косметика, но видна всем — срочно.

Low severity, low priority. Edge case в admin tool, никто не заметит.

Главный insight. Severity ≠ priority. SA должен уметь различать.

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Bug life cycle

[New] → [Assigned] → [In Progress] → [Fixed] → [Verified] → [Closed]
                                       ↓
                                   [Reopened]
                                       ↓
                                  [Rejected / Duplicate]
                                       ↓
                                    [Won't Fix]
                                    [Deferred]

New. Только заведено.

Assigned. Назначено разработчику.

In Progress. Работа идёт.

Fixed. Dev исправил, ждёт verification.

Verified. QA подтвердил исправление.

Closed. Финал.

Reopened. При verification обнаружено что не исправлено или regression.

Rejected / Duplicate / Won't Fix / Deferred — alternative endings.

Частые ошибки

Все баги Critical severity. Девальвирует. Severity — описывает, не привлекает внимание.

Severity = priority. Самая частая ошибка. Они разные.

Severity changes after assignment. Severity — статичная природа дефекта. Priority может меняться.

Bug без steps to reproduce. Невозможно verify. Mandatory: steps + expected + actual.

Не указывать environment. «Не работает» — где? Browser, OS, app version?

Закрывать bug без verification. Регрессия будет обнаружена в проде, а не QA.

Связанные темы

FAQ

Кто меняет severity?

Изначально QA. PO / SA могут переоценить, если QA misjudged.

Это официальная информация?

Нет. Статья основана на ISTQB syllabus и стандартных QA practices.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.

Ещё по теме