В спецификации правил скидки обнаружена следующая таблица. Какой дефект делает результат для части заказов ...

rules:
  - when: {segment: new, amount: '>=10000'}
    discount: 10
  - when: {segment: new, amount: '>=5000'}
    discount: 5
  - when: {segment: new, amount: '>=10000'}
    discount: 15

Краткий ответ

Дефект — пересечение условий правил: заказ на сумму от 10 000 одновременно подходит всем трём правилам. При этом два правила задают разные скидки, поэтому результат зависит от незафиксированного порядка применения или реализации.

Таблица должна явно обеспечивать взаимоисключаемость правил либо содержать формально определённый приоритет. Для данного случая корректнее задать непересекающиеся диапазоны и устранить противоречивое дублирование.

Исторический контекст

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

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

Постановка проблемы

Правило с условием amount: '>=10000' удовлетворяет как первому, так и второму правилу. Третье правило имеет те же условия, что и первое, но возвращает другое значение.

Если система применяет первое найденное правило, скидка составит 10%. Если последнее — 15%. Если система считает пересечение ошибкой, заказ вообще может быть отклонён. Ни один из этих вариантов нельзя считать корректным без явно согласованной политики.

Главный риск — не только неправильный расчёт скидки, но и невозможность однозначно принять требование на тестировании. Разные участники будут считать правильным разные результаты.

Подробное решение

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

• срабатывает ровно одно правило;
• несколько правил разрешены, но их приоритет и способ объединения формально определены.

В данном примере естественная модель — непересекающиеся диапазоны:

rules:
  - when: {segment: new, amount: '5000..9999'}
    discount: 5
  - when: {segment: new, amount: '>=10000'}
    discount: 10

Если бизнес действительно хотел предоставить 15% для заказов от 10 000, это должно быть зафиксировано как единственное правило для такого диапазона. Нельзя молча выбирать между 10% и 15% по техническому порядку строк: порядок исполнения — это не бизнес-решение, пока он явно не согласован.

После устранения пересечений нужно проверить граничные значения: сумму 4 999, 5 000, 9 999 и 10 000. Также следует определить поведение для неизвестного сегмента и для отрицательной или нулевой суммы, если такие значения могут попасть во входные данные.

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

Ситуация из практики

В интернет-магазине действовали правила бесплатной доставки: она предоставлялась новым клиентам при заказе от 5 000 рублей и клиентам из выбранных регионов независимо от суммы. При проверке выяснилось, что часть новых клиентов из этих регионов одновременно попадала под оба правила, а система не определяла, считать ли это одним основанием или двумя льготами.

Рассматривались два варианта. Первый — оставить правила как есть и использовать порядок строк: это было быстро, но скрывало бизнес-логику и делало результат хрупким при добавлении новых правил. Второй — ввести отдельный результат «бесплатная доставка» и явно определить, что повторное совпадение не меняет результат; этот вариант требовал уточнения требований, но устранял неоднозначность.

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

Что кандидаты часто упускают

1. Достаточно ли назначить приоритет правилам, чтобы устранить дефект?

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

2. Чем пересечение правил отличается от неполноты таблицы?

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

3. Когда можно оставить несколько совпадающих правил без ошибки?

Только когда модель явно задаёт их совместную семантику. Например, одно правило может назначать базовую скидку, а другое — дополнительную, причём способ объединения заранее определён и проверяем. Если правила возвращают альтернативные значения одного атрибута, как 10% и 15%, без приоритета или операции выбора пересечение остаётся дефектом.