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