В таблице решений есть комбинация условий, которая считается невозможной. Как поступить с ней при планировании тестов?
Невозможную комбинацию не следует автоматически включать в исполняемые тесты. Сначала нужно подтвердить ограничение, зафиксировать причину исключения и проверить ближайшие допустимые комбинации, особенно те, которые могут возникнуть из-за ошибки валидации или изменения бизнес-правил.
Таблицы решений применяют для формализации сложных правил, когда результат зависит от сочетания нескольких условий. Подход помогает увидеть пропущенные варианты, но при росте числа условий появляются комбинации, которые противоречат друг другу или ограничениям предметной области.
Если тестировать такие сочетания без анализа, команда тратит время на сценарии, которые пользователь не может выполнить. Если без проверки исключать их из модели, можно скрыть ошибку в самих требованиях или в механизме валидации входных данных.
Предположим, правило зависит от статуса клиента и способа оплаты. Комбинация «клиент не идентифицирован» и «оплата разрешена только идентифицированным клиентам» может быть невозможной после корректной валидации.
Риск состоит в том, что слово «невозможная» может означать разные вещи: комбинация запрещена бизнес-правилом, недостижима через пользовательский интерфейс или просто не встречалась в прежних сценариях. В первых двух случаях тест нужно исключить из обычного набора с обоснованием, а в третьем — его нельзя считать невозможным.
Сначала проверяют источник ограничения: требования, модель состояний, правила валидации и фактические способы вызова системы. Если ограничение подтверждено, комбинацию помечают как неприменимую или недостижимую, а причину фиксируют в таблице решений или тестовой документации.
Затем проверяют допустимые комбинации по обе стороны ограничения. Это позволяет убедиться, что система корректно принимает валидный вариант и отклоняет минимально изменённый невалидный вариант. Важно также проверить сам механизм, который не допускает невозможное сочетание: например, валидацию формы, авторизацию или проверку согласованности данных.
Нельзя подменять невозможную комбинацию произвольным тестом только ради увеличения покрытия. Такой тест будет либо постоянно падать из-за корректного отказа, либо закрепит поведение, которого нет в требованиях. Однако если данные могут поступить напрямую через API, импорт или другой интеграционный канал, комбинацию следует проверить как негативный сценарий: система должна предсказуемо отклонить её и вернуть корректную ошибку.
Компромисс заключается в балансе между полнотой и стоимостью тестирования. Исполняемый тест для каждой невозможной комбинации обычно не нужен, но доказательство невозможности и проверка защитного поведения должны оставаться видимыми.
В системе выдачи кредита таблица решений содержит сочетание «возраст младше минимального» и «кредит одобрен». Бизнес-аналитик считает его невозможным, потому что интерфейс не позволяет отправить такую заявку.
Можно полностью удалить строку из тестов. Это дёшево, но не проверяет загрузку заявок из внешнего канала. Можно оставить её как обычный позитивный сценарий, но тогда тест закрепит некорректное одобрение. Третий вариант — проверить два допустимых соседних случая и отдельно отправить внешнюю заявку с несовместимыми данными.
Выбирается третий вариант: таблица помечает сочетание как недопустимое, а интеграционный тест проверяет отказ с понятной причиной. Такой подход одновременно подтверждает бизнес-ограничение и защищает систему от обхода пользовательской валидации.
1. Нужно ли тестировать невозможную комбинацию, если пользовательский интерфейс её не создаёт?
Да, если данные могут попасть в систему другим путём: через API, импорт, интеграцию или ошибку клиента. В этом случае проверяют не успешную обработку комбинации, а корректное отклонение, целостность данных и отсутствие непредусмотренного побочного эффекта.
Если других путей поступления нет и невозможность доказана архитектурно, отдельный исполняемый тест может быть избыточен. Но решение об исключении нужно документировать, иначе при изменении интерфейса ограничение легко будет забыто.
2. Чем недостижимая комбинация отличается от непротестированной?
Недостижимая комбинация не может возникнуть при выполнении явно заданных ограничений системы. Непротестированная комбинация лишь ещё не проверялась; отсутствие теста не доказывает её невозможность.
Чтобы провести различие, нужно найти источник ограничения и проверить его на практике или анализом модели. Простого утверждения разработчика или отсутствия сценария в интерфейсе недостаточно.
3. Что делать, если аналитики по-разному трактуют невозможность комбинации?
Комбинацию нельзя молча исключать. Её нужно вынести на уточнение требований, описать противоречие и временно выбрать безопасное ожидаемое поведение — обычно отказ с диагностируемой ошибкой, если это не противоречит требованиям безопасности и бизнеса.
После согласования правило обновляют в таблице решений и добавляют тест на выбранное поведение. Иначе разные команды будут строить тесты на разных трактовках, а дефект требований проявится поздно.