В чём разница между Critical и Blocker?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Разница между Critical и Blocker в баг-трекинге
В контексте управления дефектами (bug tracking) и приоритизации задач, Critical и Blocker — это два уровня серьёзности (severity) дефекта, которые часто путают, но они имеют чёткие различия в воздействии на продукт и процесс разработки. Оба указывают на высокую важность, но с разной степенью срочности и блокирующего эффекта.
Определение и ключевые характеристики
Blocker (Блокирующий)
Blocker — это дефект, который полностью останавливает или делает невозможным дальнейшее тестирование или использование определённой функциональности, а часто и всего приложения. Такой баг создаёт непреодолимое препятствие для прогресса.
- Воздействие: Полная остановка работы. Примеры:
* Критический крах (crash) приложения на старте.
* Недоступность основного сценария (например, невозможность войти в систему из-за падения сервера аутентификации).
* Дефект, блокирующий прохождение других обязательных тестов.
- Приоритет в работе: Исправляется в первую очередь, так как блокирует команду. Часто требует немедленного "горячего" фикса (hotfix).
Critical (Критический)
Critical — это дефект, который приводит к серьёзному нарушению основной функциональности, но не полностью блокирует работу системы. Продукт может продолжать функционировать, но ключевые функции либо не работают, либо работают настолько некорректно, что делают использование невозможным или опасным.
- Воздействие: Серьёзная поломка ключевой функции, но без полной блокировки. Примеры:
* Потеря данных при сохранении.
* Некорректный расчёт итоговой суммы в заказе (финансовые ошибки).
* Падение основного функционала в определённом, но важном сценарии (например, невозможность оформить платеж после заполнения всех данных).
- Приоритет в работе: Исправляется сразу после Blocker'ов. Требует срочного внимания, но команда может временно обойти проблему или работать в других областях.
Сравнительная таблица
| Критерий | Blocker | Critical |
|---|---|---|
| Основное воздействие | Полная остановка тестирования или работы. | Серьёзный сбой основной функциональности. |
| Работоспособность системы | Система/функция недоступна для использования. | Система работает, но ключевая функция даёт сбой. |
| Влияние на процесс | Блокирует дальнейший прогресс по задаче или модулю. | Не блокирует полностью процесс, но делает его бессмысленным или рискованным. |
| Аналогия | Дверь в комнату заварена наглухо – попасть внутрь невозможно. | Дверь в комнату открывается, но внутри обрушился потолок – зайти можно, но находиться опасно. |
| Пример из e-commerce | Главная страница сайта не грузится для всех пользователей (ошибка 500). | На странице товара кнопка "Купить" не реагирует, но каталог просматривать можно. |
| Пример из софта | Приложение закрывается с ошибкой при запуске. | Функция "Сохранить как..." в текстовом редакторе сохраняет файл с повреждённым содержимым. |
Практические примеры в тест-кейсах
# Пример дефекта с Severity: Blocker
Сценарий: Вход в систему с валидными данными
Дано: Пользователь находится на странице логина
Когда: Пользователь вводит корректный email и пароль
И нажимает кнопку "Войти"
Тогда: Происходит redirect на страницу дашборда
---
**Фактический результат**: После нажатия кнопки сервер возвращает ошибку "500 Internal Server Error" в 100% случаев. Страница дашборда недоступна.
**Severity**: Blocker (полностью блокирует основной поток использования приложения).
# Пример дефекта с Severity: Critical
Сценарий: Оформление заказа
Дано: Пользователь добавил товары в корзину
Когда: Пользователь переходит к оформлению и подтверждает заказ
Тогда: Заказ создаётся в системе, списывается корректная сумма
---
**Фактический результат**: Заказ создаётся, но со скидки в 10% списывается двойная сумма (20%). Данные на экране и в БД не совпадают.
**Severity**: Critical (ключевая бизнес-функция работает с фатальной финансовой ошибкой, но процесс оформления формально завершается).
Важность правильной классификации
Правильное присвоение Severity (Blocker/Critical/Major/Minor) критически важно для:
- Эффективной работы команды: Разработчики и менеджмент понимают, что требовать немедленного внимания.
- Управления релизами: Blocker-дефекты почти всегда являются причиной для остановки или отката (rollback) релиза. Critical-дефекты могут отложить релиз, если не будут исправлены.
- Коммуникации с заказчиком: Чёткая терминология помогает адекватно донести серьёзность проблемы.
Важное замечание: В некоторых системах (например, Jira по умолчанию) Blocker может быть уровнем приоритета (priority), а не severity. На практике команды часто смешивают эти понятия или создают свои соглашения. Главное — иметь внутреннее соглашение (bug policy) внутри команды, которое все понимают и соблюдают. Например: "Blocker — это всё, что ломает сборку или делает билд непротестируемым, а Critical — это потеря данных или крах основной функции".