Таблицы решений
Тема дорожной карты · QA-инженер
Тестирование на основе таблиц решений — это техника проектирования тестов по принципу «чёрного ящика», которая представляет сложную бизнес-логику в виде сетки условий и соответствующих действий, обеспечивая наличие хотя бы одного тест-кейса для каждой комбинации входных данных, сопоставленной с отдельным выходным значением, и исключая пропуск правил. Каждый столбец таблицы решений представляет одно правило (уникальную комбинацию значений условий), строки представляют отдельные условия и действия, а ячейки содержат значения Y/N/- (безразличное значение) — что делает тестирование на основе таблиц решений особенно эффективным для проверки логики аутентификации, ценообразования, правил скидок и матриц разрешений. QA-инженеры переводят каждый столбец таблицы решений в конкретный тест-кейс: таблица правил ценообразования с тремя булевыми условиями (премиум-участник, применён купон, заказ свыше 100$) даёт до 8 столбцов, каждый из которых становится параметризованным тестом @pytest.mark.parametrize или строкой @DataProvider в TestNG, вызывающей API ценообразования через Postman или REST Assured и проверяющей правильность цены. Тестирование на основе таблиц решений дополняет разбиение на классы эквивалентности и анализ граничных значений в STLC: разбиение на классы эквивалентности сокращает пространство входных данных, анализ граничных значений исследует края, а таблицы решений исчерпывающе покрывают ветки с несколькими условиями, которые пропускают техники с одним условием. Документирование таблиц решений как «живой QA-документации» в Confluence или TestRail рядом с автоматизированными тест-кейсами делает бизнес-правила видимыми для владельцев продуктов и разработчиков, снижая риск недокументированной условной логики при рефакторинге в рамках SDLC.
Как это работает
Таблицы решений применяет систематические техники для решения, что тестировать: equivalence partitioning (делим input на классы с тем же поведением), boundary value analysis (off-by-one баги живут на границах), decision tables (комбинации условий), state transitions (состояния + валидные переходы), pairwise testing (все пары параметров протестированы хотя бы раз). Каждая техника торгует широтой покрытия против количества тестов.
Когда применять
Boundary value analysis — на каждом числовом input; 99% off-by-one багов прячутся на min, max, min-1, max+1. Decision tables — когда бизнес-правила комбинируют условия (цена если (premium и регион=EU и количество>10)). State transitions — для stateful-флоу (lifecycle заказа, состояния аккаунта). Pairwise-инструменты (PICT, allpairs) режут экспоненциальные комбинации до управляемого числа тестов.
Типичные ошибки
Ловушки Таблицы решений: тестируют только happy-path (в production странные input); ad-hoc тест-дизайн без traceability к требованиям (нельзя доказать, что тестировали фичу X); только техники без exploratory testing (люди пропускают неожиданное); экспоненциальный рост числа тестов без pairwise-редукции.