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