Содержание
Тестовый заказ DBS на Маркете: как провести репетицию без отправки товара
До первого рабочего заказа полезно пройти обработку в учебном режиме и выяснить, кто видит заказ, кто меняет его состояние и как команда отличает тест от реальной работы. Для DBS у Яндекс Маркета есть штатный сценарий виртуальных заказов.
Цель репетиции: получить проверяемую последовательность действий по одному тестовому идентификатору. Она не должна заканчиваться вызовом курьера или передачей товара на складскую отгрузку.
Что позволяет проверить тест
В справке Маркета указано: тестовые заказы доступны после завершения подключения, они виртуальные и не тарифицируются. Используется тестовая карта без списания денег, а отправлять товар не требуется.
Есть важное ограничение: условия доставки такого заказа не связаны с действующими настройками магазина. Успешное прохождение теста не подтверждает корректность реальных зон, сроков и тарифов доставки.
Поэтому заранее разделите две задачи:
| Проверяется в репетиции | Проверяется отдельно |
|---|---|
| Сотрудник находит нужный тестовый заказ | Фактические условия доставки магазина |
| Команда понимает последовательность действий | Готовность курьера и склада к реальному заказу |
| Зафиксирован результат каждого шага | Полнота производственной интеграции |
| Тест не попал в физическую отгрузку | Правильность исполнения реального заказа |
Подготовьте сценарий до создания заказа
Выберите подключённый магазин и товары, которые команда узнает без путаницы. Запишите цель проверки: например, найти заказ в кабинете и пройти предусмотренную обработку. Не добавляйте сразу все возможные ошибки в один тест: тогда будет сложно понять, на каком шаге возникло расхождение.
Назначьте сотрудника, который ведёт протокол. Достаточно таблицы: идентификатор теста, время шага, действие, наблюдаемый результат и отклонение. Предупредите участников складского процесса, что товар по этому идентификатору не нужно отгружать.
Если у вас подключена сторонняя система, сначала выясните по её документации, как она распознаёт тестовый тип. Сам факт появления заказа в кабинете не доказывает, что все внешние звенья обработали его правильно.
Пройдите штатный путь в кабинете
Официальная инструкция ведёт через настройки аккаунта, раздел API и модулей и создание тестового заказа. Выберите магазин и товары, проверьте состав и завершите тестовое оформление.
В списке заказов найдите запись с типом «Тестовый». Сверяйте не только товар и время, но и номер: похожий реальный заказ может находиться рядом. Выполните предусмотренный шаг «Готов к отгрузке», затем проверьте запись на вкладке всех заказов. Физической отправки не делайте.
Если сценарий предполагает отмену, откройте именно тестовый заказ и выполните штатную отмену с подтверждением. Зафиксируйте её результат отдельно от успешной обработки.
Разберите расхождения по шагам
Если запись не найдена, сначала проверьте магазин, идентификатор и фильтры. Не создавайте серию новых тестов, чтобы случайно увидеть один из них.
Если кабинет и внешняя система показывают разные состояния, сохраните время и идентификатор в обеих системах. Разделите три события: заказ создан, получен внешней системой, обработан сотрудником. Объединённое «не работает» не позволяет локализовать проблему.
Если тест попал в реальную очередь сборки, остановите именно его физическое исполнение и выясните правило отбора заказов. Успешный экран в кабинете не компенсирует такую ошибку процесса.
Зафиксируйте границу результата
Репетиция завершена, когда по одному тестовому номеру понятны все выполненные шаги, выявленные отклонения и итоговое состояние. В протоколе отдельно отметьте, что доставка и реальный складской маршрут этой проверкой не подтверждались.
Так команда получает конкретный список исправлений до рабочего запуска, а не общее впечатление, что «заказ прошёл».
Комментарии 0