Таблица решений помогает проверить функцию, результат которой зависит от сочетания условий. В ней удобно увидеть не только обычный успешный путь, но и комбинации, для которых требования ничего не говорят. Каждое допустимое правило должно иметь понятный ожидаемый результат.
В упражнении Mentoring.digital используем вымышленную форму скачивания отчёта. Это учебный контракт, а не описание поведения конкретного сервиса.
Сначала запишите правила словами
Допустим, отчёт можно скачать только авторизованному пользователю с правом доступа. Если пользователь не вошёл, показывается предложение войти. Если вошёл, но права нет, показывается отказ. Если оба условия выполнены, начинается скачивание. На этом шаге требования уже задают приоритет проверки входа.
Два независимых булевых условия дают четыре сочетания. Обозначим их A: пользователь вошёл; B: есть право доступа. На уровне модели допускаем проверку B для каждого случая. В реальной системе нужно отдельно уточнить, существует ли B до определения пользователя.
Разложите сочетания по столбцам
| Условие или действие | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| A: пользователь вошёл | Нет | Нет | Да | Да |
| B: есть право | Нет | Да | Нет | Да |
| Предложить войти | Да | Да | Нет | Нет |
| Показать отказ | Нет | Нет | Да | Нет |
| Начать скачивание | Нет | Нет | Нет | Да |
Каждый столбец представляет правило. Полезно читать таблицу вертикально: заданы входные условия и все ожидаемые действия. Здесь действия взаимоисключающие по нашему контракту. Для другой функции несколько действий могут выполняться одновременно, поэтому это нельзя считать универсальным правилом таблиц.
Превратите правило в воспроизводимый тест
Для R3 подготовьте авторизованного учебного пользователя без права на отчёт. Откройте форму, запросите скачивание и проверьте отказ. Дополнительно убедитесь, что файл не выдан. Проверка только видимой надписи недостаточна, если рядом всё равно доступна ссылка на содержимое.
Для R4 используйте пользователя с правом и убедитесь, что скачивается нужный отчёт. Для R1 проверьте предложение войти и отсутствие выдачи файла. R2 сначала обсудите с владельцем требований: если наличие права без пользователя невозможно по модели данных, столбец нужно отметить как недостижимый с обоснованием, а не пытаться создать вымышленное состояние.
У тест-кейса должны быть исходное состояние, конкретные данные, действие и ожидаемый результат. После выполнения отдельно записывают фактический результат. Галочка в таблице ожиданий не означает, что тест уже пройден.
Когда можно сократить таблицу
Если результат не зависит от B при A = Нет, R1 и R2 можно объединить, указав «неважно» для B. Сначала подтвердите это правилом, затем сокращайте. Не путайте несущественное условие с невозможным сочетанием: причины исключения различаются.
Покрытие таблицы считают относительно допустимых правил. Даже покрытие всех её столбцов не доказывает отсутствие ошибок за пределами модели: остаются сетевые сбои, неверный формат данных, граничные значения и последовательности действий. Для них нужны другие проверки.
Для тренировки добавьте условие «отчёт готов» и заново согласуйте ожидаемые действия. Такой разбор можно включить в обучение тестированию с практикой. Противоречивое ТЗ удобно разобрать с наставником по QA до написания большого набора тестов.
