Как построить тесты переходов между статусами заказа

Когда в заказе есть несколько статусов, ошибка часто прячется не в самом статусе, а в смене одного статуса на другой. Поэтому вопрос лучше формулировать узко: какие события разрешены из каждого состояния и как это доказать тестами. В учебной модели ниже у заказа есть три статуса: создан, оплачен и отменен. Мы зададим правила переходов, построим минимальный набор проверок и отдельно разберем, как не сломать исходное состояние теста.

Полезная мысль здесь такая: если вы просто увидели на экране статус «Оплачен», это еще не проверка перехода. Вы проверили состояние в одной точке времени. Чтобы проверить переход, нужно зафиксировать, из какого статуса пришел заказ, какое событие произошло и какой результат ожидается после него. Именно на этой разнице чаще всего путаются начинающие тестировщики.

Сначала отделите состояние от перехода

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

Проверка состояния отвечает на вопрос: «Что сейчас у заказа в поле status?» Например, вы открыли заранее подготовленный заказ и увидели статус «оплачен». Это полезно, но такой тест не доказывает, что оплата корректно переводит заказ из «создан» в «оплачен». Проверка перехода отвечает на другой вопрос: «Что произойдет, если к заказу в статусе создан применить событие pay?» Здесь уже нужно проверить и ответ системы, и итоговый статус.

В учебной модели примем такие правила: новый заказ создается в статусе создан; из него можно либо оплатить заказ, либо отменить его. Статусы оплачен и отменен считаем конечными: повторная оплата и отмена из них запрещены. Это не универсальное правило для всех магазинов, а только условная модель, удобная для тренировки тест-дизайна.

Постройте таблицу разрешенных переходов

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

Эта таблица сразу подсказывает объем работы. У нас три состояния и два события, значит всего 3 × 2 = 6 комбинаций «состояние + событие». Из них разрешены две, запрещены четыре. Такой подсчет полезен, потому что он защищает от типичной ошибки: протестировать только два «счастливых» сценария и решить, что модель покрыта полностью.

Еще один практический вывод: покрытие состояний не равно покрытию переходов. Если вы один раз оплатили заказ и один раз отменили другой заказ, то уже посетили все три статуса: создан, оплачен, отменен. Но вы все еще не знаете, что случится при попытке отменить уже оплаченный заказ или оплатить отмененный. Значит, переходы покрыты не полностью.

Разбейте проверки на позитивные и негативные

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

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

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

Учебный пример: как выглядит один полный набор тестов

УЧЕБНЫЙ ПРИМЕР. Допустим, у нас есть тестовые заказы O1–O6. Чтобы не смешивать сценарии, каждый тест использует отдельный заказ. Начальные данные такие: O1 и O2 создаются заново в статусе создан; O3 и O4 подготавливаются через разрешенный переход «создан → оплачен»; O5 и O6 подготавливаются через разрешенный переход «создан → отменен». Это уже показывает разницу между подготовкой состояния и основной проверкой: подготовительный шаг нужен лишь затем, чтобы привести заказ в стартовую точку теста.

Дальше выполняем шесть проверок из таблицы. Для O1 вызываем событие «оплатить» и ожидаем успешную операцию и статус оплачен. Для O2 вызываем «отменить» и ожидаем статус отменен. Для O3 повторно вызываем «оплатить» и ожидаем отказ без смены статуса. Для O4 пытаемся отменить оплаченный заказ и тоже ожидаем отказ. Для O5 проверяем запрет на оплату отмененного заказа. Для O6 — запрет на повторную отмену.

Проверяемый результат у этого набора очень конкретный: 2 успешных перехода и 4 отклоненных попытки, при этом итоговые статусы совпадают с матрицей. Если все шесть тестов прошли, учебная модель реализована без противоречий. Если, например, T4 внезапно меняет статус O4 на «отменен», это уже локализованный дефект: правило для перехода оплачен → отменен нарушено. Такой результат можно оформить без размытых формулировок, потому что исходное состояние, событие и ожидаемый итог зафиксированы заранее.

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

Как восстановить исходное состояние теста

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

Если полное создание данных перед каждым тестом слишком дорого по времени, используйте отдельные шаги подготовки, но только через разрешенные переходы. Например, тесту T4 нужен заказ в статусе «оплачен» — значит, подготовка может легально оплатить новый заказ, а уже потом выполнить основную проверку запрета на отмену. Важно лишь явно пометить, где подготовка, а где целевая проверка. Иначе в отчете будет непонятно, какая часть сценария дала сбой.

Не связывайте тесты в цепочку вида «T1 оплатил заказ, T2 на том же заказе проверил запрет отмены». Такой набор хрупкий: если T1 не отработает, T2 потеряет корректное исходное состояние и начнет падать вторично. Гораздо лучше изолировать данные: уникальный заказ на тест, отдельная подготовка и независимая проверка результата. Тогда один дефект не загрязняет остальные прогоны.

Если хотите потренировать этот подход на смежной теории, в сохраненном описании каталога курса «Основы тестирования ПО: Быстрый старт» есть темы про функциональное тестирование, тест-кейсы, таблицы принятия решений и диаграммы состояний. Официальная страница школы для этого материала недоступна, поэтому опираться стоит именно на сохраненное описание каталога, а дальше уже смотреть, хватит ли вам самостоятельной практики и проверки работ по таким заданиям.