После разбора ты сможешь по готовому списку выделить правила одного поля, отделить известное от предположений и записать проверяемое условие после уточнения требований. Нужно различать входные данные, действие пользователя и ожидаемый результат.
Начни с того, что действительно написано
Представь задачу для учебного магазина: «Покупатель может добавить до 100 товаров. При неправильном количестве показать ошибку».
При неправильном количестве показать ошибку.
Есть ограничение количества
Упомянуто 100 и сообщение об ошибке.
Но как оно работает?
- Входит ли 100 в диапазон?
- Можно ли 0 или 2.5?
- Когда проверять и блокировать ли переход?
Сплошная рамка — факт из текста. Пунктир — вопросы, а не готовые ожидания.
Рука тянется сразу написать проверки: 0, 1, 100, 101. Но пока непонятно, почему именно такие ожидания должны быть у программы. Разрешено ли нулевое количество? Включается ли 100 в допустимый диапазон? Может ли пользователь заказать половину единицы товара? Ошибка заменяет значение или мешает продолжить оформление?
Вопросы появляются ещё до запуска приложения. Проверка текста требований может выявлять неоднозначности и пропуски — это одна из задач статического тестирования. См. ISTQB CTFL v4.0.1, §3.1.3, с. 34.
Для нашего примера полезно сделать две записи:
- Известно: речь идёт о количестве товаров; указан предел 100; при неверном количестве требуется ошибка.
- Нужно уточнить: тип значения, нижний предел, включение верхнего предела, обязательность ввода и конкретное поведение при ошибке.
Пока ответ не получен, фраза «0 должно отклоняться» — предположение. Его можно обсудить с аналитиком, но нельзя незаметно превратить в утверждённый ожидаемый результат.
Используй один список вопросов
Для одного поля начни с пяти пунктов:
- Тип и формат. Что можно вводить: целые числа, дробные значения, текст? Как обрабатываются пробелы и пустой ввод?
- Допустимые значения. Каковы минимум и максимум? Включены ли сами пределы?
- Контекст. Для каких товаров и пользователей действует правило? Не описан ли другой случай отдельным требованием?
- Момент проверки. Когда пользователь узнаёт об ошибке: во время ввода, при выходе из поля или при продолжении?
- Наблюдаемый результат. Что происходит при корректном и некорректном вводе: появляется сообщение, меняется состояние кнопки, выполняется переход?
Это предложенный рабочий список для данного упражнения, а не универсальный стандарт полноты требований. В конкретной задаче его могут дополнять правила доступности, прав доступа, взаимодействия с сервером и другие условия.
Пиши вопрос так, чтобы на него можно было ответить. Вместо «Что делать с ошибками?» спроси: «При количестве 101 нужно заблокировать переход к оплате? Какое сообщение показать?» Если предлагаешь вариант, подпиши его как предложение.
Преврати уточнение в проверяемые правила
Теперь для учебного примера считаем, что аналитик дал такой ответ:
- Поле обязательное. Разрешены только цифры от 0 до 9, без знака, пробелов и дробного разделителя. Ведущие нули разрешены.
- Числовое значение — от 1 до 100 включительно.
- Проверка выполняется при нажатии «Продолжить».
- При допустимом значении открывается следующий шаг оформления.
- При пустом вводе, неверном формате или выходе за диапазон показывается «Введите целое количество от 1 до 100». Следующий шаг не открывается.
Это новые явно заданные условия упражнения. Они не были выведены из исходной фразы «до 100» и не описывают все реальные магазины.
Теперь у проверок есть основание:
- Ввести
25и нажать «Продолжить»: открывается следующий шаг. - Ввести
101: появляется указанное сообщение, перехода нет. - Оставить поле пустым: то же сообщение, перехода нет.
- Ввести
2.5: ошибка формата, даже несмотря на то, что число находится между 1 и 100.
Для каждой проверки можно показать правило, которое задаёт ожидание. Если условия изменятся, будет видно, какие ожидания пересмотреть.
- 1Вопрос
Включается ли 100?
Что происходит при 101? - 2Явное уточнение
1–100 включительно.
При 101 — ошибка, перехода нет. - 3Проверка
Ввести 101 → «Продолжить» → сравнить сообщение и отсутствие перехода.
Уточнение здесь дано для учебного магазина. Его нельзя вывести из одной фразы «до 100».
Не подменяй вопрос своим решением
Допустим, приложение автоматически заменяет 101 на 100. Если уточнённые требования запрещают переход и требуют сообщения, это наблюдаемое расхождение. Если способ обработки нигде не задан, сначала нужно выяснить ожидаемое поведение. Одна и та же реализация оценивается в контексте разных требований по-разному.
Обратная ошибка — проверять только наличие сообщения. В нашем примере важно и отсутствие перехода. Сообщение может появиться, а оформление всё равно продолжиться.
Ещё одна ловушка — записать «проверить некорректное значение» без конкретного ввода. Такой пункт не показывает, проверен ли пустой ввод, формат или диапазон. Укажи значение и причину, по которой оно должно быть отклонено.
Разобранные примеры
Оба разбора ниже синтетические. Уточнения заданы для обучения и не являются правилами настоящего сервиса.
Пример 1. Срок бронирования без нижнего предела
Условие. В задаче написано: «Бронь хранится до 48 часов». Нужно подготовить проверку ввода срока.
Ход разбора. Из фразы нельзя получить минимум, формат, включение 48 и результат ошибки. Сначала спрашиваем: «Можно ли 0 или 1,5 часа? Допускается ли 48? Когда сохраняется значение?». Для примера дан ответ: обязательное целое 1–48 включительно, только цифры; при «Сохранить» неверный срок вызывает «Введите целый срок от 1 до 48 часов», сохранения нет.
Проверка и вывод. В чистой форме при корректных остальных полях вводим 49 и нажимаем «Сохранить»: ожидаем заданное сообщение и отсутствие сохранения. Это ожидание основано на ответе, а не на догадке по словам «до 48». Без ответа готовый expected писать рано.
Пример 2. Корректная длина ещё не означает корректный ввод
Условие. Код приглашения обязателен: ровно 6 латинских букв A–Z в верхнем регистре. На «Применить» подходящий код передаётся на проверку существования; неверный формат даёт «Нужно 6 букв A–Z», запрос не отправляется.
Ход разбора. Разделяем длину и алфавит. Запись ABC12D содержит 6 символов, но цифры запрещены. Нельзя ожидать переход к проверке существования только из-за подходящей длины.
Проверка и вывод. Вводим ABC12D, нажимаем «Применить»: ожидаем сообщение формата и отсутствие запроса. Наличие сообщения проверяется в интерфейсе, отсутствие запроса — отдельным наблюдением в Network. Здесь описан план проверки, фактического запуска нет. Поведение для нижнего регистра не угадываем: в условии разрешён только верхний.
Попробуй по образцу
Исходное описание: «Пользователь выбирает срок хранения до 30 дней. Неверное значение сопровождается ошибкой».
Сначала по списку выше выпиши три неизвестных условия и три соответствующих вопроса. Зафиксируй их до чтения ответа аналитика: так будет видно, какие правила действительно отсутствовали в исходной фразе.
После своих вопросов: показать ответ аналитика
Уточнение для упражнения: аналитик ответил, что разрешены только цифры без пробелов/знака/разделителя; ведущие нули допустимы; поле обязательное; значение от 1 до 30 включительно; при «Сохранить» корректный срок сохраняется; иначе показывается «Введите целый срок от 1 до 30 дней», сохранения нет.
Теперь запиши одно проверяемое правило и одну проверку неверного ввода. Отдели их от первоначальных вопросов: правило уже должно опираться на полученный ответ.
Показать разбор самопроверки
Пример разбора: до уточнения неизвестны формат, включение пределов и результат ошибки. Возможные вопросы: «Можно ли дробное число?», «Входит ли 30 в диапазон?», «Блокируется ли сохранение?». После уточнения проверка 31 получает однозначное ожидание: сообщение заданного текста, срок не сохраняется. Проверка 30 должна завершиться сохранением. Эквивалентные формулировки допустимы.
Что оставить себе
Перед тест-кейсами раздели известное и неизвестное. Для каждого ожидания найди правило. Неподтверждённое предположение вынеси в вопрос. После ответа обнови правило и связанные проверки.
Следующий шаг — разбить значения поля на классы эквивалентности.
Источник понятий: ISTQB Certified Tester Foundation Level Syllabus v4.0.1, §3.1.3. Авторы и правообладатель syllabus указаны в его Copyright Notice: © ISTQB, авторы редакций 4.0/4.0.1. Источник проверен 05.11.2026. Список вопросов, магазин и упражнение про хранение — собственные учебные примеры «Твой Ментор». Материал не является официальным курсом ISTQB.