Decision table, state transition, pairwise, exploratory testing

После эквивалентного разбиения и граничных значений следующий шаг в развитии QA — научиться выбирать технику под конкретный тип задачи. В реальной работе редко бывает одна универсальная схема. Где-то важны комбинации условий, где-то переходы между состояниями, где-то нужно быстро исследовать новую зону без полного набора тест-кейсов. Именно поэтому полезно понимать decision table, state transition, pairwise и exploratory testing.

Decision table

Decision table полезна там, где поведение системы зависит от сочетания нескольких условий. Например, скидка может зависеть от роли пользователя, суммы заказа и типа промокода. Если пытаться держать это в голове, легко забыть важную комбинацию. Таблица решений помогает явно перечислить условия, возможные сочетания и ожидаемые результаты.

→Decision table особенно хороша для бизнес-правил и условий доступа.
→Она делает сложную логику видимой и проверяемой.

State transition

State transition подходит для систем, у которых есть явные состояния и правила переходов между ними: заказ создан, оплачен, отменен, возвращен; пользователь активен, заблокирован, удален; подписка trial, active, expired. Здесь важно не только проверить отдельное состояние, но и то, какие переходы допустимы, какие недопустимы и что происходит после последовательности действий.

→Техника особенно сильна в workflow-системах.
→Она помогает находить ошибки в логике процесса, а не только в отдельных экранах.

Pairwise testing

Pairwise testing полезно, когда параметров много, а полный перебор комбинаций слишком дорогой. Суть в том, чтобы покрыть все пары значений между параметрами, потому что большое количество дефектов возникает уже на уровне взаимодействия двух факторов. Например, браузер, язык, роль пользователя, тип оплаты и валюта могут давать огромное число комбинаций. Pairwise помогает сократить набор тестов до управляемого объема.

→Pairwise — это компромисс между покрытием и затратами.
→Техника особенно полезна в конфигурационном и compatibility testing.

Exploratory testing

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

→Exploratory testing не означает хаос.
→Хороший exploratory session все равно имеет цель, фокус и заметки.

Как выбирать технику под задачу

Если у тебя много условий и бизнес-правил — думай о decision table. Если есть статусная логика и переходы — state transition. Если много параметров и конфигураций — pairwise. Если новая или слабо документированная зона — exploratory. Сильный QA не привязывается к одной технике, а подбирает инструмент под проблему.

→Техника должна вытекать из природы задачи.
→Хорошее тестирование почти всегда сочетает несколько подходов.

Практический взгляд для QA

Новичку не обязательно превращать эти техники в сложную академию. Достаточно уметь распознавать ситуации, где они дают выгоду. Даже простая таблица условий, карта состояний или короткая exploratory-сессия уже заметно повышают качество тестирования по сравнению с бессистемным перебором.

→Тест-дизайн — это про структуру мышления, а не про красивые названия.
→Главное — уметь выбирать технику осознанно.

Вывод

Decision table, state transition, pairwise и exploratory testing решают разные задачи, но все они помогают тестировщику выйти за пределы случайных проверок. Чем лучше QA понимает, какую проблему решает каждая техника, тем сильнее становится его тест-дизайн и тем разумнее расходуются время и усилия команды.