После разбора ты сможешь по шаблону описать простой стабильный дефект и исправить слабый репорт по замечанию. До этого полезно разобрать оформление тест-кейса: кейс задаёт проверку, а репорт описывает уже наблюдавшееся расхождение.
Начни с наблюдения и основания
Представь вымышленный магазин. В заданных требованиях количество товара — целое от 1 до 100 включительно. На «Продолжить» значение 101 должно вызвать «Введите целое количество от 1 до 100», перехода нет.
Для учебного разбора считаем данными такие наблюдения: на сборке demo-17 в браузере DemoBrowser 1.0 на тестовом стенде после ввода 101 открывается следующий шаг, сообщения нет. После возврата в чистое исходное состояние это повторилось три раза из трёх. Остальные поля заполнены корректно.
Это придуманные условия примера, не результаты проверки нашего продукта. У тебя есть факт, ожидание и основание для сравнения. Запись «форма сломана» их не заменяет.
Дай информацию, необходимую для повторения
- 1Контекст
Сборка, окружение, исходное состояние и данные.
- 2Повторение
Какие действия приводят к наблюдению?
- 3Сравнение
Факт рядом с ожиданием и основанием требования.
- 4Границы знания
Частота попыток, реальные вложения и то, что ещё не исследовано.
Структура помогает повторить и обсудить дефект; она не устанавливает причину автоматически.
В CTFL среди типичных данных репорта названы описание проблемы, объект и окружение, условия воспроизведения, фактический и ожидаемый результаты, классификация и связанные материалы. См. ISTQB CTFL v4.0.1, §5.5, с. 56–57. Ниже — наш учебный шаблон, а не обязательный формат всех багтрекеров.
- Заголовок: где, что происходит, при каком условии.
- Окружение и версия: где наблюдалось поведение, какая сборка и релевантные настройки использовались.
- Предусловия и данные: с какого состояния начинать и какие конкретные значения нужны.
- Шаги: последовательность, которая привела к расхождению.
- Фактический результат: что действительно увидели.
- Ожидаемый результат и основание: что должно происходить по указанному правилу.
- Повторяемость и доказательства: сколько попыток выполнено, что приложено и что остаётся неизвестным.
Severity и priority в рабочем трекере могут быть обязательными, но шкала команды нужна отдельно. При отсутствии шкалы не угадывай «критичность» по настроению. Эти поля разберём в следующем материале.
Заполни шаблон на данном примере
Заголовок: «Оформление заказа: количество 101 открывает следующий шаг вместо ошибки».
Окружение: тестовый стенд учебного магазина, сборка demo-17, DemoBrowser 1.0. Предусловия: открыта форма количества, остальные обязательные поля корректны, предыдущий результат очищен. Данные: строка 101.
Шаги:
- Очистить поле количества.
- Ввести
101. - Нажать «Продолжить».
Фактический результат: открыт следующий шаг, сообщения об ошибке нет. Ожидаемый: «Введите целое количество от 1 до 100», перехода нет. Основание: заданный максимум 100 включительно и правило обработки ошибки.
Повторяемость: 3 из 3 попыток после возврата в исходное состояние — это часть условий нашего вымышленного примера. Не пиши «всегда» по трём попыткам и не переноси эту частоту на другие сборки или браузеры. Проверка других окружений здесь не проводилась.
Теперь разработчик или другой тестировщик знает, с чего начать и с чем сравнивать результат. Слова «работает неправильно» можно убрать без потери информации.
Приложи подходящее доказательство
Для описанного сценария полезна короткая запись экрана от ввода 101 до неожиданного перехода. Одиночный скриншот второго шага показывает конечное состояние, но может не показать, какое количество было введено и как пользователь туда попал. Поэтому шаги и данные остаются в тексте.
Это рекомендация выбора артефакта, а не заявление о приложенном видео: реальная запись к нашему синтетическому примеру не создавалась. В репорте нужно честно различать «приложено», «нужно собрать» и «не проверено».
В рабочем проекте используй допустимые тестовые данные. Перед отправкой вложения проверь, не видны ли чужие аккаунты, токены, реквизиты или закрытая информация. Для учебного упражнения такие данные вообще не нужны. Конкретные правила хранения и доступа определяет команда.
Не выдавай гипотезу за установленную причину
101 открывает следующий шаг
Сборка demo-17, DemoBrowser 1.0, три попытки из трёх после сброса.
Почему это происходит?
Нет анализа кода или запросов. Фраза «backend не проверяет максимум» пока только гипотеза.
Частота здесь — исходные учебные данные. Настоящее тестирование или вложение этим не утверждается.
Репорт «backend не проверяет максимум» звучит уверенно, но в наших данных есть только неожиданное поведение интерфейса. Мы не исследовали обработчик, запрос или ответ сервера. Причина может быть другой.
Опиши наблюдение, а предполагаемую причину при необходимости вынеси в отдельную гипотезу. Не заполняй пробелы выдуманными запросами, логами или идентификаторами. Если для диагностики нужна дополнительная информация, укажи, что её ещё предстоит получить.
Для этого упражнения достаточно одного воспроизводимого расхождения. Несвязанный дефект другого поля лучше описать отдельно, чтобы обсуждение и проверка исправления не смешались. Это рабочий приём для наших простых случаев, а не универсальное правило, запрещающее объединять связанные проявления одной проблемы.
Разобранные примеры
В этих репортах наблюдения специально даны условием. Реальное приложение не запускалось; заявленные частоты — синтетические данные, вложения не создавались.
Пример 1. Сообщение есть, запрет перехода не работает
Условие. По требованию Q-1 количество 1–8 допускается, 9 при «Далее» даёт «Введите число от 1 до 8» без перехода. Дано наблюдение: на тестовой сборке demo-q2, DemoBrowser 1.0 сообщение видно, но открывается подтверждение; две попытки после сброса дали одинаковый результат.
Ход разбора. Ожидаемое поведение состоит из двух частей. Сообщение соответствует правилу, но переход ему противоречит; заголовок должен указывать именно это расхождение.
Репорт и вывод. «Бронирование: при 9 местах переход происходит несмотря на ошибку». Предусловия — чистая форма, остальные поля корректны. Шаги — ввести 9, нажать «Далее». Факт — сообщение и переход; ожидание — указанное сообщение без перехода по Q-1. Повторяемость 2/2 на заданной сборке/браузере. Вложений пока нет, причина не установлена. Репорт не утверждает, что ошибка отсутствует: она как раз показана.
Пример 2. Фильтр теряется после возврата
Условие. Правило F-2 требует сохранять выбранный фильтр «Только доступные» при возврате из карточки товара в каталог. Дано: на catalog-demo-3 в DemoBrowser 1.0 после возврата встроенной кнопкой «К каталогу» фильтр выключен в 3/3 попыток, хотя перед открытием карточки он был включён.
Ход разбора. Указываем способ возврата: браузерная «Назад» в условии не проверялась. Не приписываем расхождение кешу или базе данных.
Репорт и вывод. «Каталог: фильтр “Только доступные” сбрасывается при возврате кнопкой “К каталогу”». Шаги — включить фильтр, открыть доступный товар, нажать указанную кнопку. Факт — фильтр выключен; ожидание — включён по F-2. Окружение и 3/3 берём из условия; другие способы возврата неизвестны, вложений нет. Такой текст различает подтверждённый путь и ещё не исследованные варианты.
Попробуй по образцу
Даны требования: поле числа билетов принимает целое от 1 до 8 включительно. При «Оформить» значение 9 должно дать «Введите число билетов от 1 до 8», перехода нет.
Даны наблюдения: на тестовой сборке tickets-demo-4 в DemoBrowser 1.0 значение 9 открывает следующий шаг без ошибки; две попытки из двух после сброса дали тот же результат. Остальные поля корректны. Сетевые запросы и другие браузеры не проверялись, вложения ещё не собраны.
Исправь репорт «Не работает оформление, наверное backend». По шаблону запиши заголовок, исходное состояние, данные, шаги, факт, ожидание и известную повторяемость. Не дополняй наблюдения догадками.
Показать разбор самопроверки
Один корректный ответ: «Оформление билетов: значение 9 открывает следующий шаг вместо ошибки»; окружение — заданная сборка и браузер; начать с чистой формы с корректными прочими полями; ввести 9, нажать «Оформить»; факт — переход без ошибки; ожидание — указанное сообщение, перехода нет, основание — максимум 8; повторяемость 2 из 2 после сброса. Причина неизвестна, запросы и другие браузеры не проверены, вложений пока нет. Возможны эквивалентные формулировки.
Что оставить себе
Сделай расхождение повторяемым по тексту: конкретное окружение, исходное состояние, данные, действия, факт и ожидание с основанием. Отдельно назови подтверждённое и неизвестное. Следующий шаг — разделить серьёзность и приоритет дефекта.
Источник понятий: ISTQB CTFL Syllabus v4.0.1, §5.5, проверен 05.11.2026. Авторы и правообладатель syllabus указаны в его Copyright Notice: © ISTQB, авторы редакций 4.0/4.0.1. Шаблон, магазин, билеты, сборки, браузер и наблюдения — собственные синтетические примеры «Твой Ментор». Это не реальный баг-репорт продукта, не официальный курс ISTQB и не подтверждение уровня навыка.