Как выбрать тестовый аккаунт электронной почты для QA

Что такое тестовая почтовая запись для QA?

Тестовый почтовый аккаунт, или тестовый адрес электронной почты для QA, — это адрес, который ваша команда использует для получения и проверки писем, отправляемых вашим собственным приложением. Используйте временный почтовый ящик для ручной проверки регистрации и OTP без конфиденциальных данных. Выбирайте корпоративный почтовый ящик, если нужно сохранять сообщения, ответы или вложения, а SMTP-песочницу или хостированный входящий API — когда автоматизированные тесты должны проверять почту без участия человека.

Тмайлор ведёт этот блог, так что вот где он уместен. Tmailor — это бесплатный временный почтовый сервис только для приёма в интернете, на Android, iOS и бот Telegram. Это подходит для первого случая: человек открывает входящую, запускает регистрацию и читает полученные сообщения. В последнем случае отдельный API Tmailor Temp позволяет автоматическим тестам создавать адреса только для приёма и читать их сообщения из кода. Сообщения хранятся около 24 часов с момента поступления, вложения не принимаются, а адрес не может отправлять письма или отвечать. Если вы новичок в одноразовой почте, начните с того, как работает временная почта.

• Письмо не должно приходить (проверка формы, фикстуры, модульные тесты): используйте зарезервированный домен для примеров.
• Человек читает письмо, и в нём нет ничего конфиденциального: временный почтовый ящик — самый быстрый вариант.
• Конфиденциальные данные, ответы, вложения или доказательства, которые нужно сохранить: используйте одобренный почтовый ящик, контролируемый компанией; добавляйте плюс-теги, только если ваша почтовая система и приложение их поддерживают.
• Без участия человека: используйте SMTP-ловец, если вы управляете настройками исходящей почты приложения, или хостированный входящий API, если приложение должно отправлять через своего обычного провайдера.

Ручное и автоматическое тестирование электронной почты: дерево решений

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

1. Нужно ли, чтобы в ходе теста пришло письмо? Проверки формата, состояния интерфейса, фикстуры и модульные тесты обычно этого не требуют. Используйте адреса на example.com, example.org или example.net. Эти домены зарезервированы для документации и примеров, поэтому ничего не доходит до реального человека. Избегайте выдумывания случайных доменов, потому что кто-то может ими владеть.
2. Прочитает ли человек сообщение во время теста? Дымовые тесты, ручной UAT, демонстрации и исследовательские сессии предполагают участие человека. Регрессионные наборы и задачи CI обычно — нет.
3. Если письмо читает человек, есть ли в нём что-то конфиденциальное? Реальные записи клиентов, учётные данные, регулируемые данные или сообщения, которые нужно хранить как доказательства для аудита, не должны попадать во временный почтовый ящик. Вместо этого используйте корпоративный почтовый ящик. Если ответ — нет, временного почтового ящика достаточно.
4. Если письмо читает код, может ли тестовая среда отправлять свою почту на тестовый SMTP-сервер? Если да, SMTP-ловец перехватывает каждое сообщение, не доставляя его. Если нет, потому что приложение должно отправлять через своего обычного почтового провайдера, используйте хостированный входящий ящик, который ваши тесты читают через API.

В таблице пять вариантов сравниваются бок о бок.

Какие адреса должно принимать или отклонять поле электронной почты?

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

Когда достаточно временного входящего ящика

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

Привлекательность — скорость. Не нужно запрашивать аккаунт у IT и не нужно чистить общий почтовый ящик. Компромисс — контроль: вы получаете короткое окно хранения сообщений, отсутствие вложений и входящий ящик, который читает человек, а не код.

Когда вам нужен SMTP-перехватчик или API размещённого входящего ящика

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

SMTP-перехватчики и песочницы заменяют исходящий почтовый сервер вашего приложения в тестовой среде и сохраняют каждое сообщение для проверки вместо доставки.

