В магазине 47 проверок, и все зелёные. А покупатель пишет в поддержку: оформил заказ с промокодом, отменил — и на карту вернулось на 340 ₽ меньше, чем он заплатил. Проверки честные: возврат проверяли без промокода (3400 ₽ заплатили, 3400 ₽ вернули), скидку — в корзине (3400 ₽ стало 3060 ₽). Баг живёт между ними: сумма со скидкой едет из корзины в оплату, оттуда в возврат, и на последнем перегоне скидку вычитают второй раз.
Цепочка действий, которую человек проходит целиком ради одной цели, называется пользовательским сценарием. От набора отдельных проверок он отличается одним: мир не сбрасывается между шагами — данные едут дальше, состояние меняется, и каждый следующий шаг работает с тем, что оставил предыдущий.
Отдельная проверка смотрит в один столбец: нажали — увидели. Сценарий ведёт все четыре строки состояния через всю цепочку, и на последнем стыке становится видно то, чего не видно нигде: деньги и бонусы отмена вернула, а товар на склад — нет.
Цепочка — это не сумма отдельных проверок
Отдельный кейс начинается с чистого листа: заказ создают запросом в базу, оплаченный статус проставляют руками. Так кейс не зависит от соседей — но переход между шагами никто не проходит: заказ в проверке возврата не приезжал из оплаты, он появился уже правильным.
Сценарий проходит переходы сам и видит два класса вещей. Данные едут через весь путь и меняются: сумма 3060 ₽ появляется в корзине, уходит в шлюз, возвращается в кабинет, печатается в письме и участвует в возврате — пять мест, и достаточно одного, где её пересчитают ещё раз. Состояние меняется и не откатывается: после оплаты остаток на складе меньше, бонусы начислены, промокод использован, — и «отмена вернула деньги, но не вернула товар на склад» видно только на заказе, который действительно прошёл оплату.
Откуда берутся шаги: путь живого покупателя, а не карта экранов
Первый сценарий новичок обычно пишет по меню сверху вниз: главная, каталог, корзина, оформление, кабинет. Получается обход интерфейса без единой цели — он и найдёт ровно незагрузившийся экран, потому что человек, идущий по меню, ничего не покупает.
Шаги берут из того, что люди делают на самом деле: из обращений в поддержку, где десяток писем за месяц складывается в три-четыре повторяющихся пути; из цифр о поведении, где видно, каким путём идут девять из десяти и на каком шаге отваливаются; из рассказа аналитика, который за пятнадцать минут выдаёт нормальную покупку готовой цепочкой. А если непонятно, что должно произойти на шаге, — это дыра в требованиях.
Готовые шаги проверяют правилом: шаг называют словами цели, а не словами интерфейса. «Выбрать доставку на послезавтра» переживёт редизайн, «нажать третью вкладку» устареет при первой перестановке кнопок; подписи и данные живут внутри тест-кейса. И кончается сценарий на цели человека — полученном товаре и письме с номером.
Сквозной сценарий: от гостя до возврата денег
Ожидаемый результат пишут после каждого шага: «в конце всё сломалось» ничего не стоит, если неизвестно, где разошлось.
Предусловия: «Кофемолка» за 3400 ₽, на складе 7 штук; промокод SPRING10 даёт 10% и не действует на доставку; доставка 300 ₽; почта anna@example.com доступна для чтения; тестовая карта 4111 1111 1111 1111.
- Гость кладёт кофемолку в корзину — одна позиция на 3400 ₽, на складе всё ещё 7 штук (корзина не резервирует), вход не требуется.
- Нажимает «Оформить» и регистрируется — корзина не опустела: первый настоящий стык, корзина гостя переезжает к новой учётной записи; письмо о регистрации пришло, в «Мои заказы» пусто.
- Вводит
SPRING10— «Скидка 340 ₽», к оплате 3060 ₽; скидка от товара, а не от суммы с доставкой; промокод ещё не отмечен использованным. - Выбирает доставку и переходит к оплате — доставка 300 ₽ отдельной строкой, итог 3360 ₽, скидка не пересчиталась; на странице оплаты та же сумма, что в корзине.
- Оплачивает картой — «Заказ оплачен» с номером; в шлюзе списано ровно 3360 ₽; в «Мои заказы» статус «Оплачен» и 3360 ₽; на складе 6 штук; начислено 306 бонусов (10% от суммы товара);
SPRING10отмечен использованным. - Письмо о заказе — пришло на
anna@example.com, тот адрес, что вводили, а не из настроек; тот же номер, те же 3360 ₽ и 340 ₽; ссылка открывает заказ под этим покупателем. - Отменяет заказ и ждёт возврата — статус «Отменён»; на карту вернулось 3360 ₽, а не 3020 ₽ со второй раз вычтенной скидкой и не 3060 ₽ без доставки; бонусы сняты, баланс 0; на складе снова 7 штук; письмо об отмене пришло.
Баг из начала статьи ловит седьмой шаг: продукт возвращает 3020 ₽, потому что скидку вычитают ещё раз из уценённой суммы. Там же видна вторая ошибка, нарисованная выше: остаток на складе не вернулся к семи.
Стыки: что проверять там, где систем больше одной
Большая часть шагов заканчивается не на экране: письмо уходит через почтовый сервис, деньги через шлюз, остаток живёт в складской системе. А экран говорит «Заказ оплачен» и когда всё хорошо, и когда письмо не ушло. Отсюда правило: у стыка два конца, и смотреть надо на оба.
Письмо — пришло ли на адрес, который вводил покупатель, совпадают ли числа внутри, открывается ли ссылка под тем пользователем; частая ошибка — отметить «письмо пришло» и не открыть его, а в шаблоне цена без скидки. Остаток — после оплаты меньше ровно на один, после отмены возвращается, при повторном «Подтвердить» не уменьшается дважды (запросом в базу или в админке). Кабинет — заказ виден своему покупателю и не виден чужому. Деньги — вернулась ровно та сумма, что списывали: «Возврат выполнен» — слова кабинета о себе, факт живёт в шлюзе, а что ушло, видно во вкладке «Сеть».
Срабатывают стыки не мгновенно: письмо идёт секунды, остаток пересчитывает фоновая задача, возврат в банке занимает дни, — поэтому в сценарии пишут, сколько ждать и по какому признаку считать, что дождались.
Прерывания и персонажи: живой человек не идёт по прямой
Он возвращается назад, открывает вторую вкладку, отвлекается на час, жмёт «Оплатить» второй раз, потому что первый раз ничего не произошло. Сценарий-прямая этого не проверяет, а поддержка разбирает именно такие истории: в них теряются деньги. Записывают прерывания ветками от основного пути. «Назад» с оплаты — жива ли скидка, не создался ли второй заказ, не зарезервирован ли товар дважды. Повторная оплата — ждём одно списание и один заказ, и смотреть надо в шлюз: экран часто показывает один заказ при двух списаниях. Две вкладки — в одной корзина собрана десять минут назад, в другой только что куплен последний экземпляр. Пауза — через час истекли резерв, сессия и промокод, изменилась цена: ждём сообщения и сохранённой корзины. Проверяют прерывания вокруг точек невозврата — шагов, после которых деньги списаны, письмо отправлено, заказ ушёл в доставку.
Подсказывают эти ветки персонажи — обобщённые образы людей по двум осям, квалификация и склонность к экспериментам:
| Низкая квалификация | Высокая квалификация | |
|---|---|---|
| Не склонен к экспериментам | «Осторожный» | «Консервативный» |
| Склонен к экспериментам | «Отчаянный» | «Изощрённый» |
Наш сценарий у «Отчаянного» пройдёт с двумя вкладками и двойным «Оплатить», у «Изощрённого» — горячими клавишами и обходными путями: разные проходы по одному пути дают разные находки за пять минут вместо часа бессистемных кликов (так же набирают идеи для исследовательской сессии). Сломал «Отчаянный» оплату двойным нажатием второй раз подряд — это уже постоянный кейс в наборе.
Сколько сценариев держать, в каких наборах и что остаётся для дымовой проверки
Соблазн описать побольше путей за неделю даёт сорок сценариев по двадцать минут прохода, и не гоняет их никто. Держат столько, сколько команда реально проходит перед выпуском — обычно пять-семь, — а отбирают по цене ошибки: деньги, частота (самый хоженый путь ломается у всех сразу), необратимость (отправленное письмо не вернуть, заказ в доставке не остановить). И сценарий не перебирает варианты: «проверим заодно карту с истёкшим сроком и отказ банка» превращает путь в дерево, которое нельзя ни пройти, ни починить, — перебор значений живёт в точечных кейсах (техники тест-дизайна, таблицы решений).
Хранят кейсы наборами — сьютами. В свободном кейсы независимы и идут в любом порядке, упал один — остальные выполняются; на нём держат регресс. В последовательном порядок важен, результат кейса становится стартовым состоянием следующего: «зарегистрироваться» → «собрать корзину» → «оплатить» → «отменить и получить возврат». Шагов меньше и переходы проходятся, плата — хрупкость: упал второй кейс, и в отчёте пять «заблокировано» вместо пяти честных результатов. Поэтому договариваются, откуда прогон можно перезапустить: обычно это шаг с подготовленными данными вроде «начать с оплаты готового заказа».
Полный проход нашего сценария — двадцать-сорок минут, перед каждой сборкой его не запускают. Из него вырезают короткую, дымовую версию на три-четыре минуты, и режут в ней подробности, а не шаги: уходят содержимое письма, сверки с базой, промокод и отмена, остаётся скелет — в корзину, оплатить тестовой картой, увидеть заказ в кабинете. Обязаны остаться шаг с деньгами и шаг, после которого путь разветвляется: уберёте оплату — короткая проверка начнёт зеленеть на продукте, где нельзя купить, а ей верят. Дальше она первой уезжает в автоматизацию.
Коротко
- Сценарий — цепочка действий ради одной цели без сброса мира между шагами: данные едут дальше, состояние остаётся изменённым, и баги на стыках видит только он.
- Шаги берут из пути живого человека, а не из карты экранов, и называют словами цели; ожидаемый результат пишут после каждого шага. У стыка два конца: экран сказал «отправлено» — почта, шлюз, склад или кабинет должны сказать «получено», и срабатывает это не мгновенно.
- Сценариев держат пять-семь: по деньгам, по частоте пути, по необратимости ошибки; перебор вариантов внутри шага в сценарий не кладут.
- Прерывания — «назад», повторное нажатие, две вкладки, пауза — записывают ветками и проверяют вокруг точек невозврата; подсказывают их персонажи.
- Сценарии живут в последовательных наборах: шагов меньше, но упавший кейс блокирует хвост; для ежедневной проверки из сценария вырезают короткую версию.
Что почитать дальше
- Как писать тест-кейс: шаги и ожидаемый результат — из чего собран каждый шаг сценария и откуда берётся ожидаемый результат.
- Виды тестирования: дымовой набор и регресс — куда попадает короткая версия сценария.
- Тест-план и тест-сьюты: как организовать проверки — где хранят сценарные наборы и как планируют прогон.
- SQL для тестировщика — как посмотреть на второй конец стыка: остаток, статус заказа, списание бонусов.