Начните с заказа, который сотрудники смогут обработать
Выберите товар с настоящими характеристиками и согласованной ценой. Покупатель должен найти нужный вариант, увидеть наличие, положить его в корзину и получить понятные условия доставки. Если стоимость перевозки уточняет менеджер, интерфейс должен объяснять это до оплаты.
Пройдите покупку на телефоне, которым реально пользуется команда, и на компьютере. Проверьте ввод адреса, изменение количества и возвращение к карточке. Ошибка в поле должна оставлять уже введённые данные, а итоговая сумма — соответствовать выбранному составу заказа. Если действует скидка, отдельно сравните сумму на сайте и в платёжной форме.
После оформления проверку продолжает сотрудник магазина. Ему нужны состав, вариант товара, контакт покупателя, адрес, способ доставки и понятный статус оплаты. Пусть он найдёт заказ без помощи разработчика и выполнит согласованное действие: подтвердит, передаст в сборку или распечатает нужный документ. Так проверяется пригодность административной части к работе.
Подтверждение платежа должно доходить без покупателя
Сначала согласуйте с исполнителем и провайдером безопасное тестовое окружение. Для окончательного запуска отдельно потребуется проверка подключённых рабочих реквизитов; успешный тест в песочнице их не подтверждает. Использование настоящих денег и последующий возврат должны быть заранее согласованы владельцем магазина.
Один из важных сценариев — закрыть страницу после оплаты и проверить заказ со стороны магазина. Например, ЮKassa описывает серверные уведомления, через которые приложение получает изменения состояния платежа. Возвращение браузера на страницу благодарности не должно быть единственным способом узнать об оплате.
Затем проверьте отказ и прерванную попытку. Покупателю нужно понятное дальнейшее действие, сотруднику — состояние без ложного подтверждения. Повторное нажатие и повторная обработка уведомления не должны создавать лишний заказ или повторную финансовую операцию. Конкретную защиту исполнитель реализует по документации выбранного платёжного сервиса; критерий приёмки описывает наблюдаемый результат.
Проверьте случаи, которые меняют работу склада
Для приёмки полезен товар с ограниченным остатком. Зафиксируйте правило: когда возникает резерв, сколько он действует и как освобождается после отмены. Затем выполните сценарий и сравните доступное количество на сайте и в учётной системе. Если обмен идёт по расписанию, оценивать его следует в согласованных временных пределах.
Отдельно проверьте адрес, для которого доставка недоступна. Магазин должен показать предусмотренное ограничение, а не принять оплату с неподтверждёнными условиями отправки. Если сервис доставки временно не отвечает, поведение должно соответствовать договорённости: повторный расчёт, заявка менеджеру или временная остановка оформления.
Возврат тоже входит в торговый процесс, если он предусмотрен составом проекта. Проверяют состояние заказа, результат операции у провайдера и действия сотрудников. Изменение подписи на кнопке не подтверждает возврат денег. Частичный возврат нужен в проверке тогда, когда он включён в согласованную реализацию.
Сверьте заказ с аналитикой
Открывающийся счётчик ещё не показывает, что аналитика получает состав и стоимость покупки. В инструкции Яндекс Метрики по проверке электронной коммерции описаны проверка отправляемых событий и наблюдение данных. Исполнитель должен показать, какое действие вызывает событие и какие сведения передаются.
Для контрольного заказа сравните идентификатор, товары, количество и сумму. Уточните смысл события покупки: оформление заказа и подтверждённая оплата могут происходить в разное время. Если считать их одним показателем без пояснения, рекламный отчёт и данные о деньгах начнут расходиться.
В итоговом отчёте важно различать заказ, платёж, отмену и возврат. Аналитика помогает исследовать путь клиента; финансовый статус сверяют с системой заказов и провайдером. Такой порядок позволит после запуска обсуждать качество трафика на основе определённых показателей.
Зафиксируйте основания для запуска
Удобный результат проверки — таблица с условием, ожидаемым поведением, фактическим результатом и ссылкой на доказательство. Для оплаты это запись операции, для склада — состояние товара, для передачи заказа — запись в принимающей системе. Рабочие документы с персональными данными остаются в закрытом доступе.
Несоответствия разделите по последствиям. Потерянная оплата или неверная сумма мешают продажам; небольшая визуальная погрешность может получить отдельный срок исправления. Решение об исключении принимает заказчик, понимая последствия. Перед открытием магазина также нужны доступы владельца, назначенный ответственный за обращения и согласованный порядок восстановления после сбоя.
Если вы готовитесь заказать разработку интернет-магазина, обсудите приёмку ещё на этапе сметы. В pommeDeTerre можно начать с вашего пути заказа и определить, какие результаты должны быть показаны перед запуском. Тогда завершение разработки будет связано с проверенной работой магазина, а бюджет на рекламу получит подготовленную площадку.