Severity и priority. Жизненный цикл бага

Баг-репорт готов, локализован и проверен на генерализацию. Но у команды таких репортов много одновременно, и кто-то должен решить, что чинить в первую очередь. Для этого используют две независимые оценки, которые новички почти всегда путают между собой.

Чему научишься за этот урок:
— различать severity (техническая тяжесть) и priority (очерёдность починки с точки зрения бизнеса);
— расставлять обе оценки для конкретных багов с обоснованием;
— ориентироваться в жизненном цикле бага от находки до закрытия.

Severity и priority — разные оси

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

Четыре комбинации

  • Высокий severity + высокий priority — упала оплата курса целиком: чинить сразу.
  • Высокий severity + низкий priority — упал редкий экспорт отчётов, которым бухгалтерия пользуется раз в квартал: можно подождать.
  • Низкий severity + высокий priority — опечатка в названии курса на главной странице: все видят, чинить быстро.
  • Низкий severity + низкий priority — мелкая визуальная неровность в редко посещаемом разделе.
                     Priority: низкий         Priority: высокий
  Severity: высокий   упал редкий экспорт      упала оплата курса
                       отчётов (раз в квартал)  целиком — чинить сразу
  Severity: низкий     мелкая неровность в      опечатка в названии
                       редком разделе           курса на главной

Проверочный вопрос для severity: «насколько технически тяжелы последствия?» Для priority: «насколько это срочно с точки зрения бизнеса прямо сейчас?» Это два разных вопроса, и отвечать на них может даже не один и тот же человек.

Жизненный цикл бага

После того как баг заведён, он проходит стандартный путь статусов: New (заведён) → Assigned (назначен разработчику) → In Progress (в работе) → Fixed (исправлен) → Retest (тестировщик перепроверяет) → Closed (закрыт). Если проверка после Retest не прошла — баг не закрывается, а возвращается в статус Reopened и снова уходит в работу.

  New -> Assigned -> In Progress -> Fixed -> Retest -> Closed
                          ^                     |
                          |                     v (retest не прошёл)
                          +------------------ Reopened

Практика: расставь severity и priority

Разберём три бага, найденных на полигоне: 1) промокод SUMMER2026 не применяет скидку при оплате картой — воспроизводится стабильно, влияет на всех, кто использует промокод с картой; 2) при экспорте архивных отчётов за прошлые годы, которым бухгалтерия пользуется 1-2 раза в год, файл скачивается пустым; 3) на странице каталога у курса «Python для начинающих» указано неверное количество уроков (23 вместо 24), но это не мешает записаться и пройти курс.

Итог:
— severity и priority — независимые оси, путать их нельзя;
— комбинация зависит и от технической тяжести, и от того, кто и как часто сталкивается с багом;
— жизненный цикл бага — стандартный путь от New до Closed, с возможным возвратом в Reopened, если исправление не прошло проверку.

Контрольный вопрос. Severity бага описывает:

АТехническую тяжесть последствий бага для системы
БОчерёдность исправления с точки зрения бизнеса
ВВремя, за которое баг был найден тестировщиком

Подсказка: Речь про то, насколько серьёзны технические последствия, а не про то, когда чинить.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Priority бага описывает:

АОчерёдность исправления с точки зрения бизнеса
БТехническую тяжесть последствий бага для системы
ВКоличество пользователей, нашедших баг одновременно

Подсказка: Речь про то, что чинить в первую очередь, а не про техническую тяжесть.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Может ли баг иметь высокий severity, но при этом низкий priority одновременно?

АДа
БНет

Подсказка: Вспомни пример с редким экспортом отчётов, которым пользуются раз в квартал.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Выбери все верные утверждения о severity и priority:

Выберите все верные варианты.

АЭто две независимые оценки, и назначать их могут по разным критериям
БВысокий severity всегда означает высокий priority
ВНизкий severity может сочетаться с высоким priority, если баг видят все пользователи
ГSeverity зависит только от того, сколько денег теряет компания

Подсказка: Ищи утверждения, которые подтверждают независимость двух осей, а не связывают их напрямую.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Опечатка в названии курса на главной странице, которую видят все посетители сайта, — пример какой комбинации?

АНизкий severity + высокий priority
БВысокий severity + низкий priority
ВВысокий severity + высокий priority

Подсказка: Опечатка — не техническая поломка, но её видит каждый посетитель сайта.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Как называется статус бага сразу после того, как разработчик исправил его в коде, но тестировщик ещё не проверил исправление? Ответь этим статусом как в жизненном цикле урока (на английском).

Подсказка: Это статус ПЕРЕД Retest, когда код уже изменён.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Контрольный вопрос. Если после Retest баг снова проявляется, в какой статус он переходит?

АReopened
БClosed
ВNew

Подсказка: Баг не закрывается и не заводится заново с нуля — у него есть отдельный статус именно для этого случая.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. Баг: «При выгрузке годового отчёта, которым пользуются раз в квартал, отчёт не формируется, но у этой функции всего 1-2 постоянных пользователя в компании». Оцени priority этого бага и ответь одним словом.

Подсказка: Обрати внимание, как редко используется эта функция — это влияет на очерёдность исправления, а не на техническую тяжесть.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. Баг: «Оплата курса картой не проходит до конца — деньги списываются, но курс не появляется в личном кабинете, и это происходит у всех пользователей». Определи severity этого бага и ответь одним словом.

Подсказка: Подумай, насколько серьёзны технические последствия — деньги списаны, а результата у пользователя нет.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Задание. Для каждого из трёх багов из раздела «Практика» выше укажи severity (высокий/средний/низкий) и priority (высокий/средний/низкий) с кратким обоснованием (1 фраза на баг): 1) промокод SUMMER2026 не работает при оплате картой; 2) экспорт архивных отчётов (1-2 раза в год) скачивается пустым; 3) неверное количество уроков в карточке курса (23 вместо 24), запись и прохождение курса не затронуты.

Критерий приёмки: для каждого из трёх багов указаны обе оценки; баг 1 получил высокий priority (влияет на оплату у всех, кто использует промокод с картой); баг 2 получил низкий priority (функция используется 1-2 раза в год); баг 3 получил низкий severity (не мешает записаться и пройти курс); обоснование логически связано с оценкой, а не выбрано случайно.

Подсказка: Пройдись по каждому багу отдельно и спроси по очереди: насколько это технически тяжело (severity)? насколько это срочно для бизнеса прямо сейчас (priority)?

✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.

Онлайн-проверка ответа появится позже

Задание. Баг: «В личном кабинете при открытии раздела «Мои курсы» иногда страница показывает пустой список вместо купленных курсов, но после обновления страницы (F5) всё появляется корректно, данные нигде не теряются». Оцени severity этого бага и ответь одним словом.

Подсказка: Severity оценивает технические последствия по факту — теряются ли данные и ломается ли функциональность необратимо, а не то, как часто и как долго длится сбой.

✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.

Проверить ответ →

Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →

Что дальше

Теперь ты знаешь, из каких полей состоит баг-репорт, как локализовать и обобщить дефект, и как расставлять severity и priority. Осталось узнать, где всё это реально живёт и работает — в баг-трекере, инструменте вроде Jira, где баги заводят, ведут по статусам жизненного цикла и фильтруют по severity и priority. О баг-трекерах — следующий урок.

Назад  ·  ↑ В начало урока  ·  ⌂ В начало курса  ·  Вперёд →

Школа Виктора Комлева