БЛОК 4. Тест-дизайн техники — 13. Decision Tables и Pairwise testing

🧭 Введение: когда условий слишком много

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

Decision Tables и Pairwise testing помогают управлять этой сложностью. Первая техника делает правила прозрачными, вторая сокращает число комбинаций без потери базового покрытия взаимодействий.

💡 Совет:

Если в задаче много условий и «если/то», сначала сделайте таблицу решений, а потом оптимизируйте набор проверок через pairwise.

✅ Вывод:

Decision Tables дают логику, Pairwise даёт экономию объёма.

⚠️ Проблема -> решение

Проблема: при множестве параметров QA либо проверяет слишком мало (пропуски), либо пытается проверить всё (перегрузка и дедлайны). Оба пути рискованные.

Решение:

Decision Table фиксирует правила и ожидаемые действия;
Pairwise сокращает комбинации, сохраняя покрытие пар параметров.

🟢 Если совсем просто:

Сначала понимаем «какие решения должны быть», затем выбираем минимальный, но сильный набор комбинаций.

🎯 Как понять, что этап прошёл успешно:

Есть таблица правил и оптимизированный набор тестов, который покрывает ключевые пары условий.

🛠️ Чем помогает и как работает

Эти техники особенно полезны для бизнес-логики с несколькими переключателями и условиями. Они делают тест-дизайн объяснимым для QA, аналитиков и разработчиков.

Как это работает:

Шаг 1: собираем все условия, влияющие на поведение.
Шаг 2: описываем возможные исходы/действия системы.
Шаг 3: строим Decision Table (условия -> результат).
Шаг 4: убираем невозможные/дублирующие правила.
Шаг 5: применяем Pairwise для сокращения комбинаций.
Шаг 6: фиксируем expected result и приоритет.

✅ Вывод:

Связка Decision Tables + Pairwise позволяет покрывать сложную логику без хаоса.

📚 Ключевые термины (простыми словами)

Decision Table (таблица решений) — таблица, где комбинации условий сопоставлены с ожидаемыми действиями системы.
Condition (условие) — входной параметр, влияющий на решение.
Action/Outcome (действие/исход) — что система должна сделать при заданных условиях.
Rule (правило) — одна строка/столбец таблицы: конкретная комбинация условий и результат.
Pairwise Testing (попарное тестирование) — техника, которая покрывает все пары значений параметров, не перебирая все комбинации.
Combinatorial Explosion (комбинаторный взрыв) — резкий рост количества комбинаций при добавлении параметров.
Coverage (покрытие) — степень закрытия условий, правил и взаимодействий параметров.
Expected Result (ожидаемый результат) — корректный исход для каждой выбранной комбинации.

1. Decision Tables: как фиксировать сложные правила

Decision Table нужна, когда поведение системы зависит от нескольких условий одновременно. Например: «если VIP + активная подписка + лимит не превышен -> операция разрешена».

🟢 Если совсем просто:

Таблица решений превращает запутанные правила в понятную структуру.

🎯 Как понять, что этап прошёл успешно:

Каждое важное условие учтено, и у каждой комбинации есть явный исход.

Назначение:

Сделать бизнес-логику проверяемой и прозрачной.

Простыми словами:

Это карта «при каких условиях что должно произойти».

Для новичка:

Если вы не можете объяснить правило одной фразой, скорее всего нужна таблица решений.

Аналогия:

Как таблица тарифов: набор признаков клиента сразу определяет доступные опции.

Пример:

Условия:- account_active- has_subscription- payment_overdue Результат:- allow_streaming (yes/no)

🔎 Как это происходит на практике:

QA выписывает условия из AC.
Уточняет неоднозначности с аналитиком.
Строит таблицу и согласует ожидаемые исходы.

Характеристики:

✅ Убирает двусмысленность требований.
✅ Помогает находить конфликтующие правила.
✅ Удобна для ревью с командой.

Когда использовать:

Когда результат зависит от 2+ условий и есть ветвление бизнес-логики.

✅ Вывод:

Decision Table — лучший способ сделать «если/то» логику тестируемой.

2. Pairwise testing: как сократить комбинации

Полный перебор комбинаций быстро становится неподъёмным. Pairwise строит компактный набор, где каждая пара значений параметров встречается хотя бы один раз.

🟢 Если совсем просто:

Мы не проверяем всё, но проверяем взаимодействие каждой пары параметров.

🎯 Как понять, что этап прошёл успешно:

Набор тестов покрывает все пары значений факторов при приемлемом объёме.

Назначение:

Сократить количество тестов при множестве параметров.

Простыми словами:

Pairwise — это «умная экономия» без случайного урезания покрытия.

Для новичка:

Если у вас 4–6 параметров с несколькими значениями, pairwise почти всегда полезен.

Пример:

Параметры:- browser: Chrome, Firefox, Safari- locale: RU, EN- payment_type: Card, Wallet Полный перебор: 3*2*2 = 12Pairwise: обычно 4-6 тестов

🔎 Как это происходит на практике:

QA перечисляет параметры и их значения.
Генерирует pairwise-набор (инструментом или вручную для маленького объёма).
Проверяет, что критичные бизнес-правила не потерялись.

Характеристики:

