Decision tables особенно полезны там, где поведение системы зависит от сочетания нескольких условий. Вместо хаотичного перечисления сценариев QA раскладывает логику по комбинациям и видит, какие правила уже покрыты, а какие ещё нет.
Когда техника особенно сильна
- →Есть несколько входных условий, которые вместе определяют результат.
- →Логика описана текстом и легко теряется в деталях.
- →Нужно проверить не только happy path, но и конфликтующие или редкие комбинации.
- →Есть риск, что команда по-разному понимает одно и то же правило.
Как строится decision table
- →Сначала перечисляются условия, влияющие на поведение системы.
- →Потом фиксируются возможные состояния этих условий: да/нет, валидно/невалидно, роль A/роль B и так далее.
- →После этого для каждой значимой комбинации записывается ожидаемое действие системы.
- →Наконец, таблица очищается от невозможных или бессмысленных комбинаций, чтобы не тестировать абстракции ради абстракций.
Пример
Представь оформление заказа, где решение зависит от трёх факторов: товар в наличии, пользователь авторизован и оплата подтверждена. Текстом такую логику легко запутать, а таблица решений быстро показывает, когда заказ можно создать, когда нужно запросить логин, а когда операция должна быть заблокирована.
Частые ошибки
- →Пытаться заносить в таблицу все возможные состояния без анализа реальной значимости.
- →Не отделять невозможные комбинации от реальных.
- →Фиксировать действия системы слишком расплывчато, без конкретного ожидаемого результата.
- →Использовать таблицу как красивый артефакт, но не превращать строки таблицы в реальные проверки.
Decision tables дают QA сильное преимущество: они превращают размытые бизнес-правила в прозрачную карту решений. Это особенно ценно в fintech, e-commerce, доступах, скидках, тарифах и workflow-системах.