Почему корзине нужны автотесты, даже если заказы оформляются

В магазин поступают заказы, менеджер вчера сам купил товар, жалоб на корзину нет. При таких вводных предложение потратить время на автотесты легко отложить. Но один успешный заказ подтверждает только одну последовательность действий: с этим товаром, этой доставкой и этим способом оплаты.

Покупатель может уменьшить количество уже на оформлении, вернуться назад, применить промокод, сменить город или повторно нажать кнопку после долгого ожидания. В каждом случае меняются данные заказа. Ошибка в этих переходах может прервать покупку, изменить сумму или создать лишнюю операцию. Владелец магазина должен иметь возможность проверить, что бизнес принимает и исполняет именно согласованный с покупателем заказ.

Ошибка, которую не видно при обычной покупке

На Primula мы разбирали два связанных сбоя. При возврате между корзиной и оформлением старый снимок данных мог заменить свежий состав заказа. Покупатель уменьшал количество или удалял вещь, а после перехода видел её снова. Открыть магазин заново и купить один товар было недостаточно, чтобы воспроизвести эту последовательность.

Второй сбой зависел от суммы. В проверенной 25 октября 2026 года конфигурации магазина оплата частями была доступна от 5 000 ₽. Два платка стоили 5 800 ₽, один стоил 2 900 ₽. После уменьшения количества ранее выбранный способ оплаты требовалось сбросить. Сделать его серым на экране недостаточно: внутри формы могло остаться прежнее значение.

На экране после исправления итог составляет 2 900 ₽, недоступные способы отключены, выбрана банковская карта. Чтобы проверить такое поведение, нужно сначала выбрать оплату при допустимой сумме, затем уменьшить заказ и проверить новый выбор. Проверка страницы, сразу открытой с маленькой корзиной, пропустит сам переход.

После доработки эти действия повторили на рабочем сайте. Для всего выпуска прошли 103 автоматических теста интерфейсной логики; дополнительно выполнили 13 браузерных проверок до выпуска и 17 после него. Эти числа относятся ко всему выпуску, включая другие исправления. Они не означают, что мы автоматически проверили все возможные состояния корзины или измерили прирост продаж. Подробный разбор ошибки Primula опубликован отдельно.

Что значит покрыть все элементы корзины

Для каждого элемента с действием нужно определить ожидаемый результат и автоматическую проверку. У кнопки «минус» это изменение количества, пересчёт суммы и сохранение нового состава после перехода. У выбора города это новый тариф и допустимые способы доставки. У кнопки оплаты это согласованный заказ и защита от повторной обработки.

Проверки одного наличия кнопок на странице не подтвердят правильность расчёта и сохранения заказа. Приёмочный список удобнее составлять по действиям покупателя и деньгам, которые за ними стоят.

Список зависит от магазина. Если нет промокодов или резервов, соответствующие проверки не нужны. Зато продажа мерного товара, наборов или товаров с персонализацией потребует собственных правил. Полное покрытие списка действий не даёт гарантии отсутствия любых ошибок: остаются сочетания условий, внешние сервисы и ограничения среды. Приоритет получают ошибки с наибольшими последствиями для заказа.

Почему один большой браузерный тест не закроет задачу

Расчёт скидки удобнее проверять отдельно на заранее согласованных примерах. В тесте фиксируют состав, цены, порядок скидок и ожидаемый итог до копейки. Если ожидаемую сумму получать той же функцией, которую проверяем, неверная формула может подтвердить сама себя.

На уровне сервера проверяют сохранённый заказ: состав, количество, итог, доставку и платёжное состояние. Здесь нужны запросы с устаревшей ценой, недопустимым способом оплаты и повтором одной операции. Для штучного товара проверяют ноль, отрицательное и дробное количество, превышение доступного остатка. Доверять только запрету в интерфейсе нельзя: запрос может прийти из старой вкладки или в обход формы.

Итог на экране сверяют с суммой сохранённого заказа и суммой, отправленной платёжному сервису. В примеры включают округление скидки и платную доставку. Совпадение одной общей цифры ещё не проверяет состав: две ошибки в разных строках могут компенсировать друг друга.

Браузерные тесты проходят покупательские последовательности: меняют количество, возвращаются назад, выбирают другой город, ждут ошибку доставки и продолжают оформление. Они связывают расчёты и сервер с тем, что видит человек. Отдельно проверяют мобильное управление и клавиатуру: закрытая виджетом кнопка или поле, к которому нельзя перейти, тоже мешают закончить заказ.

Для повторов платежа важны правила конкретного провайдера. Например, ЮKassa использует ключ идемпотентности: повтор с теми же данными и ключом возвращает исходный результат. Другой ключ означает новую операцию. Для API ЮKassa срок такой защиты составляет 24 часа. Поэтому в тесте нужно проверить сохранение ключа при повторной попытке и собственную защиту магазина от дублей заказа. Документация ЮKassa о повторных запросах.

Как проверять переходы и отказы при оформлении

У каждого ограничения есть граница. Если оплата доступна от 5 000 ₽, полезны значения ниже порога, ровно на нём и выше. Затем следует изменить уже оформляемый заказ так, чтобы он пересёк эту границу в обе стороны. Если правило считает сумму после скидки, тест должен пересечь порог именно промокодом. Иначе проверена другая бизнес-логика.

Для доставки стоит отдельно воспроизвести задержку расчёта, ошибку сервиса и смену города во время ожидания. Поздний ответ для первого города не должен записать свой тариф в заказ для второго. При недоступном расчёте покупатель должен увидеть предусмотренный магазином вариант продолжения, а не незаметную бесплатную доставку.