• Mailpit — бесплатный инструмент с открытым исходным кодом, который вы запускаете сами. По умолчанию он перехватывает почту и предоставляет веб-интерфейс и REST API для интеграционных тестов.
• MailHog работает так же, но он старше. Сопровождающие Mailpit описывают его как больше не поддерживаемый, поэтому проверьте его статус перед тем, как его внедрять.
• Mailtrap Email Sandbox — это хостинговая версия той же идеи с доступом через SMTP и API. Это отдельный продукт, не связанный с основным сервисом Mailtrap для отправки писем.
• Ethereal — это бесплатный поддельный SMTP-сервис, который в основном используют вместе с Nodemailer. Сообщения перехватываются для предварительного просмотра и никогда не доставляются.

API размещённых входящих ящиков дают тестам реальные адреса на доменах поставщика, поэтому ваше приложение отправляет почту через своего обычного провайдера, а тест читает результат через API. Собственный Temp Mail API от Tmailor работает именно так, с официальными SDK для Python, Node.js и PHP.

• Mailosaur предлагает тестовые адреса электронной почты, API и клиентские библиотеки, совместимые с такими фреймворками, как Cypress, Playwright и Selenium. Он также поддерживает SMS-коды.
• MailSlurp создаёт входящие ящики по запросу через свой API и SDK. Тесты могут дождаться сообщения, а затем извлечь коды, ссылки и вложения.

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

Когда корпоративный почтовый ящик с тегами Plus — лучший выбор

Теги Plus позволяют одному корпоративному почтовому ящику принимать множество вариантов адреса. Письма на qa+signup или qa+reset на домене вашей компании попадают в ящик qa, где их можно отфильтровать по тегу. Google Workspace это поддерживает, а Microsoft документирует, что плюс-адресация в Exchange Online включена по умолчанию, если администратор её не отключил.

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

Как провести ручной тест регистрации с временной почтой

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

1. Откройте почтовый ящик. Создайте бесплатный временный почтовый в браузере либо используйте приложение Tmailor или бот Telegram и скопируйте адрес. На компьютере расширение браузера Tmailor также может подставить его в поле электронной почты вашей тестовой сборки.
2. Зарегистрируйтесь в тестовой сборке. Используйте адрес в среде staging или QA и запишите время отправки формы.
3. Дождитесь письма. Проверьте, какое сообщение пришло, имя отправителя и адрес From, тему и сколько времени это заняло.
4. Завершите шаг. Перейдите по ссылке или введите код. Убедитесь, что аккаунт меняет состояние один раз, а повторное использование той же ссылки завершается понятным сообщением об ошибке.
5. Запишите доказательства в другом месте. Скопируйте ссылку, код, временные метки и скриншот в ваш тест-кейс. Сообщения хранятся около 24 часов с момента получения, поэтому почтовый ящик — не ваш тестовый журнал.
6. Сохраните access token, если будете перепроверять. Токен позже открывает тот же адрес, например чтобы повторно запустить сброс пароля. Он не восстанавливает уже истёкшие сообщения, а потерянный токен восстановить нельзя.

Когда в одной сессии нужно несколько ролей одновременно, например бесплатный пользователь, пробный пользователь и приглашённый коллега, просмотр множественных входящих показывает до пяти адресов рядом в одной вкладке браузера. У каждой роли свой адрес, поэтому видно, какое письмо какому аккаунту принадлежит.

Это представление всё ещё ручное. Ящики создаёт человек в браузере, а не код, поэтому оно не заменяет API размещённых входящих ящиков для параллельных автоматических запусков.

Один ящик или один адрес на тест?

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

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

Некоторые сценарии требуют того же адреса снова через несколько дней — например, пробный период, который переходит в платный, или пользователь, вернувшийся после оттока. Многоразовый временный почтовый адрес сохраняет адрес доступным через его Access Token, но не саму почту. Сохраняйте нужные ссылки и коды по мере выполнения каждого шага, а любой шаг, зависящий от старых сообщений, переносите в корпоративный ящик. Если тестировщик входит в бесплатный аккаунт Tmailor до создания адресов персон, каждый из них сохраняется в разделе «Созданные письма», так что потерянный токен больше не означает потерянный адрес.

