Тестирование переходов состояний проверяет, как система реагирует на события с учётом своего текущего состояния. Одно и то же действие может быть допустимо для черновика и запрещено для уже завершённой заявки. Поэтому проверять только отдельные кнопки недостаточно.
Для практики на Mentoring.digital построим небольшую учебную модель заявки. Правила ниже придуманы специально для упражнения и не описывают процесс конкретного сервиса.
Определяем состояния и события
У заявки четыре состояния: Черновик, Отправлена, Принята, Отменена. В этой модели отправлять можно только заполненный черновик, принимать только отправленную заявку, а отменять только черновик или отправленную заявку. Принята и Отменена являются конечными состояниями.
События: «Отправить», «Принять», «Отменить». У отправки есть условие: обязательные поля заполнены. У успешной отправки есть побочное действие: создание одного уведомления. У запрещённого перехода состояние не меняется и уведомление не создаётся.
Записываем разрешённые переходы
- Черновик + Отправить при заполненных полях → Отправлена, одно уведомление.
- Черновик + Отменить → Отменена.
- Отправлена + Принять → Принята.
- Отправлена + Отменить → Отменена.
Остальные сочетания состояния и события в нашем договоре запрещены. Например, «Принять» для черновика не должно превращать его в принятую заявку. Отправка незаполненного черновика также должна сохранять исходное состояние.
В рабочем проекте список запрещённых сочетаний нужно согласовать с требованиями. Отсутствие кнопки в интерфейсе ещё не определяет ответ API: повторное действие может возвращать ошибку или быть идемпотентным. Здесь для упражнения выбран явный отказ.
Превращаем модель в тест-кейсы
Сценарий A. Создать заполненный черновик, отправить, затем принять. После отправки проверить состояние и одно уведомление. После принятия проверить конечное состояние и отсутствие второго уведомления об отправке.
Сценарий B. Создать новый черновик и отменить. Проверить Отменена и отсутствие уведомления об отправке.
Сценарий C. Создать новый черновик, отправить, затем отменить. Проверить обе промежуточные точки, а не только финальное состояние.
Эти последовательности охватывают четыре перечисленных разрешённых перехода. Это описание запланированного покрытия, а не сообщение о выполненном тестировании реального приложения.
Запрещённые переходы проверяем отдельно
Для каждого запрещённого действия подготовьте нужное начальное состояние и выполните одну такую попытку. Затем проверьте ответ, сохранённое состояние и побочные действия. Изолированные проверки помогают не скрыть вторую ошибку первой.
Особенно полезны повторная отправка уже отправленной заявки, принятие черновика и отмена принятой заявки. Если запрещённый переход неожиданно сработал, дальнейшая цепочка уже идёт по неверному состоянию и не доказывает корректность остальных правил.
Как оценивать достаточность проверки
Посетить каждое состояние и проверить каждый переход между состояниями не одно и то же. В нашем примере путь Черновик → Отправлена → Принята вообще не проверяет отмену. Отдельно учитывайте условия переходов и изменения данных.
Конкурентные действия тоже требуют отдельного сценария: например, два запроса одновременно пытаются принять и отменить одну заявку. Простая последовательная модель помогает сформулировать допустимый результат, но сама по себе не проверяет блокировки и атомарность.
Разработку тест-кейсов можно отработать на курсах тестирования. Обсудить полноту модели и неоднозначные требования помогут наставники по QA.
