Таблица решений: как проверить сочетания условий в форме заявки

Если в форме заявки есть несколько условий, начинающие тестировщики часто проверяют только «всё заполнено правильно» и по одному отрицательному случаю на каждое поле. Для простой валидации этого иногда хватает, но для логики отправки формы — не всегда. Когда результат зависит от сочетания условий, полезнее строить таблицу решений: она показывает, какие комбинации возможны, что система должна сделать в каждой из них и какой набор тестов действительно покрывает правило.

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

Когда для формы нужна именно таблица решений

Таблица решений нужна тогда, когда одно наблюдаемое действие зависит сразу от нескольких признаков. В форме заявки это обычно не «какое число ввести в поле», а логика уровня выше: можно ли отправить данные, покажется ли успешное сообщение, уйдет ли запрос на сервер, появятся ли подсказки по ошибкам. Если вы описываете проверку как «при A и B происходит X, иначе Y», значит перед вами не просто набор входных значений, а комбинационная задача.

Частая ошибка выглядит так: тестировщик отдельно проверяет корректный телефон, отдельно отсутствие согласия и считает покрытие достаточным. Но без полного перебора сочетаний легко пропустить дефект, который проявляется только при двух отрицательных условиях сразу. Например, форма может показывать ошибку телефона, но забывать про обязательный чекбокс, или наоборот — отправлять запрос, если ошибок несколько и фронтенд обрабатывает их не в том порядке.

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

Условия и наблюдаемое действие

Учебный пример. Есть форма заявки на демо-доступ. Для отправки должны выполняться два независимых условия:

• A — телефон валиден. Поле заполнено в допустимом формате.
• B — чекбокс согласия отмечен. Пользователь установил обязательную галочку.

Наблюдаемое действие одно: что происходит после нажатия кнопки «Отправить заявку». Мы не смешиваем сюда все возможные нюансы интерфейса, а фиксируем проверяемый результат: ушел ли запрос, создана ли заявка, показано ли сообщение об успехе или ошибки остаются на форме. Это важно, потому что таблица решений строится не вокруг полей самих по себе, а вокруг реакции системы.

Для учебного разбора договоримся о таком ожидаемом поведении:

• если A=true и B=true, заявка отправляется и пользователь видит сообщение об успехе;
• если A=false, под полем телефона видна ошибка формата;
• если B=false, рядом с чекбоксом видна подсказка о необходимости согласия;
• если хотя бы одно условие ложно, запрос не отправляется.

Здесь независимость условий означает простую вещь: валидность телефона не зависит от состояния чекбокса, а чекбокс не зависит от формата телефона. Именно поэтому мы вправе строить полную таблицу из четырех сочетаний. Если бы одно условие выводилось из другого, сначала пришлось бы пересмотреть модель.

Полная таблица сочетаний

Теперь можно построить полную таблицу решений. Каждая строка — это не просто случайный тест, а отдельное правило работы формы. Даже если действие «не отправлять заявку» повторяется в нескольких строках, причины разные, а значит и проверка должна быть разной: пользователь должен увидеть именно те ошибки, которые соответствуют текущему состоянию формы.

Практический смысл последней строки часто недооценивают. Кажется, что раз система уже не отправляет форму при любой одиночной ошибке, то комбинация двух ошибок ничего нового не даст. На деле именно там нередко всплывают дефекты: показывается только одна ошибка из двух, кнопка ведет себя иначе, очищается часть полей, а иногда форма даже отправляет запрос из-за некорректного объединения условий в коде.

Если коротко, проверяемый результат таблицы таков: для двух независимых булевых условий должно быть покрыто четыре правила. Если у вас в наборе тестов только два или три случая, покрытие неполное, даже если каждая отдельная проверка кажется разумной.

Тестовые данные для каждого правила

Следующий шаг — подобрать конкретные данные на каждую строку. Здесь полезно помнить границу между техниками. Таблица решений не отвечает на вопрос, какие именно форматы телефона считать валидными и невалидными во всем многообразии вариантов. Это отдельная задача для проверок поля. Для текущей таблицы нам нужен один представитель валидного состояния и один представитель невалидного состояния, чтобы проверить именно сочетания условий.

Для выполнения таких тестов удобно держать одинаковый порядок действий:

1. Открыть пустую форму.
2. Ввести телефон по правилу текущей строки.
3. Установить или не устанавливать чекбокс.
4. Нажать кнопку отправки.
5. Проверить сообщение на форме и факт отправки запроса.

Проверяемый учебный результат: после выполнения четырех тестов вы либо подтверждаете, что каждая строка таблицы отрабатывает ожидаемо, либо фиксируете расхождение. Например, если в R4 система показывает только ошибку телефона и никак не отмечает отсутствие согласия, это уже конкретный дефект логики отображения ошибок при комбинированном нарушении условий.

Ограничения и недостижимые сочетания

В нашем учебном примере недостижимых сочетаний нет: все четыре строки реальны. Пользователь может ввести корректный или некорректный телефон независимо от того, поставил он галочку или нет. Значит, сокращать таблицу нельзя. Если кто-то убирает строку R4 со словами «это и так понятно», он не доказывает недостижимость, а просто уменьшает покрытие.

Недостижимые сочетания появляются только тогда, когда условия на самом деле не независимы. Например, если одно условие звучит как «поле пустое», а второе — «поле прошло проверку формата», комбинация «пустое и прошло проверку» может быть невозможной по самой логике проверки. Но это уже другой тип модели: перед построением таблицы придется уточнить, не дублируют ли условия друг друга и действительно ли они относятся к одному уровню абстракции.

Есть и еще одно ограничение: таблица решений не заменяет проверки самих полей. Если вы подтвердили четыре строки, это не означает, что формат телефона покрыт полностью. Отдельно могут потребоваться проверки пустого значения, лишних символов, пробелов, автозаполнения и других вариантов. Таблица решений отвечает на вопрос о сочетаниях условий, а не о полном анализе входных данных.

Если хотите проверить себя на практике, сформулируйте для своей формы два булевых условия, одно наблюдаемое действие и попробуйте честно выписать все строки. Затем задайте себе три вопроса: не пропустили ли вы сочетание, есть ли у каждой строки конкретные данные и можно ли по результату однозначно понять, отправилась форма или нет. Такой шаблон хорошо дисциплинирует даже на очень простых экранах.

По сохраненной карточке каталога курса «Ручное тестирование (Manual QA)» и официальной странице школы подтверждаются темы тестирования форм и полей, тест-кейсов и тестирования требований. Если вы выбираете обучение по этой теме, полезно спросить себя: будете ли вы самостоятельно строить таблицы по требованиям, получать разбор пропущенных сочетаний и отдельно проверять не только шаги теста, но и наблюдаемый результат формы.