Как собрать смок тест для интернет-магазина от регистрации до оплаты и проверки письма
Что проверяют
Умеете ли вы отделить смок от полной регрессии и выбрать критический путь, без которого магазин не продаёт. Следом обычно спрашивают, как проверить оплату и письмо на тестовом стенде, не тратя реальных денег и не заводя сотню почтовых ящиков.
Как отвечать
Смок это короткий прогон главного сценария после каждой сборки: минут десять руками или пара минут в автотестах. Он отвечает на один вопрос: можно ли дальше тестировать эту сборку. Валидация всех полей и негативные сценарии сюда не входят, их место в регрессии.
Каркас сценария:
- регистрация: новый пользователь с уникальным адресом, например
qa+<timestamp>@доменили ящик тестового почтового сервиса; - вход: под только что созданной учёткой, сессия сохраняется после перезагрузки;
- каталог и корзина: переход в категорию или поиск, добавление товара, верная сумма в корзине;
- оформление: адрес, способ доставки, итог с учётом доставки;
- оплата: sandbox-режим платёжного шлюза и тестовая карта от провайдера. Проверяете и экран успеха, и статус заказа в админке или через API: редирект ещё не значит, что вебхук дошёл;
- письмо: на стенде почту перехватывает Mailpit, MailHog или аналог с API для чтения. Сверяете, что письмо пришло, номер заказа и сумма верные, ссылки ведут на нужный стенд.
Сценарии храните в TestRail, Qase или Allure TestOps. Для автоматизации удобен Playwright: его request умеет ходить в API почтового сервиса и админки. Тестовые данные готовьте через API, а не через интерфейс, так прогон быстрее и стабильнее.
Где спотыкаются
Раздувают смок до регрессии: проверки каждого поля, негативы, несколько браузеров. Прогон на час перестаёт быть смоком, и его начинают пропускать.
Проверяют оплату только по экрану «Спасибо за заказ». Если вебхук от шлюза не обработался, заказ висит неоплаченным, а тест зелёный.
Используют один и тот же email на каждый прогон. Повторная регистрация падает на проверке уникальности, а письма разных прогонов смешиваются в одном ящике.