Что проверять в письмах регистрации и онбординга

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

Письма в типичном сценарии регистрации

• Ссылка для подтверждения или одноразовый код
• Приветственное письмо и любая серия быстрого старта
• Вход по magic-link
• Сброс пароля
• Изменение адреса электронной почты, отправляемое на старый и новый адрес
• Оповещение о безопасности при новом устройстве или новом местоположении
• Напоминания о незавершённых регистрациях

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

Что проверять в каждом тестовом письме

• Отправитель и получатель: имя и адрес отправителя, Reply-To и точный адрес в поле To.
• Тема и тело письма: обе версии — HTML и обычный текст — с правильными именами, данными тарифа и языком.
• Ссылки: куда ведёт ссылка и указывает ли она на нужную среду. Письмо со стенда, ведущее в продакшн, — это настоящая ошибка.
• Коды: формат, длина, текст об истечении срока и совпадает ли заявленный срок с тем, что реально применяет сервер.
• Время: сколько времени прошло от срабатывания триггера до прихода письма.
• Вложения: если поток отправляет PDF или счет, протестируйте его в корпоративном почтовом ящике или инструменте тестирования. Тмайлор не получает вложения.

Одно замечание об отображении. Временная почта показывает, как ваш HTML выглядит в одном веб-просмотрщике. Она не скажет, как то же письмо выглядит в Gmail, Outlook, Apple Mail, в тёмной теме или на маленьком экране телефона, поэтому, если это важно, планируйте отдельные проверки отображения.

Сценарии смены электронной почты и восстановления аккаунта

Сценарии восстановления ломаются незаметнее, чем регистрация. Проверьте, что при смене электронной почты подтверждение приходит на новый адрес, а уведомление — на старый; что использованную ссылку сброса нельзя применить повторно; что старая ссылка сброса перестаёт работать после отправки новой; и что ссылка, открытая на втором устройстве, приводит пользователя в разумное состояние. Сценарии OTP заслуживают отдельного анализа рисков; список рисков OTP для QA и UAT охватывает метрики, интервалы повторной отправки и ответственность.

Как тестировать OTP и граничные случаи верификации

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

• Медленный приход: подождите перед проверкой ящика и убедитесь, что интерфейс объясняет, что происходит, и предлагает понятный способ отправить код повторно.
• Повторная отправка: запросите второй код и проверьте, аннулируется ли первый или всё ещё принимается.
• Истечение срока: введите код после заявленного срока его жизни и убедитесь, что сообщение об ошибке соответствует тому, что произошло.
• Неверный код: убедитесь, что лимит попыток и текст о времени ожидания понятны человеку.
• Магические ссылки на другом устройстве: запросите ссылку на ноутбуке, откройте её на телефоне и проверьте, куда попадает пользователь.

Чтобы шире понять, какие коды доходят до временной почты, а какие нет, смотрите это руководство по временной почте для OTP-кодов.

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

Что меняется, когда тесты почты выполняются без присмотра

Когда рядом нет человека, тесту нужен почтовый ящик, который можно читать программно. Для этого подойдёт API SMTP-перехватчика или API размещённого почтового ящика. Веб-ящик Tmailor для этого не подходит, а Tmailor Temp Mail API — подходит: тесты могут создавать адреса только для приёма, получать список и читать сообщения, а также извлекать одноразовый код или ссылку для подтверждения, которые находит API. MCP-сервер позволяет ИИ-агентам, таким как Claude, Cursor или VS Code Copilot, делать то же самое для сценариев регистрации, которые вам принадлежат или которые вам разрешено тестировать.

Несколько привычек помогают сохранять стабильность автономных тестов почты при любом выбранном инструменте:

