Многие объекты живут по статусам: заказ, заявка, подписка, карта при вводе PIN. Результат действия зависит не только от ввода, но и от текущего состояния. Для этого есть тестирование переходов состояний. А когда документации мало, помогают техники, основанные на опыте.
Диаграмма состояний
Пример: заявка.
Черновик --отправить--> На проверке --одобрить--> Одобрена
|
отклонить
v
Отклонена --исправить--> Черновик
Элементы: состояния, события (действия), переходы, иногда условия и действия при переходе (отправить письмо, вернуть деньги).
Уровни покрытия
От слабого к сильному:
- Все состояния: каждое посещено хотя бы раз. Слабо: можно пропустить переходы.
- Все допустимые переходы (0-switch): каждый переход пройден хотя бы раз. Основной стандарт.
- Пары переходов (1-switch): каждая последовательность из двух переходов. Ловит ошибки, зависящие от предыстории: «после отклонения заявка ведёт себя иначе, чем новая».
- Плюс недопустимые переходы: система корректно отказывает.
Для заявки выше один сценарий покрывает все 4 перехода: отправить, отклонить, исправить, отправить, одобрить.
Таблица состояний и недопустимые переходы
Диаграмма показывает, что можно. Таблица показывает и то, что нельзя.
| Состояние \ Событие | отправить | одобрить | отклонить | исправить |
|---|---|---|---|---|
| Черновик | На проверке | - | - | - |
| На проверке | - | Одобрена | Отклонена | - |
| Одобрена | - | - | - | - |
| Отклонена | - | - | - | Черновик |
16 клеток, 4 допустимых перехода, 12 недопустимых. Каждая пустая клетка кандидат в негативный тест: «одобрить черновик», «исправить одобренную». Проверяй их не только в интерфейсе, где кнопка может быть скрыта, но и через API.
Что ещё проверить в переходах
- Побочные действия. Отмена оплаченного заказа должна вернуть деньги, вернуть остатки, отправить письмо. Ошибка в побочном действии обычно дороже ошибки статуса.
- Счётчики. «Карта блокируется после трёх неверных PIN подряд»: проверь, что верный PIN сбрасывает счётчик. Сценарий «неверный, неверный, верный, выход, неверный, неверный» не должен блокировать карту.
- Гонки и порядок событий. Вебхуки платёжных систем могут прийти повторно или не по порядку. Старое событие «оплата не прошла» не должно откатить новое «оплата прошла».
- Одновременные действия. Оплата и отмена в одну секунду.
Опытные техники
Предугадывание ошибок (error guessing). Тесты по опыту и спискам типичных проблем: деление на ноль, пустой список, часовые пояса, 29 февраля, двойной клик по «Оплатить», очень длинные строки, эмодзи, медленная сеть.
Исследовательское тестирование. Изучение продукта, проектирование и выполнение тестов идут одновременно, следующий шаг выбирают по результатам предыдущего. Это не «тыкать наугад», если вести его сессиями:
- Чартер: цель сессии. «Исследовать оплату картой при медленной сети, чтобы найти повторные списания».
- Ограничение по времени: обычно 60-120 минут.
- Заметки по ходу: что проверил, идеи, вопросы, баги.
- Оформление дефектов сразу после.
- Разбор отчёта с тест-лидом: что дальше.
Такой подход называют SBTM (сессионное управление тестированием).
Сценарии использования (use case). Тесты по сценарию «актор делает, система отвечает»: основной поток, альтернативы, исключения. Хорошо для сквозных процессов.
Частые ошибки
- Проверять только счастливый путь.
- Не рассматривать недопустимые переходы.
- Забывать про побочные действия переходов.
- Называть исследовательское тестирование хаотичным и не уметь объяснить, как его вести и отчитываться.
Что спросят на собесе
- Как протестировать статусы заказа?
- Что такое таблица состояний и зачем она?
- Чем покрытие переходов отличается от покрытия состояний?
- Что такое исследовательское тестирование и чартер?
- Что такое error guessing? Приведи примеры.