Ответ
На проекте использовалась классическая модель оценки дефектов по Severity (влияние на систему) и Priority (важность для бизнеса). Окончательное решение по severity принимал QA-инженер, а по priority — Продуктовый менеджер / Владелец продукта, после чего оно согласовывалось с командой разработки.
Критерии оценки Severity:
| Уровень | Описание | Пример |
|---|---|---|
| S1: Блокирующий (Blocker) | Полная неработоспособность ключевой функции, падение системы, потеря данных. Нет обходного пути. | «Приложение крашится при запуске для 100% пользователей на iOS 17». |
| S2: Критический (Critical) | Ключевая функция не работает, но есть обходной путь. Серьезная ошибка логики, влияющая на бизнес. | «Кнопка "Оплатить" неактивна после выбора способа доставки. Покупку можно завершить только через корзину». |
| S3: Значительный (Major) | Функция работает с ограничениями или ошибками, не критичными для основного сценария. | «В отчете за прошлый месяц не отображаются транзакции, созданные 31-го числа». |
| S4: Незначительный (Minor) | Косметическая проблема, опечатка, неверное сообщение об ошибке. Не влияет на функциональность. | «Не выровнена кнопка "Отмена" в модальном окне». |
Процесс на практике:
- QA выставляет предварительную severity на основе таблицы выше.
- На ежедневном стендапе или в баг-трекинге (Jira) severity обсуждается с разработчиком (оценивается сложность исправления) и менеджером (оценивается влияние на пользователей).
- Менеджер выставляет final priority (P0-P2), который определяет очередь на исправление.
Важно: Severity — объективный технический параметр, Priority — субъективный бизнес-параметр. Баг может иметь высокую severity, но низкий priority, если проблема возникает в редко используемом функционале.
Ответ 18+ 🔞
А, ну это классика, блядь! Сидим тут, как дурачки, и думаем, как баги оценивать, а тут всё давно придумано, ёпта!
Слушай, вот смотри. Раньше у нас была простая схема: всё, что не работает — это пиздец, а всё, что работает криво — это похуй. Но нет же, надо всё усложнить, блядь! Вот и придумали эти ваши Severity и Priority.
Severity — это, грубо говоря, насколько всё ебнулось с технической точки зрения. Тут главный царь и бог — QA-инженер. Он смотрит на баг и думает: «Ну и пиздопроёбина же!». И ставит одну из этих градаций:
| Уровень | Что значит на нормальном языке | Пример, чтобы совсем понятно было |
|---|---|---|
| S1: Блокирующий (Blocker) | Всё, пиздец, кина не будет. Система легла, данные потерялись, ключевая фича не работает НИ ДЛЯ КОГО. Обходного пути — ноль, нихуя. | «Приложение, сука, вылетает сразу после запуска у всех пользователей на новых айфонах. Вообще всем. Вот это пизда». |
| S2: Критический (Critical) | Ключевая функция сломана, но не наглухо. Есть какой-то костыль, какая-то кривая тропинка, чтобы пользователь не умер. Ошибка серьёзная, бизнес теряет деньги. | «Кнопка "Купить" сдохла. Но если зайти через левое меню в корзину и тыкнуть три раза по иконке, то оплата пройдёт. Ну, в общем, кринж». |
| S3: Значительный (Major) | Функция вроде жива, но прихрамывает на обе ноги. Основной сценарий работает, но где-то на периферии какая-то хуйня. | «В отчёте за месяц не показываются платежи, сделанные в последний день. То есть всё есть, а за 31-е число — хуй. Странно, блядь». |
| S4: Незначительный (Minor) | Да похуй, честно. Криво стоит кнопка, опечатка в тексте, не тот цвет. Ни на что не влияет, но глаз, блядь, режет. | «Заголовок в попапе съехал на два пикселя вправо. Ну, если прищуриться, то видно. Пидарасы, блядь». |
А вот Priority — это уже другая опера, ёпта! Это не «насколько сломано», а «насколько всем насрать или не насрать». Тут уже рулит Продуктовый менеджер или Владелец. Он смотрит на тот же самый баг и думает: «Ахуеть, ну и что? Кому это надо чинить прямо сейчас?».
Как это всё работает на практике, блядь?
- QA находит баг, охуевает и выставляет свою severity. Пишет: «S1, всё ебнулось!».
- Потом все собираются на стендап или в тикете и начинается цирк. Разработчик смотрит и говорит: «Да это, бля, на три строки кода, чинится за пять минут». А менеджер такой: «Да этой фичей за год три человека воспользовались, похуй». И начинается торговля, ебать её в сраку.
- В итоге менеджер своим царским жестом выставляет финальный priority (P0-P2). Вот он-то и решает, когда это чинить: прямо сейчас, завтра или никогда.
Самое важное, что нужно понять, ёбта: Severity и Priority — это не одно и то же! Это, блядь, как в больнице: можно с оторванной ногой приехать (Severity — высоченный), но если ты бомж, то тебя будут ждать в очереди два дня (Priority — низкий). И наоборот: у какого-нибудь директора может мозоль натереть (Severity — низкий), но ему всё бросятся лечить сию секунду (Priority — высоченный).
Вот такая, блядь, наука. Казалось бы, ерунда, а без этого — бардак, сука, полный. Все орут, ничего не понятно, что чинить в первую очередь. А так — всё по полочкам, в рот меня чих-пых.