После разбора ты сможешь различать влияние дефекта и срочность исправления, а затем применить явно заданную учебную шкалу к описанному случаю. Сначала полезно научиться записывать наблюдения в баг-репорт: без фактов классификация быстро превращается в догадку.
Задай два разных вопроса
Что нарушено?
Доступен ли сценарий? Есть ли приемлемый обход? Повреждаются ли данные?
Почему сейчас?
Какое согласованное обязательство связано с выпуском? Есть ли текущие пользователи?
Обозначения и определения задаёт команда. Ниже используются только авторские учебные шкалы этой статьи.
Severity — серьёзность — описывает степень влияния дефекта. Priority — приоритет исправления — помогает определить порядок работы над ним. В CTFL эти данные указаны как отдельные поля репорта: ISTQB CTFL v4.0.1, §5.5, с. 57.
Для практического разбора спроси отдельно: «Что нарушено и как это влияет на затронутый сценарий?» и «Почему этим нужно заняться раньше или позже других задач?». Второй вопрос требует контекста релиза, аудитории и обязательств команды. Одного названия ошибки для ответа недостаточно.
Значения Critical, Major, S1, P1 и другие обозначения зависят от правил проекта. Нет основания автоматически переносить чужую шкалу в свой трекер. Для нашего упражнения ниже правила даны явно; это авторская учебная модель, а не политика «Твой Ментор» или универсальная шкала ISTQB.
Используй заданную шкалу серьёзности
В вымышленной команде для рассматриваемых случаев согласованы такие определения:
- S1: основной сценарий затронутой функции полностью недоступен без приемлемого обхода либо возникла потеря данных.
- S2: требуемый результат в одном режиме получить нельзя, но описан приемлемый обход; потери данных нет.
- S3: только текстовая или визуальная неточность, не меняющая смысл информации и не препятствующая действию; данные не повреждаются.
Сначала сопоставь наблюдения с определением. Если поведение не помещается в эти три учебных случая, не подгоняй его силой: нужны уточнение и более полная шкала команды. Число в названии не даёт дополнительного знания без определения.
Приемлемость обхода тоже должна быть задана. «Пусть пользователь вводит всё заново каждый час» нельзя автоматически считать приемлемым только потому, что технически это возможно.
Затем используй заданную шкалу приоритета
В той же вымышленной команде:
- P1: исправление требуется до ближайшего согласованного релиза или события, потому что затронут явно обязательный для него сценарий либо критерий приёмки.
- P2: случай идёт в ближайший плановый цикл, если такого срочного обязательства нет и условия P3 не выполнены.
- P3: допустимо отложить за текущие P1/P2, когда в условиях прямо указаны отсутствие текущих пользователей затронутой возможности и отсутствие ближайшего обязательства её включить.
Здесь не предлагается самостоятельно назначать срок всей команде. В реальном проекте нужно знать, кто подтверждает приоритет и как решаются разногласия. Роли и полномочия не одинаковы во всех компаниях; классификация тестировщика может быть предложением до согласования.
Разбери три описанных случая
Заказ не оформляется. На текущем стенде обязательный сценарий оформления полностью блокируется кнопкой, приемлемого обхода нет. Выпуск этого сценария запланирован на завтра и входит в обязательные критерии релиза. По нашей шкале — S1 и P1: есть полная блокировка и отдельно дано срочное обязательство.
Опечатка перед событием. На промостранице во вспомогательном заголовке лишняя буква. Смысл понятен, все действия доступны, данные не повреждены. На завтра запланирована кампания, а согласованный критерий её запуска прямо требует исправить эту опечатку. По заданным правилам — S3 и P1. Близкая дата не превратила опечатку в техническую блокировку; она повлияла на порядок исправления через конкретное обязательство.
Обход без срочного события. В предпросмотре отчёта один режим обрезает суммы, и прочитать их полностью невозможно. Переключение на другой режим показывает все суммы и принято командой как обход. Функцией сейчас пользуются, сохранённые данные не теряются, срочного обязательства нет. Получается S2 и P2. Если обход перестанет работать или появятся сведения о потере данных, основание серьёзности нужно пересмотреть.
Это вымышленные контексты. Без указанных условий тот же заголовок дефекта не гарантирует ту же пару значений.
Запиши основание вместо спора о ярлыке
- 1S1 / P1: оформление полностью заблокировано
Без обхода → S1. Отдельно: сценарий обязателен для завтрашнего выпуска → P1.
- 2S3 / P1: лишняя буква во вспомогательном заголовке
Смысл и действия не меняются → S3. Её исправление явно входит в критерий запуска → P1.
- 3S2 / P2: суммы не видны в одном режиме
Есть принятый обход без потери данных → S2. Функция используется, срочного обязательства нет → P2.
Это три разных синтетических случая, не последовательные статусы одного дефекта.
Запись «S1, потому что всё плохо» не помогает проверить оценку. Лучше: «Пользователь не может завершить заказ, воспроизведение дано, приемлемого обхода нет». Для приоритета добавь отдельное основание: «Этот сценарий входит в завтрашний релиз и обязателен для него».
Если известно только «кнопка не работает», нужно выяснить, какое действие заблокировано, для кого, в каких условиях, есть ли обход и что обещано к ближайшему выпуску. До ответа честнее указать, что классификация требует уточнения. Не придумывай масштаб аудитории, потери денег или обязательства ради желаемой метки.
Классификация может изменяться при новых данных. Если выросло влияние на сценарий, пересматривается основание severity. Если изменился срок обязательного события, может измениться priority при прежнем техническом проявлении. Это не повод стирать исходное наблюдение: сохрани, на каких условиях было принято каждое решение.
Разобранные примеры
Используем только учебные шкалы этой статьи. Это синтетические ситуации, а не решения о приоритетах нашего продукта.
Пример 1. Полная блокировка без ближайшего запуска
Условие. Экспорт отчёта полностью недоступен, приемлемого обхода нет, потери данных нет. Функция сейчас нужна действующим пользователям, но не связана с ближайшим согласованным релизом или иным срочным обязательством.
Ход разбора. Для severity смотрим на недоступность основного сценария затронутой функции: это S1. Для priority отдельно проверяем P1 и P3: срочного обязательства нет, но пользователи есть, значит условия обоих не выполнены.
Вывод. По нашим определениям S1/P2: сильное влияние не автоматически означает P1. В реальном проекте правила команды могут дать другой результат; здесь нельзя придумывать срок исправления или финансовые потери, которых в условии нет.
Пример 2. Неточность в ещё не используемой возможности
Условие. Вспомогательная подпись нового режима содержит лишний пробел; смысл и действия не меняются, данные не повреждаются. Режим выключен для всех текущих пользователей, ближайшего обязательства включать его нет.
Ход разбора. По влиянию это только визуальная неточность — S3. Для порядка работы даны оба условия P3: текущих пользователей нет и обязательства включения нет. P2 в нашей шкале исключает случаи P3.
Вывод. S3/P3. Если позже появится согласованный критерий ближайшего запуска, основание priority нужно пересмотреть, не меняя автоматически severity. Просто новая дата без связанного обязательства сама по себе ещё не доказывает P1.
Попробуй по образцу
Применяй только учебные определения выше. Даны два случая:
- На форме подписки лишняя буква в вспомогательном заголовке, смысл не изменён, подписка работает. Исправление этой опечатки прямо включено в критерии завтрашнего запуска страницы.
- В предпросмотре синтетического отчёта перенос строк скрывает часть сумм в одном режиме: прочитать их полностью нельзя. Другой режим показывает все суммы и явно признан приемлемым обходом. Функцией сейчас пользуются; сохранённые данные не теряются, ближайшего срочного обязательства нет.
Для каждого запиши severity, priority и по отдельному основанию для каждой метки. Затем укажи, каких данных не хватает для фразы «сохранение иногда не работает», чтобы не угадывать классификацию.
Показать разбор самопроверки
Один корректный ответ: случай 1 — S3/P1, потому что нет нарушения действия/смысла, но есть явное обязательство запуска; случай 2 — S2/P2, потому что работа нарушена при наличии принятого обхода и нет срочного обязательства. Для неопределённого сохранения нужны условия воспроизведения, влияние на сценарий/данные, наличие приемлемого обхода и контекст ближайших обязательств. Без них пару значений не назначаем.
Что оставить себе
Проверяй влияние и срочность отдельно, используй определения команды и подписывай основания. Один и тот же симптом без контекста не задаёт автоматически серьёзность и приоритет. Для реального спорного случая уточни факты и порядок согласования в своей команде.
Источник понятий: ISTQB CTFL Syllabus v4.0.1, §5.5, проверен 05.11.2026. Авторы и правообладатель syllabus указаны в его Copyright Notice: © ISTQB, авторы редакций 4.0/4.0.1. Шкалы S1–S3/P1–P3, случаи и эталоны — собственные учебные примеры «Твой Ментор», не рабочая политика продукта и не универсальный стандарт. Материал не является официальным курсом ISTQB и не подтверждает уровень навыка.