Тимчасова пошта для тестування: як розробники й 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 вкладень.

Лише приймання

З адреси не можна надсилати листи чи відповідати. Сценарії, де користувач має відповісти поштою, наприклад листування в тікетах підтримки, тут не перевірити від початку до кінця.

Домен

Один домен для всіх адрес. Якщо ваш продукт блокує відомі тимчасові домени, він заблокує й наш, і це корисно, коли ви хочете перевірити саме таку поведінку.

Нові скриньки

П’ять нових скриньок на хвилину з однієї 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.