Severity и priority: чем они отличаются

Вопрос выглядит как проверка терминов, но на самом деле проверяет, понимаете ли вы, что решение о порядке исправления принимает бизнес, а не тестировщик.

Severity — насколько дефект разрушителен для системы. Priority — насколько срочно его нужно исправить с точки зрения бизнеса.

Вопрос 1: «В чём разница между severity и priority? Приведите примеры»

Что на самом деле проверяет интервьюер

Сможете ли вы придумать пример «высокая критичность, низкий приоритет» и обратный. Без примеров ответ считается заученным.

Развёрнутый ответ

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

Два обязательных примера «крест-накрест»:

• Высокий severity, низкий priority: приложение падает при смене языка интерфейса на исландский. Падение — critical, но исландским пользуется ноль клиентов, чинить будем в следующем квартале.
• Низкий severity, высокий priority: на главной странице в названии компании опечатка, или логотип партнёра заменён на конкурента. Технически trivial, но это репутация и договор — правят сегодня.

Как это выглядит в очереди на исправление

severity_w = {"blocker": 4, "critical": 3, "major": 2, "minor": 1, "trivial": 0}
priority_w = {"high": 3, "medium": 2, "low": 1}

bugs = [
    ("Опечатка в футере на главной", "trivial", "high"),
    ("Падает оплата картой Visa", "blocker", "high"),
    ("Не открывается справка в редком сценарии", "critical", "low"),
    ("Кнопка «Купить» съезжает на iPhone SE", "minor", "high"),
]

for title, sev, pri in sorted(bugs, key=lambda b: -(severity_w[b[1]] + priority_w[b[2]] * 2)):
    print(f"{severity_w[sev] + priority_w[pri] * 2:>2}  {sev:<8} {pri:<6} {title}")

Вывод:

10  blocker  high   Падает оплата картой Visa
 7  minor    high   Кнопка «Купить» съезжает на iPhone SE
 6  trivial  high   Опечатка в футере на главной
 5  critical low    Не открывается справка в редком сценарии

Обратите внимание: critical-дефект оказался в конце очереди, потому что вес приоритета выше. Это и есть суть ответа — severity описывает дефект, priority управляет очередью. Конкретные веса в каждой команде свои, а зачастую вместо формулы работает разговор на баг-триаже.

Вопрос 2: «Кто выставляет severity и priority и что делать при несогласии?»

Что на самом деле проверяет интервьюер

Границы ответственности. Тестировщик, который в одиночку решает, что чинить, — проблема для команды; тестировщик, который молча соглашается с занижением, — тоже.

Развёрнутый ответ

Severity — ваша зона: вы видели дефект и оцениваете ущерб системе, и здесь спорить с вами сложно. Priority — зона продукта, но вы обязаны дать вход для решения: сколько пользователей затронуто, есть ли обходной путь, что произойдёт, если не чинить, воспроизводится ли на продакшене.

Если приоритет понизили, а вы считаете это опасным, правильный ход — не спор о ярлыке, а факты и риск: «баг воспроизводится у 12% пользователей с Android 12, обходного пути нет, ожидаем рост обращений в поддержку». Дальше решение принимает продукт, и оно фиксируется письменно — это нормальная работа, а не поражение. Такой ответ на собеседовании ценится очень высоко.

Типичные ошибки кандидатов

• Считают severity и priority синонимами и не могут привести перекрёстные примеры.
• Ставят всем своим багам blocker — быстро теряют доверие команды.
• Думают, что приоритет назначает тестировщик и он окончателен.
• Путают severity с «мне кажется, это важно»: критичность оценивается по ущербу системе, а не по личному раздражению.
• Не могут объяснить, почему опечатка на главной может быть срочнее падения редкой функции.

Как ответить кратко

Severity — техническая оценка ущерба от дефекта, её ставит тестировщик: от trivial до blocker. Priority — срочность исправления с точки зрения бизнеса, её определяет продукт или лид. Они независимы: падение приложения при выборе редкого языка — высокий severity и низкий priority, а опечатка в названии компании на главной — trivial severity и высокий priority, потому что это репутация. Моя задача — честно оценить severity и дать данные для приоритета: сколько пользователей затронуто, есть ли обходной путь и чем грозит откладывание. Решение об очерёдности принимает продукт, и я фиксирую его письменно.