«Електронний лист прибув» — це недостатній результат тесту.
Повідомлення про реєстрацію може потрапити у вхідні з неправильним одержувачем, простроченим посиланням, поламаним мобільним макетом, доменом продакшн або темою, яка не має сенсу в іншій мові. Хороше тестування електронної пошти охоплює весь шлях користувача і залишає достатньо доказів для діагностики збою.
Тимчасові скриньки тут корисні, бо кожен запуск може починатися з чистої адреси. Скринька має бути одноразовою; результат тесту — ні.
Створіть невелику, продуману матрицю
Почніть з потоків, які можуть блокувати користувача:
- перевірка новоствореного облікового запису;
- скидання пароля;
- запрошення до команди або робочого простору;
- підтвердження зміни електронної адреси;
- посилання для входу або одноразовий код;
- сповіщення про безпеку після чутливої дії.
Для кожного потоку протестуйте щасливий шлях, один прострочений або повторно використаний обліковий запис і одну помилку на боці одержувача. Це виявляє більше реальних дефектів, ніж надсилання десятків ідентичних щасливих повідомлень.
Використовуйте одну поштову скриньку на сценарій
Повторне використання однієї адреси створює неоднозначність. Старе повідомлення про скидання може бути сплутане з новим, а паралельні тести можуть споживати посилання один одного.
Генеруйте унікальну адресу для кожного тестового випадку або запуску. Записуйте її разом з номером збірки, середовищем, локаллю та сценарієм. Якщо тест провалюється, адреса стає частиною доказу і її можна переглянути до закінчення терміну зберігання.
Не використовуйте реальні адреси клієнтів у staging. Це створює небажані повідомлення, забруднює аналітику та ускладнює автоматичне очищення.
Перевірте конверт перед вмістом
Перед тим як щось клікати, переконайтеся у наступному:
- Повідомлення надійшло на саме ту адресу, яку створено для цього тесту.
- Домен відправника відповідає очікуваному для даного середовища.
- Тема ідентифікує дію, не розкриваючи конфіденційних даних.
- Прийшло лише очікуване число повідомлень.
- Часова мітка пізніше дії, яка його ініціювала.
Ці перевірки виявляють проблеми маршрутизації та дублювання ще до того, як парсер вмісту їх сховає.
Тестуйте вміст так, як його бачить користувач
Відкрийте повідомлення в вузькому та широкому вікні переглядача. Переконайтеся, що головна дія видима, текстовий fallback зрозумілий, а довгі адреси чи URL не ламають макет.
Для потоків з кодом перевірте, що новий код працює один раз і після використання не діє. Для потоків з посиланням підтвердіть хост і середовище перед відкриттям. Повідомлення у staging, яке вказує на продакшн, блокує реліз, навіть якщо посилання технічно працює.
Також перевірте менш помітні деталі: поведінку reply‑to, контакт підтримки, формулювання терміну дії, локаль та назву облікового запису або робочого простору, що вказані в листі.
Негативні випадки, які варто залишити
Корисні негативні тести включають:
- запит другого коду та підтвердження, що перший анульовано;
- відкриття простроченого посилання;
- відкриття того самого посилання двічі;
- зміна стану облікового запису перед використанням листа;
- запрошення адреси, яка вже належить учаснику;
- введення непідтримуваної або некоректної адреси;
- затримка доставки настільки, що вона переходить межу терміну дії.
Ці тести виявляють гонки та вводять в оману повідомлення про помилки, які простий перевірка скриньки ніколи не знайде.
Відокремте збій продукту від затримки доставки
Коли повідомлення відсутнє, зберігайте часові мітки дії користувача, постановки в чергу, передачі провайдеру та прибуття в скриньку, якщо ці сигнали доступні. Скриншот порожньої скриньки доводить лише, що лист не був видимий у той момент.
Використайте діагностичну послідовність у Лист підтвердження не надходить: знайдіть поломаний крок перед тим, як створювати нечітке «електронна пошта не працює»‑завдання.
Що автоматизувати
Автоматизуйте стабільні контракти:
- генеруйте унікальну адресу;
- ініціюйте дію продукту;
- опитуйте з обмеженим тайм‑аутом та бекоффом;
- порівнюйте очікуваного відправника та тему;
- читайте найновіше підходяще повідомлення;
- валідируйте код або посилання проти продукту;
- зберігайте корисні докази збою;
- виконуйте очищення.
Залиште візуальну перевірку, якість копії та незвичну поведінку клієнта у сфокусованому ручному проході. Автоматизація добре підходить для повторень, а не для смаку.
Reliable Temporary‑Inbox API Automation охоплює сторону API, включаючи опитування та очистку.
Корисний звіт про збій
Звіт, який розробники можуть використати, містить сценарій, середовище, адресу, час тригеру, очікуваного відправника, спостережувані повідомлення, час останнього опитування, статус відповіді та скриншот або санітизований уривок тіла. Ніколи не додавайте живі секрети чи повторно використовувані верифікаційні посилання до публічної задачі.
Мета не довести, що електронна пошта ненадійна. Мета — визначити, який контракт зламався, і залишити відтворюваний шлях до виправлення.