• Выделяйте каждому запуску теста собственный адрес и идентификатор корреляции, чтобы запоздавшее письмо от предыдущего запуска не могло удовлетворить неверную проверку.
• Используйте отдельное ожидание прихода письма с разумной задержкой повторов, независимое от общего тайм-аута теста, и логируйте, сколько времени заняло каждое сообщение.
• Сопоставляйте конкретное сообщение по получателю и теме, а не читайте «последнее письмо».
• Маскируйте коды и magic-ссылки в логах CI, поскольку логи часто живут дольше почтового ящика.

Также чётко понимайте, что доказывает успешный тест. «Приложение сгенерировало и передало письмо», «размещённый тестовый домен получил его через публичную почтовую инфраструктуру» и «Gmail поместил его во входящие, а не в спам» — это три разных факта. SMTP-перехватчик доказывает первое, API размещённого ящика доказывает первые два, и ни один из них не доказывает третье. О настройке конвейера на GitHub Actions, GitLab CI и CircleCI см. руководство по тестированию электронной почты в конвейерах CI/CD.

Берегите тестовые данные и соблюдайте правила

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

• Никаких реальных данных во временной почте. Никогда не направляйте реальные записи клиентов, учётные данные, ключи API или регулируемые данные на адрес временной почты. Используйте синтетических пользователей с явно вымышленными именами.
• Тестируйте только то, что вам разрешено. Проводите тесты регистрации на своём продукте или системе, которую вы уполномочены тестировать, и соблюдайте ограничения по частоте запросов и условия этого сервиса. Не используйте временную почту для массового создания аккаунтов на сторонних сайтах. Тестирование объёма и нагрузки должно проходить в вашей собственной среде staging с SMTP-перехватчиком или API размещённого ящика.
• Не допускайте QA-трафик в производственную статистику. Чётко помечайте тестовые аккаунты и исключайте их из аналитики и дашбордов роста. Избегайте отправки больших объёмов тестовых писем с вашего производственного домена отправки, где отказы и жалобы могут навредить его репутации.
• Зафиксируйте политику письменно. Укажите, какие сценарии могут использовать временную почту, каким нужен корпоративный ящик, как долго хранятся тестовые данные и у кого есть доступ. Проверки безопасности и соответствия проходят быстрее, когда границы уже закреплены на бумаге.

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

Ограничения, которые стоит учесть

Веб-ящик Tmailor подходит для коротких ручных проверок неконфиденциальной входящей почты (для автоматизации предназначен API временной почты). Перед выбором решите, нужны ли в сценарии исходящие действия, вложения, долгосрочные доказательства или надёжное восстановление адреса. Любое из этих требований означает, что нужен контролируемый компанией ящик или специализированный инструмент тестирования; в чек-листе ниже объясняется почему.

• Тмайлор доступен только для приёма. Он может проверять входящую регистрацию, верификацию и почту OTP, но не отвечать или отправлять с этого адреса.
• Tmailor не принимает вложения, поэтому письма со счетами, договорами или документами требуют корпоративного ящика или инструмента тестирования.
• Сообщения хранятся около 24 часов с момента поступления. Экспортируйте ссылки, коды и временные метки, которые понадобятся для более длительного расследования.
• Access Token снова открывает адрес, но не просроченные сообщения, а потерянный токен восстановить нельзя.
• Веб-ящик читает человек. Для чтения ящика без участия человека нужен SMTP-перехватчик или размещённый в облаке API входящих писем, например Tmailor Temp Mail API.
• Некоторые сервисы блокируют домены одноразовой почты. Если проверяемый сценарий делает это намеренно, проверьте его с реальным адресом или адресом, контролируемым компанией.

Как выбрать подходящий тестовый ящик

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

Для ручных случаев откройте временный входящий ящик и начните со сценария регистрации, который вы выпускаете следующим. У временной почты есть немало практических применений, помимо QA.