Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системы — Действие — иное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «Действие — Результат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the Cart — Proceed to Checkout — Checkout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

• У нас нет времени на тест-дизайн…
• На нашем проекте это не используется…
• Никто на проекте не говорит, какую именно технику надо использовать…
• Я тестирую только экивалентность и границы значений, и этого достаточно…
• Пожалуйста, спасите-помогите…
• Все эти техники — для задротов, реально они ничего не приносят…
• Я буду это применять, если это реально поможет уменьшать количество тестов…
• Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
• Я клоун…

Что надо сделать

1. определить happy path — их может быть несколько.
2. определить другие сценарии и ветвления к ним.
3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.