Я випустив більше сценаріїв реєстрації, ніж можу порахувати. І щоразу тестування підтвердження email — та сама історія: скринька заповнюється тестовими листами, я починаю плутати, який тест був який, а десь на сороковій тестовій реєстрації взагалі перестаю дивитися на листи. Кажу собі, що приберу їх потім. Не прибираю. Через пів року після запуску в моїй скриньці досі лежить 200 тестових листів підтвердження, які нікому не потрібні.
Це справді погана звичка — не лише з погляду порядку, а й для якості самого тестування. Коли скринька повна попередніх тестових листів, значно важче переконатися, що конкретний тест щойно спричинив конкретне надсилання. Ви починаєте робити припущення замість того, щоб справді перевіряти. Пропускаєте непомітні баги. І все це зовсім не обов’язково, бо є набагато кращий підхід.
Ця стаття про те, як зробити тимчасову пошту ключовою частиною робочого процесу, коли ви створюєте й тестуєте підтвердження email. Так процес стає швидшим, чистішим, ретельнішим і, чесно кажучи, значно приємнішим.
З чого насправді складається підтвердження email
Перш ніж говорити про тестування, варто точно визначити, що саме ми тестуємо. Підтвердження email — це не просто «надіслати посилання». Це багатокроковий процес із кількома компонентами, які можна тестувати окремо, — ті самі частини, які доводиться складати докупи, коли ви створюєте систему підтвердження email з нуля, — і кожна з них може зламатися по-різному, іноді дуже непомітно.
Крок перший: генерація криптографічно стійкого токена. OWASP Authentication Cheat Sheet тут однозначний: токени підтвердження треба генерувати криптографічно стійким генератором випадкових чисел, вони мають бути завдовжки щонайменше 32 байти й зберігатися так, щоб їх можна було перевірити на сервері, але не можна було відновити. Не послідовне ціле число. Не передбачуваний хеш ID користувача. Справжній випадковий токен.
Крок другий: збереження токена з потрібними метаданими — якому користувачу він належить, коли створений, коли спливає і чи вже використаний. Крок третій: формування листа. Це тема, ім’я відправника, текст, URL підтвердження і перевірка, що цей URL веде на правильне середовище (а не на продакшен із вашого dev-сервера). Крок четвертий: доставка листа через SMTP. RFC 5321 визначає специфікацію Simple Mail Transfer Protocol — навіть базове розуміння того, як працює SMTP, допомагає діагностувати проблеми з доставкою, коли вони виникають.
Крок п’ятий: користувач клікає посилання. Ваш сервер перевіряє токен: чи він існує? Чи не прострочений? Чи не використаний раніше? Якщо всі перевірки пройдено, акаунт позначається як підтверджений, а токен анулюється. Якщо будь-яка перевірка не пройшла, користувач бачить зрозуміле повідомлення про помилку. Кожен із цих кроків — тест-кейс. Кожен може бути неправильним по-своєму. Ретельне тестування охоплює їх усі.
Чому тестувати зі справжньою поштою — погана ідея
Використання справжньої адреси для тестування під час розробки має кілька конкретних проблем, які накопичуються протягом проєкту. Найочевидніша — безлад: після сотні тестових реєстрацій скринька повна листів підтвердження, які вже нікому не потрібні. Знайти серед цього шуму результат конкретного тесту справді важко. Ви можете почати автоматично відфільтровувати такі листи, тобто перестанете їх читати, а отже, перестанете помічати баги відображення й помилки в тексті шаблонів.
Є й глибша проблема: зі справжньою адресою неможливо зімітувати «нового користувача, якого система ще не бачила». Ваша адреса вже є в базі. Щоб протестувати нову реєстрацію, доводиться видаляти акаунт і реєструватися знову — це морока, і ви не можете зберегти жодного попереднього тестового стану. З тимчасовою адресою кожен тест — справді новий користувач зі справді новою скринькою.
Крім того, деякі поштові сервіси починають позначати як спам повторювані схожі листи, що за короткий час надходять з того самого домену. Ваші тестові листи можуть узагалі перестати доходити, і ви подумаєте, що ланцюжок доставки зламаний, хоча це не так. А одночасні реєстрації протестувати просто неможливо — якщо треба перевірити, що буде, коли троє користувачів реєструються одночасно, з однією справжньою адресою цього не зробиш.
Рішення з тимчасовою поштою — крок за кроком
Ось як саме я використовую temp-email.ai у своєму робочому процесі. Відкрийте тимчасову пошту у вкладці браузера поруч зі своїм середовищем розробки. Унікальна адреса вже чекає на вас — без налаштувань і без створення акаунта. Скопіюйте її одним кліком.
Перейдіть у свій застосунок. Відкрийте сторінку реєстрації. Вставте тимчасову адресу в поле email і заповніть решту форми. Надішліть. Поверніться на вкладку temp-email.ai. Якщо доставку пошти налаштовано правильно, лист підтвердження надійде за 2–5 секунд. Ви побачите тему, ім’я відправника й увесь текст листа, відображений так само, як у будь-якому справжньому поштовому клієнті.
Клікніть посилання підтвердження прямо в тимчасовій скриньці. Ваш застосунок має обробити його правильно — перенаправити на потрібну сторінку, показати стан успіху й позначити акаунт як підтверджений. Ви щойно провели повний наскрізний тест підтвердження, і той самий підхід масштабується до наскрізного тестування реєстрації та оплати, коли справа доходить до checkout. Тепер відкрийте другу вкладку й повторіть усе зі свіжою адресою, щоб протестувати одночасну реєстрацію. Увесь процес від «треба протестувати» до «тест завершено» займає близько двох хвилин.
Що тестувати в сценарії підтвердження
Ось повний чек-лист, який я проходжу, тестуючи реалізацію підтвердження email:
- Базова доставка: чи надходить лист? Перевірте це в кількох сценаріях — що відбувається, коли ви реєструєтеся в чистому локальному середовищі, на staging і в продакшені? Проблеми з доставкою часто залежать від середовища.
- Правильність посилання: чи веде URL підтвердження в листі на правильне середовище? До сорому легко жорстко прописати URL продакшену в шаблоні, який потім використовується в розробці. Посилання має формуватися динамічно з налаштування базового URL.
- Безпека токена: чи має токен щонайменше 32 символи і чи справді він випадковий? Подивіться на токен в URL — він має виглядати як випадковий рядок літер і цифр, а не передбачуваний шаблон. Конкретні рекомендації щодо генерації токенів дивіться в OWASP Authentication Cheat Sheet.
- Термін дії токена: що буде, якщо почекати довше за строк дії посилання, а потім клікнути його? Застосунок має обробити це коректно — зрозуміле повідомлення, що посилання прострочене, і пропозиція запросити нове. А не загальна помилка 500.
- Одноразовість: чи можна використати те саме посилання двічі? Після першого підтвердження повторний клік не має спрацювати. Користувач має побачити, що акаунт уже підтверджено або що посилання недійсне. Перевірте це окремо.
- Повторна реєстрація до підтвердження: що буде, якщо користувач зареєструвався, не підтвердив email, а потім спробував зареєструватися знову з тією самою адресою? Чи правильно це обробляє застосунок — надсилає лист повторно чи радить перевірити скриньку?
- Повторне надсилання: чи працює кнопка «надіслати лист ще раз»? Чи анулює вона попередній токен і надсилає новий? Перевірте, клікнувши кілька разів поспіль — що буде, якщо хтось натисне її десять разів?
- Відображення HTML: чи правильно відображається шаблон листа в справжній скриньці? У переглядачі temp-email.ai перевірте: чи кнопки справді клікабельні? Чи завантажуються зображення? Чи не зламана верстка на десктопі й мобільному? Чи не виходить текст за межі?
- Тема й ім’я відправника: чи тема зрозуміла, професійна й не схожа на спам? Чи ім’я відправника — назва вашого бренду, а не загальна назва провайдера? Це важливо для доставлюваності й довіри користувачів.
- Персоналізація: чи правильно підставилося ім’я користувача там, де воно має бути в тексті листа? Це поширений баг шаблонів — підстановка змінної тихо не спрацьовує, і ви надсилаєте «Привіт, {{firstName}}» замість «Привіт, Оксано».
Тестування різних сценаріїв
Стандартна реєстрація — не єдиний сценарій, що надсилає листи на кшталт підтвердження. Якщо ваш застосунок підтримує вхід через соцмережі — «Зареєструватися через Google» чи OAuth через подібних провайдерів, — більшість реалізацій усе одно надсилає вітальний лист або підтвердження створення акаунта. Протестуйте й цей сценарій. Відкрийте тимчасову скриньку, використайте її як пов’язану адресу для тестового OAuth і переконайтеся, що вітальний лист надходить і виглядає правильно.
Скидання пароля за структурою майже ідентичне підтвердженню email: згенерувати безпечний токен, надіслати посилання листом, перевірити при кліку, анулювати після використання. Кожен пункт наведеного вище чек-листа так само стосується скидання пароля. Як і підтвердження зміни адреси — коли користувач змінює email у налаштуваннях, нову адресу треба підтвердити, перш ніж перемикатися на неї. Це ще один повноцінний поштовий сценарій, який слід тестувати окремо.
Листи-запрошення — коли користувач запрошує колегу приєднатися — додають ще один вимір: скриньку запрошеного. З тимчасовими адресами можна протестувати обидві сторони запрошення в одному сеансі браузера. Надішліть з основного тестового акаунта, отримайте на тимчасову адресу, прийміть і перевірте стан після прийняття. Чисто, повно й швидко.
Кілька користувачів одночасно
Це одна з найбільших переваг тимчасових адрес для тестування під час розробки, і з одним справжнім акаунтом пошти це просто неможливо. Кожна вкладка браузера на temp-email.ai — повністю незалежна скринька. Можна відкрити п’ять вкладок одночасно, кожну з іншою адресою, зареєструвати в застосунку п’ять акаунтів водночас і спостерігати, як п’ять незалежних листів підтвердження надходять у реальному часі в п’ять окремих скриньок.
Таке паралельне тестування ловить цілий клас багів, яких послідовне тестування з одним користувачем не виявить ніколи: стани гонитви під час генерації токенів, взаємоблокування бази на перевірках унікальності, затримки обробки черги, через які одні листи підтвердження приходять набагато пізніше за інші, і несподівані взаємодії між паралельними сеансами. Якщо ви створюєте продукт, розрахований більш ніж на жменьку користувачів, QA-тестування з кількома одночасними реєстраціями — не опція, а необхідність. Тимчасові адреси роблять його елементарним.
Не лише підтвердження — інші транзакційні листи, які варто тестувати
Коли у вас уже налагоджено процес із тимчасовою поштою, застосуйте його до кожного транзакційного листа, який надсилає ваш застосунок. Кожен із них заслуговує на окремий тестовий прогін:
- Листи для скидання пароля: ті самі питання безпеки й терміну дії токена, що й у підтвердженні. Окремо перевірте сценарії з простроченим і вже використаним посиланням.
- Листи-запрошення: їх отримує запрошений, а не наявний користувач — ідеальний випадок для свіжої тимчасової скриньки.
- Підтвердження замовлень і квитанції: перевірте, що всі позиції, ціни й посилання правильні. Зламане підтвердження замовлення — кошмар для служби підтримки.
- Сповіщення про активність: зведені дайджести, сповіщення про згадки, стрічки активності. Перевірте, що вони надсилаються лише тоді, коли відповідна активність справді сталася.
- Підтвердження відписки: коли користувач відписується від маркетингу, чи отримує він підтвердження? Чи є заголовок відписки в один клік (обов’язковий для масових відправників)?
- Підтвердження видалення акаунта: якщо ваш застосунок надсилає фінальне підтвердження, коли користувач видаляє акаунт, переконайтеся, що воно працює і що ви справді можете прочитати лист у тимчасовій скриньці до того, як акаунт зникне.
На що дивитися в тестових листах
Отримавши тестовий лист у тимчасову скриньку, не обмежуйтеся кліком на посилання. Витратьте п’ятнадцять секунд, щоб як слід роздивитися лист. Перевірте заголовки, якщо тимчасова скринька їх показує, — чи пройшли SPF і DKIM? Це важливо для доставлюваності реальним одержувачам. Якщо ваш домен-відправник не налаштований належно для DKIM, листи можуть потрапляти в спам у реальних користувачів, хоча в тестових середовищах усе працює.
Подивіться на відображення HTML. Шаблон може виглядати ідеально в локальному інструменті попереднього перегляду, а потім зламатися в справжній скриньці, бо різні поштові клієнти обробляють CSS дуже по-різному. Перегляд у справжній скриньці — хай навіть тимчасовій — виявляє проблеми, які пропускають інструменти попереднього перегляду. Перевірте кнопки, завантаження зображень, чи не обрізається текст і чи не виходить за межі контейнера. Якщо можете переглянути й мобільну версію, зробіть це — непропорційно велика частка листів відкривається на мобільних.
Перевірте час доставки. За правильно налаштованої транзакційної пошти лист має надходити в тимчасову скриньку не довше ніж за 2–5 секунд із моменту надсилання. Постійні затримки довші за це — скажімо, 20–30 секунд — свідчать про проблему з обробкою черги чи затримку DNS-резолвінгу у вашій конфігурації надсилання, яку варто дослідити, перш ніж її відчують ваші реальні користувачі.
Як зробити це звичкою
Зміна в робочому процесі справді невелика. Замість того щоб вводити справжню адресу в тестову форму реєстрації, ви витрачаєте п’ять секунд, щоб відкрити тимчасову пошту в новій вкладці й скопіювати адресу звідти. Ось і вся зміна. Але її вплив на якість тестування суттєвий.
Ви тестуєте ретельніше, бо перевірка не вимагає зусиль. Ловите більше багів відображення, бо щоразу бачите, як лист виглядає в справжній скриньці. Можете тестувати паралельні сценарії, які раніше були непрактичними. Ваша справжня скринька залишається чистою. І ви виробляєте звичку вважати пошту повноцінною частиною тестування, а не чимось другорядним, — а це правильна модель мислення для створення продуктів, яким люди справді довіряють.