Decision tables особенно полезны там, где поведение системы зависит от сочетания нескольких условий. Вместо хаотичного перечисления сценариев QA раскладывает логику по комбинациям и видит, какие правила уже покрыты, а какие ещё нет.
Когда техника особенно сильна
- →Есть несколько входных условий, которые вместе определяют результат.
- →Логика описана текстом и легко теряется в деталях.
- →Нужно проверить не только happy path, но и конфликтующие или редкие комбинации.
- →Есть риск, что команда по-разному понимает одно и то же правило.
Как строится decision table
- →Сначала перечисляются условия, влияющие на поведение системы.
- →Потом фиксируются возможные состояния этих условий: да/нет, валидно/невалидно, роль A/роль B и так далее.
- →После этого для каждой значимой комбинации записывается ожидаемое действие системы.
- →Наконец, таблица очищается от невозможных или бессмысленных комбинаций, чтобы не тестировать абстракции ради абстракций.
Пример
Представь оформление заказа, где решение зависит от трёх факторов: товар в наличии, пользователь авторизован и оплата подтверждена. Текстом такую логику легко запутать, а таблица решений быстро показывает, когда заказ можно создать, когда нужно запросить логин, а когда операция должна быть заблокирована.
Частые ошибки
- →Пытаться заносить в таблицу все возможные состояния без анализа реальной значимости.
- →Не отделять невозможные комбинации от реальных.
- →Фиксировать действия системы слишком расплывчато, без конкретного ожидаемого результата.
- →Использовать таблицу как красивый артефакт, но не превращать строки таблицы в реальные проверки.
Decision tables дают QA сильное преимущество: они превращают размытые бизнес-правила в прозрачную карту решений. Это особенно ценно в fintech, e-commerce, доступах, скидках, тарифах и workflow-системах.
Практическая таблица решений: скидка участнику
Вымышленное правило: скидка 10% действует, только если покупатель — участник программы И сумма товаров не меньше 100 целых денежных единиц. Иначе скидки нет. Сумма уже прошла валидацию, налог и доставка исключены. Целые примеры позволяют не подменять отсутствующее правило округления.
Правило Участник? Сумма >= 100? Сумма примера Скидка После скидки
R1 Нет Нет 80 0% 80
R2 Нет Да 120 0% 120
R3 Да Нет 80 0% 80
R4 Да Да 120 10% 108Два независимых булевых условия дают четыре комбинации; все допустимы в этой спецификации. Таблица явно показывает правило И: только участия недостаточно, как недостаточно и только большой суммы. Если в продукте комбинация невозможна, запишите основание до удаления соответствующего правила.
Превращаем правило в тест-кейс
Кейс DT-R4
Предусловия: авторизованный участник; сумма 120; других акций нет.
Действие: запросить итог заказа.
Ожидание: ставка 10%; сумма скидки 12; после скидки 108.
Контроль DT-R2: та же сумма, не участник; скидка 0; итог 120.Покрытие всех правил решения не означает покрытия числовых границ. Добавьте суммы участника 99, 100 и 101: ожидаемые ставки — 0%, 10% и 10%. Если итог к оплате может быть дробным, сначала определите точность валюты и округление. Эти проверки отличаются от самого условия применения скидки.
Упражнение: заменить И на ИЛИ
Правило меняется на «участник ИЛИ сумма не меньше 100». Какие строки изменятся? R2 и R3 теперь получают 10%; R1 по-прежнему без скидки, R4 — со скидкой 10%. Итоги приведённых примеров: 80, 108, 72 и 108. Пересчитайте таблицу до обновления тестов, чтобы старое предположение не осталось незамеченным.