Таблицы решений и попарное тестирование

Мы уже освоили фундамент: научились разделять данные на группы и находить критические точки на границах. Но в вебе функции редко зависят от одного поля. Обычно условия наслаиваются: скидка требует и суммы в корзине, и промокода, а доступ к видео — и подписки, и нужного региона.

Когда условий много, возникает «комбинаторный взрыв». Это ситуация, где количество сочетаний растет так быстро, что проверить всё невозможно. Чтобы не утонуть в тестах и не пропустить баги, Middle-инженеры используют две техники: таблица решений и попарное тестирование.

Таблица решений: логика без пробелов

Таблица решений (Decision Table) помогает разложить сложные требования на понятные правила. Она незаменима, когда результат системы зависит от комбинации нескольких «Да» или «Нет».

Представьте кнопку «Оформить заказ». Она активна, только если:

1. Корзина не пуста.
2. Пользователь авторизован.
3. Приняты условия оферты.

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

Как устроена таблица

Инструмент состоит из четырех частей:

• Условия (Conditions): Входные данные (факторы).
• Действия (Actions): Ожидаемый результат (выход).
• Варианты: Значения условий (True/False или Да/Нет).
• Правила (Rules): Столбцы, которые показывают, какое действие следует за конкретным набором условий.

Схема 1 наглядно демонстрирует структуру этого инструмента.

Пример: Форма регистрации

Проверим логику регистрации на вебинар. Условия: валидный e-mail и согласие с правилами. Действие: активация кнопки.

Условия / Правила	R1	R2	R3	R4
E-mail валиден?	Да	Да	Нет	Нет
Согласие дано?	Да	Нет	Да	Нет
Кнопка активна?	Да	Нет	Нет	Нет

Совет наставника: Если таблица разрослась, ищите невозможные комбинации. Например, пользователь не может быть одновременно «Гостем» и «Админом». Смело удаляйте такие столбцы — это сэкономит время на тестах ⏱️

Попарное тестирование: минимум тестов, максимум пользы

Если таблица решений проверяет логику, то попарное тестирование (Pairwise Testing) спасает при проверке совместимости независимых настроек.

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

Попарное тестирование позволяет проверить все возможные пары значений. Это в десятки раз сокращает количество проверок по сравнению с полным перебором.

Кейс: Фильтр авиабилетов

Допустим, в поиске есть такие параметры:

• Класс: Эконом, Бизнес (2).
• Багаж: С багажом, Без багажа (2).
• Возврат: Да, Нет (2).
• Оплата: Карта, СБП, Крипто (3).

При полном переборе нужно $2 \times 2 \times 2 \times 3 = 24$ теста. С техникой Pairwise хватит 6–8 проверок. При этом каждое значение (например, «Крипто») хотя бы раз встретится в паре с каждым другим значением (например, «Бизнес-класс»).

График 1 демонстрирует, как стремительно растет нагрузка на тестировщика без применения этой техники.

Инструменты для Middle QA

В 2026 году никто не составляет таблицы для Pairwise вручную — это долго. Используйте генераторы:

1. PICT: Классика от Microsoft. Мощный консольный инструмент, который легко встроить в автотесты.
2. Pairwise.teremok: Быстрый онлайн-сервис — вставили список параметров, получили таблицу.
3. AllPairs: Библиотека на Python для тех, кто хочет автоматизировать создание данных 🐍

Что и когда выбирать

• Таблицы решений — когда параметры зависимы (логика «Если А и Б, то В»). Проверяем бизнес-правила.
• Попарное тестирование — когда параметров много и они независимы (ОС + Браузер + Разрешение). Проверяем совместимость.

Умение применять эти методы — водораздел между новичком и Middle-инженером. Вы не просто «тыкаете в кнопки», а проектируете оптимальное покрытие.

Теперь мы знаем, как проектировать тесты. Но где их хранить? В следующем уроке научимся превращать наши идеи в четкую документацию: чек-листы и структурированные тест-кейсы.