Как принять интернет-магазин перед запуском

Определите границу приёмки

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

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

Проверяйте один заказ в нескольких системах

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

Добавьте неудобные сценарии

Покупатель может закрыть окно оплаты, вернуться назад или дважды нажать кнопку. Остаток может закончиться между просмотром карточки и подтверждением. Сервис доставки иногда отвечает с задержкой. Проверьте, что человек получает понятное состояние, а оператор — возможность разобраться без прямого редактирования базы.

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

Разделите тестовые и реальные операции

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

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

Учебный пример: последний товар

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

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

Зафиксируйте решение о выпуске

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

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

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

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

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