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

Зачем тестировщику отдельные почтовые адреса

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

Почему личная и корпоративная почта для этого не годятся

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

Разовая активация или аренда — что брать под сценарий

Выбор зависит от того, сколько писем ожидается в рамках сценария. Если тест проверяет ровно один шаг — регистрация и подтверждение одним письмом — подходит разовая активация: временный ящик под конкретный сайт, который живёт 20 минут и закрывается по таймауту с автоматическим возвратом денег, если письмо не пришло. Если сценарий сложнее и требует повторных писем на один и тот же адрес — например, регистрация, затем восстановление пароля, затем повторный вход с подтверждением по почте — разовой активации не хватит, потому что адрес закрывается сразу после первого письма. Здесь нужна аренда ящика на срок от 12 часов до 60 суток с поддержкой продления: есть пресеты на 12, 24 и 48 часов, неделю, месяц и 60 суток, что покрывает и короткий регрессионный прогон, и многодневное тестирование релиза.

Изоляция тестовых данных от боевых как правило

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

Что фиксировать в тестовой документации

Чтобы тестовый прогон можно было воспроизвести и объяснить коллеге без переспрашивания, в документации к сценарию стоит фиксировать три вещи: какой именно адрес использовался, под какой сайт или сервис он был заказан и какой у него срок жизни — истёк ли он сразу после письма или ещё активен для повторной проверки. Без этой записи через неделю сложно понять, почему прогон нельзя повторить: адрес закрылся автоматически по регламенту формата, а не потому, что что-то сломалось в самом сценарии.

Когда хватит бесплатных средств, а когда проще арендовать

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

Частые вопросы

Подойдёт ли разовая активация для теста сценария восстановления пароля?

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

Что делать, если тестовый сценарий требует писем от нескольких сервисов на один адрес?

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

Как быть, если тестов много и заводить адрес под каждый вручную неудобно?

Если аренда и разовая активация доступны через API, процесс заказа адреса можно встроить в подготовку тестового окружения и получать адрес программно перед каждым прогоном, не делая это вручную через интерфейс.

Оформить разовую активацию под тестируемый сайт или арендовать ящик на срок сквозного сценария можно в разделе email-OTP.