Для правила с несколькими условиями, чьи комбинации определяют результат, какую технику тест-дизайна выбрать и почему?
Выбирайте таблицу решений. Она преобразует комбинации условий в явные правила с ожидаемыми действиями и помогает проверить как допустимые, так и пропущенные варианты поведения.
Техника появилась как способ систематизировать тестирование сложной бизнес-логики, когда результат зависит не от одного входного значения, а от сочетания нескольких условий. Обычного набора позитивных и негативных сценариев в таких случаях недостаточно: отдельные условия могут быть проверены, но их комбинации — нет.
Представим правило расчёта скидки, зависящее от статуса клиента, суммы заказа и наличия купона. Ошибка может возникнуть не в обработке каждого условия отдельно, а в конкретном сочетании, например когда постоянный клиент использует купон при небольшой сумме заказа.
Если комбинации не зафиксированы явно, команда рискует пропустить правило, проверить один и тот же случай несколько раз или получить противоречивые ожидаемые результаты. Особенно опасны комбинации, для которых требования вообще не определяют поведение.
В таблице решений выделяют:
Сначала нужно выписать условия и определить их возможные значения. Затем строят комбинации, удаляют невозможные или дублирующие правила и сопоставляют каждой оставшейся комбинации ожидаемый результат. Каждое значимое правило становится кандидатом на отдельный тест-кейс.
Таблица решений полезна не только для генерации тестов, но и для проверки полноты требований. Если комбинация допустима, но для неё не указано действие, это пробел в спецификации, а не просто недостающий тест.
Полный перебор может быть слишком большим: при наличии нескольких бинарных условий число комбинаций растёт экспоненциально. Поэтому применяют ограничения предметной области, объединение эквивалентных правил или риск-ориентированный отбор, но сокращение должно быть обосновано и не должно скрывать критичные комбинации.
Попарное тестирование решает другую задачу: оно стремится покрыть взаимодействия каждой пары параметров, а не представить каждое бизнес-правило и его ожидаемое действие. Если логика выражена явными зависимостями «при такой комбинации выполнить такое действие», таблица решений обычно является более подходящей исходной моделью.
В интернет-магазине скидка зависела от типа клиента, суммы заказа и способа доставки. Команда сначала выбрала по одному позитивному и негативному тесту для каждого условия. Тесты проходили, но комбинация «новый клиент, большая сумма, экспресс-доставка» ошибочно получала скидку постоянного клиента.
Рассматривались два варианта. Попарное тестирование уменьшало количество проверок, но не гарантировало явного покрытия всех бизнес-правил. Полный перебор давал высокую полноту, однако включал невозможные сочетания и был дорогим в сопровождении.
Выбрали таблицу решений: аналитик сначала уточнил взаимоисключающие условия и приоритеты правил, затем команда оставила только допустимые комбинации с отдельными тестами для конфликтующих правил. В результате был найден дефект приоритета условий, а дальнейшее изменение требований стало проще проверять по затронутым строкам таблицы.
1. Нужно ли проверять в таблице решений все математически возможные комбинации?
Нет. Проверяют все значимые и допустимые правила, а невозможные комбинации фиксируют отдельно с объяснением причины исключения. Иначе можно потратить время на сценарии, которые система никогда не может получить, либо замаскировать неполноту требований под «неприменимость».
2. Чем таблица решений отличается от проверки каждого условия по отдельности?
Проверка условий по отдельности показывает, что система умеет обрабатывать отдельные значения. Таблица решений проверяет совместное влияние условий и ожидаемый результат конкретной комбинации. Именно это позволяет обнаружить ошибки приоритетов, конфликтующие правила и отсутствие обработки сочетаний.
3. Что делать, если две строки таблицы имеют одинаковое действие?
Их можно объединить, если различающееся условие действительно не влияет на результат и это подтверждено требованиями. Но объединение нельзя выполнять только ради сокращения числа тестов: если условие влияет на побочные эффекты, ограничения или дальнейшее состояние системы, строки должны остаться раздельными.