Временная почта для тестирования: как разработчики и QA проверяют регистрацию

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

Мы сами держим почтовые серверы PureTempMail, поэтому ограничения ниже - это наши реальные настройки, а не догадки. В этом руководстве: где публичный временный ящик уместен в тест-плане, ручной прогон на пять минут, чек-лист, по которому мы проверяли бы собственные письма при регистрации, и случаи, когда нужен другой инструмент.

Место временного ящика среди других способов тестирования

Есть пять распространённых способов дать тестовому аккаунту адрес. Большинство команд в итоге используют два-три из них на разных этапах одного релиза.

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

Ручной тестовый прогон с PureTempMail

Такой прогон мы советуем для ручной проверки регистрации. Один проход занимает около пяти минут.

1. 1

   Открывайте новый ящик для каждого тестового пользователя

   Откройте PureTempMail в отдельном окне браузера. Новый адрес создаётся при загрузке. Ящик запоминается для каждого браузера, поэтому для каждого тестового пользователя нажимайте Новый или используйте приватное окно, если за одним компьютером работают два тестировщика.

2. 2

   Записывайте адрес рядом с тест-кейсом

   Вставьте адрес в тест-кейс или тикет до того, как используете его. Если позже тестировщик спросит, почему письмо для сброса так и не пришло, нужно знать, в какой ящик оно ушло.

3. 3

   Пройдите регистрацию и вызовите все возможные письма

   Заполните форму, затем запросите все письма, которые новый пользователь может вызвать за первую сессию: повторное подтверждение, восстановление пароля, вход по волшебной ссылке, смену email. Каждое из них - отдельный шаблон, который может сломаться сам по себе.

4. 4

   Следите за ящиком, не обновляя страницу

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

5. 5

   Открывайте каждое письмо в обоих режимах

   Прочитайте его в режиме HTML, затем переключитесь на Текст. Текстовый режим - это то, к чему возвращаются некоторые клиенты и программы чтения с экрана, и именно там первым делом видна отсутствующая текстовая часть или нечитаемый код. Нажмите каждую ссылку и проверьте, куда она ведёт.

6. 6

   Продлевайте, если сценарий медленный

   Цепочкам писем, отложенным подтверждениям и напоминаниям на второй день нужно больше времени. Нажмите +1 ч, чтобы снова выставить таймер на полный час. Так можно делать до тех пор, пока с момента создания ящика не пройдёт 24 часа.

7. 7

   Дайте ящику истечь и проверьте отказ

   После истечения наш сервер отклоняет почту на этот адрес ещё на этапе SMTP с постоянной ошибкой «No such mailbox». Отправьте на него ещё одно письмо и проверьте, что ваше приложение или почтовый провайдер зафиксировал жёсткий отказ и перестал писать этому пользователю.

Чек-лист тестирования писем при регистрации

Эти проверки мы провели бы с письмами при регистрации в любом продукте перед релизом. Каждую легко заметить в настоящем ящике и легко пропустить при код-ревью.

• Код или ссылка подтверждения. Письмо приходит, код читается в текстовом виде, ссылка срабатывает один раз, а повторное нажатие показывает понятное сообщение, а не страницу ошибки.
• Волшебные ссылки и одноразовые коды. Новая ссылка делает старую недействительной, просроченная ссылка объясняет, что делать дальше, а открытие ссылки в другом браузере ведёт себя так, как вы задумали.
• Сброс пароля. В письме указано, к какому аккаунту оно относится, ссылка истекает, а запрос сброса для незарегистрированного адреса не раскрывает, есть ли у этого адреса аккаунт.
• Приветственные письма и цепочки. Первое приходит после подтверждения, а не до него, а следующие шаги не срабатывают для пользователей, которые так и не подтвердили адрес.
• HTML и текстовая часть. Обе есть, обе говорят одно и то же, и ничего важного нет только на картинке. Внешние изображения загружаются в нашем режиме HTML, так что их можно проверить там, а в режиме «Текст» посмотреть письмо без них.
• Вложения. Счета и PDF приходят с понятными именами файлов и типами содержимого. Держите тестовые файлы меньше 1 МБ на письмо или отправляйте ссылку на скачивание, что к тому же удобнее для реальных пользователей.
• Адреса ссылок. Ни одна ссылка в письме с продакшена не ведёт на localhost, внутреннее имя хоста или тестовый домен, а трекинговые редиректы приводят на нужную страницу.
• Заголовки отписки. Маркетинговые письма и цепочки содержат рабочую ссылку отписки, а у массовых отправителей ещё и заголовок отписки в один клик List-Unsubscribe, описанный в RFC 8058, который требуют от массовых отправителей правила Google для отправителей. Транзакционные письма, например для сброса пароля, не должны блокироваться отпиской.
• Время доставки. Письма с подтверждением, которые идут дольше минуты-двух, теряют пользователей. Если письмо медленное, проверьте, не ставит ли приложение почту в очередь за другими задачами и не ограничивает ли провайдер новых отправителей.
• Ваши собственные лимиты. Жмите кнопку повторной отправки без остановки. Приложение должно ограничить её и попросить пользователя подождать, а не отправить десять кодов или молча сломаться.
• Повторное использование адреса. Зарегистрируйтесь дважды с одним адресом за одну сессию и проверьте вторую попытку: понятный путь «уже зарегистрирован» и никакого второго аккаунта.
• Ваше правило против одноразовых доменов. Если продукт блокирует временные адреса, убедитесь, что сообщение об ошибке понятное и что по ошибке не блокируются настоящие провайдеры. Подробнее об этом ниже.