✅ Сильно уменьшает объём regression.
✅ Хорошо покрывает типовые взаимодействия параметров.
✅ Помогает выдерживать сроки.

Когда использовать:

При множестве независимых параметров и ограниченном времени.

✅ Вывод:

Pairwise — практичный способ контролировать комбинаторный взрыв.

3. Decision Table vs Pairwise: не путать роли

Новички часто думают, что это взаимоисключающие техники. На практике это разные уровни одной работы: Decision Table задаёт логику, Pairwise оптимизирует набор комбинаций.

🟢 Если совсем просто:

Decision Table = «что должно происходить», Pairwise = «какие комбинации выгодно проверить».

🎯 Как понять, что этап прошёл успешно:

Сначала построена логика правил, затем набор сокращён без потери критичных проверок.

Назначение:

Использовать обе техники по назначению и не терять качество.

Простыми словами:

Нельзя делать pairwise, если не ясны сами правила решений.

Для новичка:

Сначала таблица решений, потом оптимизация через pairwise.

Пример:

Шаг 1: Decision Table для "доступ к функции"Шаг 2: Pairwise для параметров окружения (браузер/язык/тип аккаунта)

✅ Вывод:

Эти техники работают лучше в связке, а не по отдельности.

4. Пошаговый алгоритм для junior QA

Ниже простой шаблон, который можно применять сразу в задачах с несколькими условиями.

🟢 Если совсем просто:

Условия -> таблица решений -> оптимизация комбинаций.

🎯 Как понять, что этап прошёл успешно:

Набор проверок компактный, но покрывает критичные правила и пары параметров.

Алгоритм:

Выписать условия и возможные значения.
Выписать действия/исходы системы.
Построить Decision Table.
Исключить невозможные комбинации.
Применить Pairwise к оставшимся параметрам.
Зафиксировать expected result и priority.

✅ Вывод:

Алгоритм помогает junior QA работать системно даже в сложной логике.

📊 Сравнение: Decision Table vs Pairwise

Критерий	Decision Table	Pairwise
Главная цель	Зафиксировать правила решений	Сократить количество комбинаций
Что покрывает	Логику условий и исходов	Пары значений параметров
Когда нужен	Сложные if/else правила	Много параметров и вариантов
Результат	Прозрачная карта поведения	Компактный набор тестов
Риск при пропуске	Неясная логика и дыры в правилах	Чрезмерный объём или хаотичное урезание

✅ Must-Know для junior QA

Decision Table и Pairwise не заменяют, а дополняют друг друга.
Без понятной таблицы решений pairwise может оптимизировать «не то».
Pairwise не гарантирует покрытие всех 3-way и более сложных взаимодействий.
Критичные бизнес-правила нельзя удалять ради сокращения.
Для каждой выбранной комбинации нужен expected result.
Невозможные комбинации нужно явно исключать и документировать.
Перед релизом приоритет задают риски, а не удобство выполнения.

❌ Частые мифы

❌ Миф:
Pairwise заменяет анализ требований. ✅ Как правильно:
Сначала анализ и таблица решений, потом pairwise. 📎 Почему это важно:
Иначе можно получить компактный, но бесполезный набор тестов.

❌ Миф:
Decision Table нужна только аналитикам. ✅ Как правильно:
QA активно использует её для проектирования проверок. 📎 Почему это важно:
Это снижает двусмысленность и улучшает качество тест-дизайна.

❌ Миф:
Pairwise покрывает абсолютно все риски. ✅ Как правильно:
Он покрывает пары, но не все сложные взаимодействия. 📎 Почему это важно:
Критичные кейсы нужно добавлять отдельно.

❌ Миф:
Чем больше комбинаций, тем лучше. ✅ Как правильно:
Нужно оптимальное покрытие по риску, а не полный перебор ради количества. 📎 Почему это важно:
Полный перебор часто нереалистичен по срокам.

🧩 Best Practices

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

🏁 Заключение

Decision Tables и Pairwise testing помогают QA работать с комплексной логикой без потери контроля.
Первая техника делает правила прозрачными, вторая помогает уложиться в сроки с разумным покрытием.

Для junior QA это сильный шаг к системному тест-дизайну и уверенным релизным решениям.

БЛОК 4. Тест-дизайн техники — 13. Decision Tables и Pairwise testing

БЛОК 4. Тест-дизайн техники — 13. Decision Tables и Pairwise testing

🧭 Введение: когда условий слишком много

⚠️ Проблема -> решение

🛠️ Чем помогает и как работает

📚 Ключевые термины (простыми словами)

1. Decision Tables: как фиксировать сложные правила

2. Pairwise testing: как сократить комбинации

3. Decision Table vs Pairwise: не путать роли

4. Пошаговый алгоритм для junior QA

📊 Сравнение: Decision Table vs Pairwise

✅ Must-Know для junior QA

❌ Частые мифы

❓ Часто спрашивают на собеседованиях

🚫 Типичные ошибки

Ошибка 1: Нет явных условий

Ошибка 2: Игнорируют невозможные комбинации

Ошибка 3: Сокращают критичные кейсы

Ошибка 4: Нет expected result

🧩 Best Practices

🏁 Заключение

Проверьте знания