Письма о заказах — самые рискованные транзакционные сообщения, которые отправляет маркетплейс. Несработавшее письмо для сброса пароля просто раздражает; чек с неверной суммой — инцидент для финансов. При этом тестировать их неудобно: каждому сценарию нужны свежий аккаунт, покупка в определённом состоянии и ящик для приёма результата. Это ровно та форма задачи, которую решают временные ящики. Вот workflow, которым QA-команды реально закрывают подтверждения заказов, чеки, уведомления о доставке, отмены и возвраты — без загрязнения реальных аккаунтов и без ожидания реальной логистики.
Почему письма о заказах особенно трудно тестировать
Четыре свойства отличают почту маркетплейса от обычного тестирования уведомлений:
- Зависимость от состояния. Уведомление о доставке существует только после заказа, который оплачен, упакован и отправлен. Воспроизвести состояние — сложная часть, а не само письмо.
- Разброс по времени. Подтверждения приходят за секунды; обновления о доставке — часами или днями позже, иногда не по порядку. Тесты должны выдерживать этот разрыв.
- Плотность merge-полей. Имена, адреса, валюты, позиции, налоговые строки, номера отслеживания — шаблоны заказов интерполируют больше значений, чем почти любой другой тип писем, и каждое из них — поверхность отказа.
- Ставки доставляемости. Подтверждение, потерянное в спаме, порождает тикет «где мой заказ?», хотя сам заказ в порядке.
Один ящик на сценарий
Ключевая дисциплина — изоляция. Дайте каждому сценарию свой одноразовый адрес: один для гостевого оформления, один для зарегистрированного покупателя, один для мультитоварных заказов, один для отмены, один для возврата. Когда подтверждение возврата не приходит, вы хотите сразу знать, сломался ли конвейер или просто письмо другого теста прилегло в тот же ящик.
Это зеркалит более широкий паттерн из статьи временная почта для QA-тест-аккаунтов: засеять аккаунты выделенными адресами, проверить, разобрать. Команды, строящие входящую обработку, превращают те же ящики в конвейеры событий — это разобрано в статье временная почта для тестирования почты с вебхуками.
Пять писем, которые каждый маркетплейс обязан делать правильно
Идите по списку по порядку, потому что каждый шаг зависит от предыдущего:
1. Подтверждение заказа. Приходит через мгновения после оформления. Проверяйте позиции, количества, цены за единицу, налог, стоимость доставки и итог против фикстуры корзины. Символы валют и десятичные разделители ломаются здесь первыми в тестах интернационализации. 2. Чек об оплате. Документ для финансов. Итоги должны совпадать с подтверждением точно; расхождение между подтверждением и чеком — дефект, который финотдел эскалирует быстрее всего. 3. Уведомление о доставке. Перевозчик, номер отслеживания и deep link, который действительно ведёт на страницу отслеживания перевозчика. Этот deep link — самый часто ломающийся элемент после любой миграции фронтенда. 4. Подтверждение доставки или исполнения. Для физических товаров — уведомление о доставке; для цифровых маркетплейсов — лицензия или ссылка доступа. Цифровой доступ заслуживает той же строгости, что и одноразовые ссылки на скачивание. 5. Письма об отмене и возврате. Подтверждение отмены должно сообщать, что отменили, когда оформлен возврат и сколько дней может занять банк. Клиенты читают их в самый тревожный момент; ясность здесь предотвращает лишние тикеты.
Проверяйте контент, а не только доставку — и подключите это к конвейеру
«Письмо получено» — слабейшее из возможных утверждений. Полезный набор тестов проверяет:
- Тема и прехедер содержат номер заказа или человеческую сводку, но никогда — сырые переменные шаблона.
- Каждое merge-поле разрешается. Утёкший в продакшен `${user.firstName}` — канонический позор; ловите это сравнением отрисованных тел с фикстурами.
- Коды извлекаются. Если подтверждения несут коды верификации или доступа, парсьте их программно — OTP-парсер вытаскивает коды из тел писем без регэкс-археологии.
- Ссылки резолвятся. Запрашивайте каждую ссылку в письме и проверяйте, что она ведёт на нужную страницу в нужном состоянии.
- Размещение, а не только факт прибытия. Подтверждение, лежащее в спаме, функционально равно отсутствующему письму.
Если ваш продукт обрабатывает письма о заказах — трекеры расходов, агрегаторы, автоматизация поддержки, — одноразовый ящик вдвойне полезен как точка приёма: прогоните пять сценариев, затем проверьте, что извлечённые структурированные данные совпадают с фикстурами. Тестировщик вебхуков проверяет событийную сторону конвейера. А поскольку письма о заказах так часто провоцируют ответы, прогоните смежный поток тикетов поддержки теми же ящиками.
Частые вопросы
Сколько тестовых ящиков нужно набору для писем о заказах? Планируйте по одному на сценарий, а не на прогон: гостевое оформление, оформление зарегистрированным, мультитоварный заказ, отмена, возврат и обновление доставки — типичные шесть. Переиспользование одного ящика между сценариями делает отказы неоднозначными; свежий ящик на прогон сохраняет чистоту истории, не добавляя этой неоднозначности.
Как тестировать письма о доставке, которые приходят через несколько дней? Вызывайте изменение состояния напрямую — пометьте фикстурный заказ как отправленный из админки или базы — или используйте песочницу маркетплейса, позволяющую двигать состояние заказа по требованию. Тестируйте шаблон вместе с его триггером состояния; никогда не ждите реальной логистики.
Должны ли отмена и возврат быть отдельными тестами? Да. Отмена — намерение пользователя; возврат — финансовое событие. Они могут сработать с разницей в минуты или в день, с разными шаблонами и разными merge-полями. Тестирование их как одного сценария скрывает, какой шаг упал, когда жалуется клиент.
Можно ли гонять эти тесты против реального маркетплейса? Избегайте. Продакшен-маркетплейсы берут реальные платёжные комиссии, непредсказуемо фильтруют одноразовые домены и считают повторяющиеся тестовые покупки злоупотреблением. Держите набор в staging или официальной песочнице платформы, а продакшен оставьте финальной точечной проверке доставляемости.
Итог
Письма о заказах маркетплейса — это машина состояний, и временные ящики дают каждому состоянию чистую, наблюдаемую точку. Настройте по ящику на сценарий, пройдите подтверждение, чек, доставку, исполнение и возврат и проверяйте контент, ссылки и размещение — а не только факт прибытия. Держите набор в staging и [создайте временный ящик](/), когда оформлению заказа нужен свидетель.