или заполните форму
Серьезность и приоритет дефекта: почему один баг чинят сразу, а другой — нет
Евгений
QA Lead
Один дефект может серьезно нарушать работу системы, но не попасть в ближайший релиз. Другой почти не влияет на функциональность, при этом команда исправит его в тот же день. Противоречия здесь нет: у дефектов различаются серьезность и приоритет.
Серьезность показывает последствия дефекта для системы и пользователей. Приоритет определяет, насколько важно исправить его сейчас по сравнению с другими задачами. Разберем, как связаны эти оценки, кто их назначает и почему высокий уровень серьезности не всегда означает первый номер в очереди.
Содержание
Что такое серьезность дефекта
Серьезность дефекта, или severity, — это степень его влияния на работу компонента или системы, согласно глоссарию ISTQB.
На практике команда оценивает последствия дефекта:
- какие функции перестали работать;
- может ли пользователь завершить сценарий;
- не теряются и не искажаются ли данные;
- вызывает ли дефект сбои, зависания или падение системы;
- сколько пользователей и компонентов затронуто;
- можно ли продолжить работу обходным способом.
Например, если покупатель не может оформить заказ, дефект затрагивает ключевой пользовательский сценарий. Если у кнопки изменился цвет, но она остается заметной и работает, последствия значительно меньше.
Серьезность нельзя определить только по внешнему виду дефекта. Небольшая неточность в расчете может привести к неверной сумме заказа, а заметный дефект верстки — не помешать пользователю выполнить задачу. Поэтому оценивают не то, насколько страшно выглядит баг, а то, к чему он приводит в конкретном продукте.
Кто назначает серьезность
Часто первоначальную серьезность указывает QA-инженер или другой сотрудник, который регистрирует дефект. Он опирается на принятую в проекте шкалу и доступные данные о последствиях.
Это не универсальное правило. В одной команде тестировщик назначает оценку самостоятельно, в другой ее подтверждают QA-лид, разработчик, аналитик или участники дефект-триажа. Если после регистрации выясняется, что дефект затрагивает больше пользователей, приводит к потере данных или, наоборот, имеет надежный обходной путь, серьезность могут пересмотреть.
Важно не название должности, а единые критерии: два специалиста должны одинаково понимать, почему дефект получил конкретный уровень.
По каким критериям определяют серьезность
Набор критериев зависит от продукта, но обычно команда рассматривает несколько видов последствий.
Одни и те же обстоятельства могут влиять и на серьезность, и на приоритет, но отвечают при этом на разные вопросы. Например, обходной путь уменьшает фактические последствия для пользователя, а заодно позволяет команде отложить исправление. В некоторых компаниях наличие обходного решения учитывают только при назначении приоритета — это зависит от внутренней шкалы.
Уровни серьезности
Единой обязательной шкалы нет. Команда может использовать четыре уровня, разделять Critical и Blocker или называть категории иначе. Пример классификации выглядит так:
Единой шкалы нет для всех продуктов. Для клиники и интернет-магазина критичны разные функции и последствия. Рекомендуем дополнять уровни серьезности примерами из своего продукта.
Что такое приоритет дефекта
Приоритет дефекта, или priority, определяет его важность и место в очереди на исправление. В глоссарии ISTQB приоритет определяется как уровень бизнес-значимости, назначенный объекту, например дефекту.
Приоритет отвечает на вопрос: когда команда должна заняться этим дефектом относительно остальных задач?
При принятии решения учитывают:
- Серьезность дефекта. Чем тяжелее последствия, тем больше оснований поднять задачу в очереди. Но это не единственный фактор.
- Сроки релиза. Дефект в функции, которая должна выйти завтра, обычно важнее дефекта в модуле следующего квартала.
- Число затронутых пользователей. Массовая проблема требует более быстрой реакции, чем редкий сценарий в неподдерживаемой конфигурации.
- Влияние на бизнес и обязательства перед клиентами. Учитывают продажи, конверсию, SLA, договоренности и требования регуляторов.
- Репутационные риски. Заметный дефект на главной странице может не ломать систему, но повлиять на доверие пользователей.
- Обходное решение. Если работу можно безопасно продолжить другим способом, исправление иногда переносят.
- Зависимости и стоимость исправления. Команда учитывает, блокирует ли дефект другие задачи и можно ли внести исправление без риска для релиза.
Кто определяет приоритет
Приоритет может назначать владелец продукта, менеджер проекта, тимлид, аккаунт-менеджер или команда на сортировке дефектов. Иногда первоначальное значение указывает и тестировщик, а потом его уточняют вместе с остальными участниками.
Порядок зависит от процесса компании. Главное, чтобы приоритет отражал общее решение команды, а не личную срочность автора задачи.
В чем разница между серьезностью и приоритетом
Серьезность и приоритет не делят дефект на «техническую» и «бизнесовую» части. Обе оценки могут учитывать влияние на систему, пользователей и компанию. Разница заключается в вопросе, на который они отвечают.
Серьезность: насколько велики последствия дефекта?
Приоритет: насколько важно исправить его сейчас?
Сочетания двух оценок можно показать на простых примерах:
Один и тот же баг может получить разные оценки в тестовой среде и рабочем продукте или до и после запуска рекламной кампании.
Кейс: средняя серьезность и высокий приоритет
О клиенте
Крупный интернет-магазин товаров для дома и ремонта. Основной трафик приходился на мобильные устройства, особенно во время рекламных кампаний и сезонных распродаж.
Команда развивала мобильную версию сайта: запускала новые категории, обновляла корзину и оформление заказа.
Проблема
Во время тестирования наша QA-команда обнаружила дефект: на части Android-устройств кнопка «Оформить заказ» периодически смещалась вниз после обновления корзины.
Кнопка оставалась доступна, поэтому оформление заказа не было полностью заблокировано. Дефект затрагивал часть устройств и усложнял пользовательский сценарий, поэтому получил средний уровень серьезности.
После запуска рекламной кампании аналитика показала рост числа незавершенных корзин, снижение мобильной конверсии и увеличение обращений в поддержку. Сами последствия дефекта не превратили его в отказ всей системы, но изменился бизнес-контекст: исправление понадобилось срочно.
Решение
Команда подняла приоритет дефекта и взяла его в работу.
Дополнительно специалисты:
- пересобрали логику обновления интерфейса после изменения корзины;
- повторно протестировали оформление заказа на популярных Android-устройствах;
- проверили полный пользовательский сценарий;
- добавили скриншотные (визуальные) автотесты для корзины.
QA и продуктовая команда также договорились пересматривать приоритеты перед крупными маркетинговыми активностями, а не оценивать очередь только для обычной нагрузки.
Результат
После исправления мобильная конверсия вернулась к прежним показателям, количество брошенных корзин и обращений в поддержку снизилось.
Кейс показывает, как дефект средней серьезности получает высокий приоритет. Он не останавливал систему полностью, но в период рекламной кампании мешал большому числу пользователей и влиял на продажи.
Кейс: высокая серьезность и более низкий приоритет
О клиенте
Производственная компания выпускает упаковку для ритейла и FMCG-брендов. Во внутренней системе менеджеры, дизайнеры и сотрудники производства управляли заказами, согласовывали макеты и отслеживали загрузку.
Проблема
Во время тестирования QA-инженер обнаружил дефект: при определенном сценарии система могла зависнуть во время формирования производственного отчета. Часть данных появлялась с задержкой, а сервис приходилось перезапускать вручную.
Дефект нарушал работу ключевой функции и приводил к зависанию системы, поэтому по принятой в проекте шкале получил критический уровень серьезности (Critical).
Затем команда уточнила контекст:
- отчет использовали несколько сотрудников;
- сценарий запускали раз в неделю;
- производство и отгрузки не останавливались;
- данные можно было временно выгрузить вручную.
Параллельно компания готовила запуск нового личного кабинета для клиентов, а ресурсы разработки были ограничены.
Решение
После сортировки серьезность оставили высокой, но исправление отчета поставили ниже задач, необходимых для запуска личного кабинета, и перенесли в следующий релиз.
На это время команда:
- описала обходной сценарий для сотрудников;
- добавила мониторинг ошибок;
- ограничила запуск проблемного отчета для части ролей.
Результат
Компания выпустила личный кабинет в запланированный срок. Дефект отчета оставался зарегистрированным и контролируемым, сотрудники пользовались временным решением, а производство продолжало работать.
Часто задаваемые вопросы
Кто определяет приоритет дефекта?
Это зависит от процесса компании. Приоритет может назначать владелец продукта, менеджер, тимлид или команда на дефект-триаже. QA-инженер также может предложить первоначальное значение.
Кто выставляет серьезность бага?
Часто первоначальную серьезность указывает QA-инженер или другой автор дефекта. В неоднозначных случаях ее уточняют с разработчиком, аналитиком, QA-лидом или всей командой на триаже.
Может ли у дефекта быть высокий приоритет и низкая серьезность?
Да. Например, опечатка в названии продукта на главной странице не нарушает функциональность, но перед рекламной кампанией ее потребуется исправить срочно.
Как часто пересматривать приоритеты дефектов?
Приоритеты пересматривают на триажах, перед релизами и при изменении обстоятельств: сроков, нагрузки, обязательств перед клиентами или бизнес-планов. Для критичных продуктов порядок также может быть закреплен в SLA и внутренних регламентах.
Какие инструменты используют для работы с дефектами?
Дефекты регистрируют в Jira, YouTrack, Redmine и других системах управления задачами. Названия полей и шкалы зависят от настроек проекта: где-то отдельно используют Severity и Priority, а где-то оставляют только приоритет или создают собственную классификацию.
Как приоритет влияет на процесс разработки?
Он помогает определить место дефекта в бэклоге, спринте или плане релиза. Высокий приоритет сам по себе не останавливает выпуск: решение зависит от критериев готовности, серьезности риска и правил конкретной команды.
Какие инструменты используют для оценки серьезности?
Отдельного инструмента, который автоматически назначает правильную серьезность, нет. Команда опирается на шаги воспроизведения, требования, логи, мониторинг, продуктовую аналитику и результаты тестирования. Автотесты помогают обнаружить и повторить дефект, но не определяют его последствия вместо человека.
Как тип продукта влияет на серьезность дефекта?
Он задает контекст оценки. Для интернет-магазина особенно важны оформление и оплата заказа, для медицинской системы — корректность и сохранность данных пациента, для игры — возможность продолжить прохождение. Один и тот же технический сбой в разных продуктах может иметь разные последствия и получить разные уровни серьезности.
Получайте полезный контент от KISLOROD в любом из мессенджеров
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Рекомендованные статьи
Оставьте заявку, чтобы обсудить проект и задачи
*
*
*