State transition testing полезен там, где система ведёт себя по-разному в зависимости от текущего состояния объекта. Пользователь, заказ, тикет, платёж, подписка, сессия — всё это примеры сущностей, которые проходят через статусы и набор разрешённых переходов.
Когда использовать
- →Есть явные статусы: создан, активен, заблокирован, отменён, завершён.
- →Не все переходы между статусами допустимы.
- →Поведение и доступные действия зависят от текущего состояния.
- →Баги часто связаны не с отдельным полем, а с нарушением жизненного цикла объекта.
Что нужно зафиксировать
- →Список состояний объекта.
- →Допустимые переходы между ними.
- →События, которые инициируют переход.
- →Ограничения: кто может инициировать переход, при каких условиях и что происходит после него.
Пример
Допустим, баг-репорт может быть в статусах Open, In Progress, Ready for Test, Reopened, Closed. State transition testing помогает проверить, можно ли перевести тикет напрямую в Closed, кто имеет право на Reopen и не ломается ли логика при повторном цикле исправления.
На что смотреть QA
- →Недопустимые переходы: система должна их блокировать или корректно объяснять.
- →Побочные эффекты переходов: уведомления, аудит, изменение доступов, запись в лог.
- →Повторные переходы и возвраты назад.
- →Состояния после сбоев: что будет, если операция прервётся посередине.
🔁
Если объект имеет жизненный цикл, почти всегда полезно нарисовать хотя бы простую state diagram. Это быстро показывает слепые зоны, которые сложно увидеть в списке тест-кейсов.