Ответ
Критичность багов обычно определяет QA-инженер, но окончательное решение может зависеть от команды или процесса. Важно учитывать:
- Влияние на пользователя – блокирующие, критические, мажорные, минорные.
- Частоту воспроизведения – регулярные ошибки vs редкие кейсы.
- Бизнес-логику – например, ошибка в платежах критичнее, чем опечатка.
Пример градации:
- Blocker – система падает при запуске.
- Critical – невозможность оформить заказ.
- Major – некорректное отображение цены.
- Minor – опечатка в UI.
Финалное согласование может проходить с PM/Dev-лидом.
Ответ 18+ 🔞
О, слушай, а вот это реально интересная тема, про которую можно дохуя спорить! Кто, блядь, решает, насколько баг — это пиздец, а не просто мелкая неприятность?
Ну, формально-то, конечно, QA-инженер, этот отчаянный воин, который всё тыкает и ломает, он первым ставит предварительный диагноз. Но! Окончательный вердикт — «лечить сейчас» или «и так сойдёт» — это уже часто вопрос коллективного разума, или, как у нас говорят, «процесса». Тут уже может влезть и проджект, и тимлид, и ещё куча народу с мнением.
Главное, на что смотрят, когда решают, ебать его в сраку или пока потерпеть:
-
Влияние на юзера. Это основа основ, чувак. Всех этих багов нахуй по шкале разбрасывают:
- Blocker (Блокер) — Это полный пиздец. Приложение даже не запускается. Пользователь смотрит в чёрный экран и думает: «Ну и хуйня».
- Critical (Критический) — Запускается-то оно запускается, но сделать главное — нихуя. Нельзя купить, нельзя отправить, нельзя сохранить. Суть продукта в жопе.
- Major (Мажорный) — Жить можно, но очень неудобно. Цена криво отображается, кнопка сползла, важная функция глючит. Пользователь уже матерится, но теоретически может продолжить.
- Minor (Минорный) — Опечатка, не тот оттенок синего, иконка кривовата. «Ну, бывает», — скажет обычный человек. Перфекционист же будет страдать.
-
Как часто вылазит. Ошибка, которая случается у каждого второго пользователя — это пиздец и треш. А та, которую воспроизвести надо с бубном, при полной луне и только если имя переменной написать кириллицей — это, конечно, тоже хуйня, но с ней можно и повременить.
-
А что по бизнесу? Вот это, блядь, самый важный пункт! Ошибка в расчёте скидки — это одно. А если баг позволяет халявно выводить бабки со счетов — это уже не баг, а криминал, ёпта! Платёжная система — святое, там любая мелочь может обернуться овердохуищем проблем.
Короче, финальное решение — это часто не просто технарская оценка, а взвешивание: «А сколько это стоит по деньгам/времени/репутации?». Собираются PM, тимлид, иногда и сам QA, и начинается: «Ребята, ну этот баг, он, конечно, критический, но фича-то завтра выкатывается... Может, в следующем спринте?».
А пользователь, конечно, нихуя об этих спринтах не знает. Он просто видит, что у него не работает. Вот такая, блядь, дилемма.