Наши ограничения и что они значат для теста

Это реальные настройки наших серверов. Планируйте тестовые прогоны с их учётом.

Срок жизни

Один час с момента создания. +1 ч снова выставляет его на полный час, но не дольше 24 часов после создания. Хватит на сессию, но не на тестовый аккаунт, который понадобится в следующем спринте.

Письма

До 50 писем и 5 МБ на ящик. Когда достигнут любой из лимитов, новая почта отклоняется, поэтому нагрузочный тест на один адрес быстро перестаёт что-либо считать. Открывайте новый ящик для каждого тестового пользователя.

Размер письма

До 1 МБ на письмо вместе с вложениями. Сохраняются только первые 10 вложений.

Только приём

С адреса нельзя отправлять письма или отвечать. Сценарии, где пользователь должен ответить по email, например переписку в тикетах поддержки, здесь не проверить от начала до конца.

Домен

Один домен для всех адресов. Если ваш продукт блокирует известные временные домены, он заблокирует и наш, и это полезно, когда вы хотите проверить именно такое поведение.

Новые ящики

Пять новых ящиков в минуту с одного IP-адреса. Команда QA за одним офисным подключением делит этот лимит на всех.

Удаление

После истечения очистка, которая запускается каждые пять минут, удаляет ящик, его письма и вложения. Если для баг-репорта нужны доказательства, сделайте скриншоты до того, как истечёт таймер.

Автоматизация

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

Проверка SPF, DKIM и DMARC в тестовых письмах

Письмо, которое хорошо отображается, всё равно может не пройти аутентификацию и попасть в спам у реальных пользователей. Чтобы проверить, отправьте то же письмо в ящик, который показывает исходный код, например через «Показать оригинал» в Gmail, и вставьте заголовки в наш анализатор заголовков email. Он покажет, пройдены ли SPF, DKIM и DMARC, отметит Reply-To на другом домене и покажет, где доставка задержалась. Анализ выполняется в вашем браузере, поэтому заголовки нам не отправляются.

Тестирование собственной блокировки одноразовых доменов

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

• Проверьте формулировку. Отказ должен подсказывать, чем воспользоваться вместо этого, например «Укажите личный или рабочий адрес». Голое «Неверный email» заставляет честных пользователей искать опечатку, которой нет.
• Проверьте ложные срабатывания. Попробуйте адреса у небольших региональных провайдеров и на корпоративных доменах компаний. Списки блокировки, работающие по шаблонам, иногда их задевают.
• Проверьте все точки входа. Одно и то же правило должно действовать для формы регистрации, настройки смены email, приглашений и API, иначе люди просто воспользуются тем путём, о котором вы забыли.
• Решите, нужна ли блокировка вообще. Наша статья о том, почему сайты блокируют одноразовую почту, описывает издержки, которые её оправдывают, и случаи, когда она лишь отпугивает честных пользователей.

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

В этих случаях используйте что-то другое.

• Всё, что содержит настоящие секреты или данные клиентов. Боевые токены, реальные счета, приглашения администраторов. Используйте песочницу, которую может читать только ваша команда.
• Автотесты и CI. В разработке и CI направляйте почту приложения в локальный перехватчик вроде Mailpit, а когда тесты должны идти на развёрнутом окружении, в облачную песочницу, например Mailtrap или Mailosaur. MailHog, более старый локальный перехватчик, больше не поддерживается, и обычно его заменяют на Mailpit.
• Тестовые стенды с копиями реальных пользовательских данных. Проблема здесь в самих скопированных данных. Очистите их и направляйте почту со стенда в перехватчик, чтобы тест никогда не написал реальному клиенту.
• Тестовые аккаунты, которые нужно сохранить. Демо-аккаунту для отдела продаж или аккаунту для проверки в магазине приложений нужен адрес, который будет работать и через месяц. Используйте плюс-адресацию в командном ящике или catch-all на собственном тестовом домене.
• Фикстуры, которые никогда не должны доставляться. Для начальных данных и юнит-тестов используйте зарезервированные домены, например example.com, и домен верхнего уровня .test, выделенные в RFC 2606. Почта на них по замыслу никуда не уходит.

Источники

• Mailpit на GitHub, инструмент и API для тестирования почты для разработчиков, а также его заметки о замене MailHog.
• Документация Mailtrap Email Sandbox.
• Клиентские библиотеки Mailosaur на GitHub.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, правила для отправителей писем.
• RFC 2606, Reserved Top Level DNS Names.
• Срок жизни ящика, лимиты на размер и количество писем, лимиты запросов, отклонение по SMTP после истечения и периодичность очистки взяты из собственной конфигурации серверов PureTempMail и также кратко описаны в FAQ.