Блог
Теория и инструменты тестирования

Таблица принятия решений в тест-дизайне

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

Как построить таблицу: пример с загрузкой JPEG

Возьмём форму загрузки изображения с тремя требованиями: файл должен быть в формате JPEG, весить не менее 32 килобайт и иметь разрешение сторон не менее 150×150 пикселей. Каждое требование — это условие, которое может быть выполнено или не выполнено, то есть у нас три условия с двумя состояниями каждое. Формула количества правил простая: два в степени количество условий. Для трёх условий получаем восемь возможных комбинаций — и восемь строк таблицы.
Каждая строка описывает конкретное сочетание условий и то действие системы, которое должно из него следовать. Если все три условия выполнены — файл успешно загружается. Если не выполнено только требование по формату — система показывает сообщение «Загрузите JPEG». Если нарушены сразу два условия — пользователь должен увидеть оба сообщения об ошибке одновременно, а не только одно из них. И так далее для всех восьми комбинаций, включая случай, где нарушены сразу все три требования.
Как только таблица построена, каждая её строка становится отдельным тест-кейсом с чётким ожидаемым результатом. Это превращает расплывчатую формулировку «протестируй загрузку файла» в конкретный и исчерпывающий список проверок, который можно раздать команде или прогнать самостоятельно.

Что даёт эта техника, кроме самих тест-кейсов

Главная неочевидная польза таблицы принятия решений — она вскрывает пробелы в требованиях ещё до того, как вы начали тестировать. Пока вы вручную прописываете все восемь строк, легко наткнуться на комбинацию, для которой аналитик не описал ожидаемое поведение системы: неясно, какое сообщение должно появиться, если нарушены два условия из трёх, или должно ли оно быть одно общее вместо двух отдельных. Это сигнал вернуться к требованиям и уточнить логику до того, как баг из-за неполного требования попадёт в продакшн.
Помимо этого, таблица делает сложную бизнес-логику наглядной. Вместо того чтобы держать ветвление в голове или пытаться описать его текстом, вы видите все правила сразу перед собой — а такой формат понятен и разработчику, и аналитику, и заказчику без специальной подготовки.

Плюсы и минусы техники

Из сильных сторон — визуализация всех важных комбинаций сразу, применимость к любой логике с ветвлением и то, что метод помогает находить недостающие требования. Из ограничений — таблица принятия решений упрощает логику и сама по себе не проверяет тонкие границы вроде 31, 32 и 33 килобайт для веса файла или поведение при пустом файле: для этого нужны отдельные техники, прежде всего граничные значения. Она не исчерпывающая — часть сценариев всё равно можно упустить, если условия выбраны неточно. И она плохо масштабируется: три условия дают восемь правил, а десять условий дают уже 1024 строки, с которыми работать вручную нереально. Наконец, таблица не расставляет приоритеты — если строк тридцать-сорок, все они формально «равны», и решать, какие проверять в первую очередь, приходится команде самостоятельно.

Когда применять и когда условий слишком много

Оптимальная зона применения — от трёх до пяти условий. При таком количестве таблица остаётся обозримой и её реально построить и прогнать целиком. Если условий больше, часть комбинаций обычно оказываются логически противоречивыми — то есть физически не могут выполняться одновременно, — и их можно сразу отбросить, сократив реальное число рабочих строк. Стоит помнить и о том, что действий в ответ на условия может быть больше одного: помимо текстового сообщения об ошибке, система может проигрывать звук, писать событие в лог или менять состояние интерфейса — всё это тоже нужно закладывать в таблицу как отдельные колонки действий.
Важно не путать таблицу принятия решений с pairwise-тестированием — они решают разные задачи, хотя обе работают с комбинациями параметров. Pairwise применяется там, где результат одинаковый при любой комбинации значений (например, фильтр поиска работает одинаково независимо от сочетания параметров, и достаточно проверить уникальные пары). Таблица принятия решений нужна там, где результат отличается в зависимости от конкретной комбинации условий — как в примере с валидацией формы, где разные сочетания дают разные сообщения об ошибках.
Умение быстро построить таблицу принятия решений и с ходу отличить её от смежных техник — то, что реально проверяют на технических собеседованиях: часто дают форму с несколькими условиями и просят прямо на месте набросать таблицу. В Quality Academy на курсе «Инженер по ручному тестированию» такие задачи разбираются не абстрактно, а на реальных формах и требованиях — ученики строят таблицы принятия решений в домашних заданиях и получают обратную связь от ментора, если логика где-то не сходится.
-------

Полезные ссылки школы

Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena