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