На сервере проверяют и соревнование за последний товар. Две независимые сессии пытаются оформить одну единицу. Результат сверяют с принятой политикой: когда появляется резерв, сколько он живёт, допускается ли предзаказ и что происходит после отказа оплаты. Сам по себе нулевой остаток на странице не подтверждает корректность параллельного оформления.

В обработке оплаты нужны повтор события, задержка подтверждения и несоответствие суммы. ЮKassa предусматривает повторную доставку уведомления при отсутствии подходящего подтверждения и рекомендует проверять подлинность сообщения. Автотест магазина должен показать, что повтор не запускает исполнение ещё раз, а уведомление по другому платежу не меняет заказ. Правила входящих уведомлений ЮKassa.

Сколько такая ошибка может стоить бизнесу

Расчёт лучше начинать с этапа, который затронут сбоем. Если ошибка появляется при оформлении, число посетителей всего сайта для оценки потерь слишком грубое. Нужны сопоставимые данные о тех, кто начал оформление, доле оплаченных заказов и составе трафика.

Условный пример: оформление начинают 100 покупателей в день. Обычно оплачивают 40, а при воспроизведённом сбое оплачивают 35 при сопоставимых остальных условиях. Разница составляет пять заказов, или пять процентных пунктов конверсии оформления. При среднем чеке 6 000 ₽ это 30 000 ₽ возможной недополученной выручки в день.

Если вклад заказа после себестоимости и переменных затрат равен 30% выручки, вклад пяти заказов составит 9 000 ₽. Это оценка недополученного вклада в покрытие постоянных расходов и прибыль, а не чистая прибыль и не сумма ущерба, доказанная одним графиком. Числа в примере вымышлены для расчёта; к финансовым результатам Primula они не относятся.

Повторное списание требует отдельной сверки платежей и возвратов. Сам возвращённый покупателю платёж нельзя целиком записывать в операционный убыток: нужно учесть фактические комиссии и расходы на исправление. Расход на привлечение этих покупателей тоже не стоит автоматически прибавлять к недополученному вкладу, если он уже учтён в расчёте.

Падение конверсии после выпуска даёт повод для расследования. Причину проверяют по воспроизведению ошибки, времени выпуска, затронутым способам оплаты, журналам и изменению трафика. Без этого вся разница между днями может быть ошибочно отнесена к корзине.

Как тестировать оплату без случайных заказов клиентов

Для автоматического прогона нужна отдельная среда с управляемыми товарами и остатками. Из неё не должны уходить настоящие задания на комплектацию, фискальные операции и сообщения покупателям. Подмену ответа службы доставки помечают в отчёте: она проверяет реакцию магазина, но не подтверждает доступность самой службы.

У платёжных сервисов есть ограничения тестового режима. В документации ЮKassa указаны тестовые платежи картой и кошельком ЮMoney; другие способы проверяют в настоящем магазине. Поэтому результат «тестовая карта прошла» нельзя переносить на все подключённые оплаты. Возможности и ограничения тестового режима ЮKassa.

Если для конкретного способа нужна настоящая операция, её согласуют отдельно: сумма, товар, получатель, действия склада и последующий возврат. Для обычной проверки после выпуска достаточно заранее определённых действий до такой границы. В приёмке интерфейсных исправлений Primula мы останавливались до создания реального заказа и оплаты, затем проверяли отсутствие побочных записей. Это не считалось проверкой полного банковского платежа.

С чего начать в работающем магазине

Сначала составьте вместе с разработчиком карту корзины. В неё входят все элементы управления, правила сумм, варианты доставки и оплаты, момент резерва и признаки успешного заказа. Для каждого пункта запишите действие, ожидаемый результат и место проверки: экран, сохранённый заказ или ответ платёжного сервиса.

Первый обязательный набор перед выпуском должен закрывать расчёт итога, изменение и удаление товара с возвратом назад, смену доставки, доступность оплаты, отказ и повтор оформления. Если магазин принимает промокоды, сертификаты или продаёт последнюю единицу одновременно онлайн и в рознице, эти правила включают сразу. После найденного дефекта добавляют проверку именно той последовательности, которая его обнаружила.

Разработчик должен показать, что новый тест замечает ошибку: на прежнем поведении он падает по нужной причине, на исправленном проходит. Проверка, которая остаётся зелёной при удалении исправления, не подтверждает устранение дефекта.

Быстрые проверки расчётов запускают при каждом изменении. Обязательные покупательские сценарии проходят перед выпуском. Если результат теста меняется без правок, сначала нужно найти причину нестабильности. Вместе с тестами остаются ручной просмотр и контроль после выпуска, поскольку внешние условия могут измениться без правок сайта.

Что владельцу получить от команды после проверки

В отчёте должны быть версия сайта, дата, среда, проверенные сценарии и результат каждого. Для сбоя нужны шаги, ожидаемое и фактическое поведение, обезличенный экран или запись. Для сценариев оплаты отдельно указывают, где работал тестовый провайдер, где ответ был подменён и выполнялась ли настоящая операция.

После публикации сверяют реальные статусы заказов: сколько оформлений завершились оплатой, где остановились, какие ошибки пришли от доставки и банка. Посещение страницы «Спасибо» само по себе не подтверждает оплату. Резкое изменение требует проверки; уведомление должно приходить человеку, который может остановить неудачный выпуск или восстановить предыдущую версию.

Если покупатель сталкивается с исчезнувшим способом оплаты или неправильной суммой, начните с записи его действий. По обезличенным экранам корзины, правилам доставки и оплаты мы можем определить, какие сценарии воспроизводить и какие проверки сделать обязательными перед следующей доработкой магазина.