Диаграмма состояний и переходов — техника тест-дизайна для проверки поведения системы при переходе из одного состояния в другое. В её основе лежит понятие конечного автомата — модели, с помощью которой удобно описывать процесс с ограниченным набором дискретных состояний. Практическая ценность техники в том, что каждый переход между состояниями превращается в готовый тест-кейс, а сама диаграмма наглядно показывает, какие переходы система должна поддерживать, а какие — не может произойти в принципе.
Что такое состояние и конечный автомат
Состояние — это своего рода снимок системы в конкретный момент времени. Со временем или в результате действий пользователя этот снимок меняется, и система переходит в новое состояние. Взгляд на продукт через призму состояний и переходов между ними — это и есть подход конечного автомата: у любой системы можно выделить конечное число «слепков», в которых она способна находиться, и описать, какие переходы между этими слепками возможны.
Классический пример, который проще всего держать в голове, — вода. У неё три состояния: жидкое, твёрдое (лёд) и газообразное (пар). Между этими тремя состояниями возможно шесть переходов: вода превращается в пар при нагреве и обратно в воду при конденсации, вода превращается в лёд при замораживании и обратно в воду при плавлении, а лёд может напрямую переходить в пар (сублимация) и пар — напрямую в лёд (десублимация), минуя жидкую фазу. Каждый из этих шести переходов — отдельный тест-кейс: мы проверяем не сами состояния, а именно переходы между ними и то, что система корректно меняет своё состояние при определённом действии.
Классический пример, который проще всего держать в голове, — вода. У неё три состояния: жидкое, твёрдое (лёд) и газообразное (пар). Между этими тремя состояниями возможно шесть переходов: вода превращается в пар при нагреве и обратно в воду при конденсации, вода превращается в лёд при замораживании и обратно в воду при плавлении, а лёд может напрямую переходить в пар (сублимация) и пар — напрямую в лёд (десублимация), минуя жидкую фазу. Каждый из этих шести переходов — отдельный тест-кейс: мы проверяем не сами состояния, а именно переходы между ними и то, что система корректно меняет своё состояние при определённом действии.
Примеры из реального тестирования
В продуктовом тестировании состояния встречаются повсеместно, стоит только начать их искать. Статус заказа в интернет-магазине — классическая цепочка состояний: заказ не оформлен, оформлен, собран, передан курьеру, доставлен. Каждая стрелка между соседними статусами — тест-кейс, который проверяет, что переход происходит корректно и в нужный момент.
Другой пример — сообщение в чате. Здесь можно выделить три состояния: сообщение отсутствует и в поле ввода, и в чате; сообщение введено в поле ввода, но ещё не отправлено; сообщение уже отображается в чате. Переходы между ними выглядят так: ввод символов переводит систему из первого состояния во второе, удаление всех введённых символов возвращает обратно в первое, нажатие кнопки «Отправить» переводит из второго состояния в третье, а нажатие «Редактировать» на уже отправленном сообщении возвращает из третьего состояния обратно во второе. Отдельного внимания заслуживает петля — редактирование текста, когда сообщение остаётся во втором состоянии, но его содержимое меняется. А ещё бывают переходы «напрямую» — например, удаление уже отправленного сообщения переводит систему сразу из третьего состояния в первое, минуя промежуточные шаги.
Другой пример — сообщение в чате. Здесь можно выделить три состояния: сообщение отсутствует и в поле ввода, и в чате; сообщение введено в поле ввода, но ещё не отправлено; сообщение уже отображается в чате. Переходы между ними выглядят так: ввод символов переводит систему из первого состояния во второе, удаление всех введённых символов возвращает обратно в первое, нажатие кнопки «Отправить» переводит из второго состояния в третье, а нажатие «Редактировать» на уже отправленном сообщении возвращает из третьего состояния обратно во второе. Отдельного внимания заслуживает петля — редактирование текста, когда сообщение остаётся во втором состоянии, но его содержимое меняется. А ещё бывают переходы «напрямую» — например, удаление уже отправленного сообщения переводит систему сразу из третьего состояния в первое, минуя промежуточные шаги.
Как строится диаграмма: состояние — это не процесс
Здесь легко ошибиться. Процесс нагрева воды сам по себе — не состояние: это динамика, у которой нет фиксированной точки, она постоянно меняется. Чтобы работать с процессом как с конечным автоматом, его нужно разбить на дискретные точки: например, температуру можно зафиксировать в состояниях 10, 20, 30 градусов, а дистанцию движущейся машины на трассе — в отметках 100, 200, 300, 400 километров. Либо взять конкретное законченное действие, у которого есть чёткая точка завершения, — например, «машина остановилась».
Уровень детализации диаграммы всегда остаётся на усмотрение тестировщика. Можно ограничиться крупными состояниями, а можно разбить процесс мельче — например, выделить отдельное состояние «сообщение редактируется» между «введено в поле» и «отображается в чате». Чем подробнее диаграмма, тем выше покрытие тестами, но и тем больше времени уйдёт на её построение и прогон — здесь, как и в других техниках тест-дизайна, важен баланс между полнотой и реальными сроками проекта.
Уровень детализации диаграммы всегда остаётся на усмотрение тестировщика. Можно ограничиться крупными состояниями, а можно разбить процесс мельче — например, выделить отдельное состояние «сообщение редактируется» между «введено в поле» и «отображается в чате». Чем подробнее диаграмма, тем выше покрытие тестами, но и тем больше времени уйдёт на её построение и прогон — здесь, как и в других техниках тест-дизайна, важен баланс между полнотой и реальными сроками проекта.
Зачем нужна диаграмма состояний
Главная практическая польза техники — она делает видимыми переходы, которые легко упустить, если тестировать систему просто «по ощущениям», кликая по интерфейсу без структуры. Диаграмма заставляет явно ответить на вопрос: что должно произойти, если пользователь попытается выполнить действие из состояния, в котором оно не предусмотрено? Может ли заказ перескочить из статуса «оформлен» сразу в «доставлен», минуя сборку и передачу курьеру? Что произойдёт, если попытаться отредактировать сообщение, которое ещё не отправлено? Такие «невозможные» или пропущенные переходы — частый источник багов, потому что разработчики нередко продумывают основной happy path, но не все ветвления вокруг него.
Техника особенно уместна там, где у продукта явно прослеживаются состояния: статус заказа, пользовательская сессия и авторизация (не авторизован → вводит данные → авторизован → вышел из аккаунта), состояние сайта или приложения (открыто, закрыто, свёрнуто в фон, аварийно завершилось), проигрыватель видео (пауза, воспроизведение, буферизация, окончание). В любой системе, где можно выделить чёткие «слепки» и переходы между ними, диаграмма состояний даст готовый и структурированный набор тест-кейсов.
Диаграммы состояний, наравне с классами эквивалентности, граничными значениями и таблицей принятия решений, входят в стандартный набор из семи техник тест-дизайна, которые проверяют почти на любом техническом собеседовании тестировщика. В Quality Academy на курсе «Инженер по ручному тестированию» эти техники разбираются на живых примерах — от статусов заказа до чатов, — а не только в теории, чтобы на собеседовании кандидат не терялся, а мог сразу нарисовать диаграмму на бумаге или в редакторе.
-------
Техника особенно уместна там, где у продукта явно прослеживаются состояния: статус заказа, пользовательская сессия и авторизация (не авторизован → вводит данные → авторизован → вышел из аккаунта), состояние сайта или приложения (открыто, закрыто, свёрнуто в фон, аварийно завершилось), проигрыватель видео (пауза, воспроизведение, буферизация, окончание). В любой системе, где можно выделить чёткие «слепки» и переходы между ними, диаграмма состояний даст готовый и структурированный набор тест-кейсов.
Диаграммы состояний, наравне с классами эквивалентности, граничными значениями и таблицей принятия решений, входят в стандартный набор из семи техник тест-дизайна, которые проверяют почти на любом техническом собеседовании тестировщика. В Quality Academy на курсе «Инженер по ручному тестированию» эти техники разбираются на живых примерах — от статусов заказа до чатов, — а не только в теории, чтобы на собеседовании кандидат не терялся, а мог сразу нарисовать диаграмму на бумаге или в редакторе.
-------
Полезные ссылки школы
Сайт Quality Academy:
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
https://quality-academy.ru/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena