Як обрати тестовий email-акаунт для QA

Що таке тестовий email-акаунт для QA?

Тестовий email-акаунт, або тестова електронна адреса для QA, — це адреса, яку ваша команда використовує, щоб отримувати й перевіряти листи, які надсилає ваш власний застосунок. Використовуйте тимчасову поштову скриньку для ручних перевірок реєстрації та OTP без чутливих даних. Обирайте корпоративну поштову скриньку, якщо потрібно зберігати повідомлення, відповіді чи вкладення, а SMTP-пісочницю або API хостингової скриньки — коли автоматизовані тести мають перевіряти пошту без участі людини.

Тмайлор веде цей блог, тож ось де він підходить. Tmailor — це безкоштовний, тимчасовий сервіс тимчасової пошти лише для прийому на вебі, Android, iOS та боті Telegram. Це підходить для першої справи: людина відкриває скриньку вхідних, запускає реєстрацію і читає те, що надходить. У останньому випадку окремий Tmailor Temp Mail API дозволяє автоматизованим тестам створювати адреси лише для прийому та читати їхні повідомлення з коду. Повідомлення зберігаються близько 24 годин від надходження, вкладення не приймаються, а з адреси не можна надіслати лист чи відповісти. Якщо ви новачок у тимчасових поштових скриньках, почніть з того, як працює тимчасова пошта.

• Лист не повинен надходити (валідація форм, фікстури, юніт-тести): використовуйте зарезервований домен для прикладів.
• Людина читає лист, і нічого в ньому немає чутливого: тимчасова скринька — найшвидший варіант.
• Чутливі дані, відповіді, вкладення або докази, які потрібно зберігати: використовуйте затверджену поштову скриньку під контролем компанії; додавайте plus-теги, лише якщо ваша поштова система та застосунок їх підтримують.
• Ніхто не спостерігає: використовуйте SMTP-catcher, якщо ви контролюєте налаштування вихідної пошти застосунку, або API хостингової скриньки, якщо застосунок має надсилати через свого звичайного провайдера.

Ручне та автоматизоване тестування пошти: дерево рішень

Чотири питання визначають, який тестовий email-акаунт потрібен для перевірки: чи лист має взагалі надходити, чи читає його людина або код, чи містить він чутливі дані та чи контролюєте ви, куди застосунок надсилає вихідну пошту.

1. Чи потрібно, щоб під час тесту надійшов лист? Перевірки формату, стани UI, фікстури та юніт-тести зазвичай цього не потребують. Використовуйте адреси на example.com, example.org або example.net. Ці домени зарезервовані для документації та прикладів, тож нічого не потрапляє до реальної людини. Уникайте вигадування випадкових доменів, бо хтось може ними володіти.
2. Чи читатиме людина повідомлення під час тесту? Димові тести, ручний UAT, демонстрації та дослідницькі сесії передбачають участь людини. Регресійні набори та завдання CI зазвичай ні.
3. Якщо лист читає людина, чи є в ньому щось чутливе? Справжні записи клієнтів, облікові дані, регульовані дані або повідомлення, які потрібно зберігати як докази для аудиту, не повинні потрапляти до тимчасової скриньки. Натомість використовуйте корпоративну поштову скриньку. Якщо відповідь — ні, тимчасової скриньки достатньо.
4. Якщо лист читає код, чи може тестове середовище надсилати свою пошту на тестовий SMTP-сервер? Якщо так, SMTP-catcher перехоплює кожне повідомлення, не доставляючи його. Якщо ні, бо застосунок має надсилати через свого звичайного поштового провайдера, використовуйте хостингову скриньку, яку ваші тести читають через API.

Таблиця порівнює п'ять варіантів поруч.

Які адреси має приймати або відхиляти поле електронної пошти?

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

Коли достатньо тимчасової скриньки

Тимчасова скринька підходить, коли людина перевіряє один сценарій за раз і в повідомленні немає нічого, що вам було б шкода втратити за добу. Це класичне застосування тимчасової електронної пошти для QA: вам потрібна електронна адреса для ручного тестування форми, а не довготривалий обліковий запис. Типові випадки — передрелізний димовий тест форми реєстрації, ручний прохід UAT для нового листа онбордингу, демонстрація створення облікового запису для клієнта або дослідницька сесія, де ви пробуєте дивні введення й спостерігаєте, що надсилає застосунок.

Приваблює швидкість. Не треба запитувати обліковий запис в ІТ і не треба чистити спільну скриньку. Ціною є контроль: ви отримуєте коротке вікно для повідомлень, без вкладень і скриньку, яку читає людина, а не код.

Коли вам потрібен 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 документує, що plus-адресація в Exchange Online увімкнена за замовчуванням, якщо адміністратор її не вимкнув.

Використовуйте цей шлях, коли процес містить реальні дані клієнтів, триває довше за добу, потребує відповідей або вкладень чи створює докази, які може запросити аудитор. Пам'ятайте про обмеження. Теги — це варіанти однієї скриньки, а не окремі вхідні скриньки, тож паралельні тести можуть читати повідомлення одне одного. Деякі форми реєстрації відхиляють знак плюс, а деякі застосунки вважають варіанти з тегами одним і тим самим акаунтом. Обидві ці поведінки варті окремого тест-кейсу.

Як провести ручний тест реєстрації з тимчасовою вхідною скринькою

Ручний тест реєстрації, що використовує тимчасову електронну пошту для тестування, потребує трьох речей: свіжої адреси, збірки, яку ви тестуєте, і місця поза вхідною скринькою для запису того, що надійшло. Запускайте його лише проти систем, якими володієте або які маєте дозвіл тестувати.

1. Відкрийте вхідну скриньку. Створіть безкоштовну тимчасову вхідну у вебі або скористайтеся застосунком Tmailor чи ботом у Telegram і скопіюйте адресу. На десктопі розширення браузера Tmailor також може вписати її в поле електронної пошти вашої тестової збірки.
2. Зареєструйтеся у своїй тестовій збірці. Використайте адресу у своєму середовищі staging або QA і запишіть час подання форми.
3. Дочекайтеся листа. Перевірте, яке повідомлення надійшло, ім'я відправника й адресу From, тему та скільки часу це зайняло.
4. Завершіть крок. Натисніть посилання або введіть код. Переконайтеся, що акаунт змінює стан лише один раз і що повторне використання того самого посилання завершується невдачею з чітким повідомленням.
5. Запишіть докази в іншому місці. Скопіюйте посилання, код, часові позначки та скріншот у свій тест-кейс. Повідомлення зберігаються приблизно 24 години від моменту надходження, тож вхідна скринька не є вашим тестовим записом.
6. Збережіть access token, якщо будете тестувати повторно. Токен знову відкриває ту саму адресу пізніше, наприклад, щоб повторити скидання пароля. Він не відновлює повідомлення, які вже минули, а втрачений токен відновити неможливо.

Коли в сесії потрібно одночасно кілька персон, наприклад безкоштовний користувач, користувач пробного періоду й запрошений колега, перегляд кількох вхідних скриньок показує до п'яти адрес поруч в одній вкладці браузера. Кожна персона має власну адресу, тож ви бачите, який лист належить якому акаунту.

Цей перегляд усе ще ручний. Вхідні скриньки створює людина в браузері, а не код, тож він не замінює хостинговий API вхідних скриньок для паралельних запусків без нагляду.

Одна вхідна скринька чи одна адреса на тест?

Однієї спільної скриньки достатньо для швидкої перевірки, але шум накопичується дуже швидко. Щойно кілька тестів запускаються одночасно, схожі теми листів ускладнюють розуміння того, який лист належить якому скрипту, і налагодження перетворюється на здогадки.

Одна адреса на тестовий випадок вирішує цю проблему. Журнали, скріншоти та листи збігаються, а відсутнє повідомлення вказує на один сценарій, а не на всі. Посібник з керування кількома тимчасовими поштовими скриньками детальніше описує цей робочий процес.

Деякі сценарії потребують тієї самої адреси знову через кілька днів, наприклад пробний період, що переходить у платний тариф, або користувач, який повертається після відмови від сервісу. Багаторазова тимчасова поштова адреса зберігає адресу доступною через її Access Token, але не саму пошту. Зберігайте потрібні посилання та коди під час кожного кроку, а будь-який крок, що залежить від старіших повідомлень, перенесіть у корпоративну скриньку. Якщо тестувальник увійде в безкоштовний акаунт Tmailor перед створенням персональних адрес, кожна з них збережеться в розділі «Створені листи», тож втрачений токен більше не означатиме втрачену адресу.

Що перевіряти в листах реєстрації та онбордингу

Почніть з інвентаризації всіх листів, які може надіслати цей шлях, а потім вирішіть, що має перевіряти кожен тест. Команди часто виявляють додаткові листи лише тоді, коли вони з’являються посеред тестування — після експерименту зі зростання або зміни в безпеці, яку ніхто не задокументував.

Листи в типовому шляху реєстрації

• Посилання для верифікації або одноразовий код
• Вітальний лист і будь-яка серія листів для швидкого старту
• Вхід за магічним посиланням
• Скидання пароля
• Зміна електронної адреси, надіслана на стару та нову адреси
• Сповіщення про безпеку щодо нового пристрою або нового місцезнаходження
• Нагадування про реєстрації, які так і не було завершено

Для кожного з них запишіть тригер, очікуваний час і умови, що його змінюють, як-от тариф, регіон або мова. Встановіть дозволене вікно доставки на основі задокументованої вимоги вашого продукту, а не припускайте універсальний поріг; негайний лист для верифікації та запланована серія вітальних листів потребують різних очікувань. Коли ці очікування визначено, кожен тест має щось конкретне для перевірки.

Що перевіряти в кожному тестовому листі

• Відправник і отримувач: ім'я та адреса відправника, 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-сервер дозволяє AI-агентам, як-от Claude, Cursor або VS Code Copilot, робити те саме для потоків реєстрації, якими ви володієте або які вам дозволено тестувати.

Кілька звичок допомагають зберігати стабільність тестів електронної пошти без нагляду, який би інструмент ви не обрали:

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

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

Зберігайте тестові дані в безпеці та дотримуйтеся правил

Використовуйте синтетичні ідентичності та нечутливий вміст у тимчасових тестових скриньках, а тести реєстрації проводьте лише на системах, якими ви володієте або які вам дозволено оцінювати. Тримайте QA-акаунти поза виробничою аналітикою, дотримуйтеся обмежень частоти запитів, а регульовані дані, облікові дані, вкладення та збережені докази переносьте до затверджених систем під контролем компанії.

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

Коли служба безпеки запитує, як провайдер обробляє дані, подивіться, що він збирає, як довго зберігає повідомлення і як працює доступ. Цей огляд тимчасової пошти та онлайн-приватності розкриває ці питання з боку користувача. Рішення про те, які потоки можуть використовувати тимчасові скриньки, все одно належить вашим командам з юридичних питань, приватності та безпеки.

Обмеження, які варто врахувати

Веб-скринька Tmailor підходить для коротких ручних перевірок нечутливої вхідної пошти (для автоматизації призначений Temp Mail API). Перед вибором вирішіть, чи потребує робочий процес вихідних дій, вкладень, довготривалих доказів або тривалого відновлення адреси. Будь-яка з цих вимог вимагає скриньки під контролем компанії або спеціалізованого інструменту для тестування; наведений нижче контрольний список пояснює чому.

• Тмайлор доступний лише для прийому. Він може перевіряти вхідну реєстрацію, верифікацію та OTP-пошту, але не потік відповідей чи щось, що надсилається з цієї адреси.
• Tmailor не отримує вкладень, тому листи з рахунками, контрактами чи доставкою документів потребують корпоративної скриньки або інструменту для тестування.
• Повідомлення зберігаються приблизно 24 години після надходження. Експортуйте посилання, коди та часові позначки, які знадобляться для тривалішого розслідування.
• Access Token знову відкриває адресу, але не прострочені повідомлення, а втрачений токен відновити неможливо.
• Веб-скриньку читає людина. Для читання скриньки без нагляду потрібен SMTP-catcher або хостований API скриньки, наприклад Tmailor Temp Mail API.
• Деякі сервіси блокують домени тимчасової пошти. Якщо потік, який ви тестуєте, робить це навмисно, перевірте його з реальною адресою або адресою, контрольованою компанією.

Як обрати правильну тестову скриньку

Обирайте скриньку відповідно до того, що має довести тест. Використовуйте зарезервований приклад домену, коли доставка не потрібна, тимчасову скриньку для ручних нечутливих перевірок, корпоративну скриньку для збережуваних або конфіденційних сценаріїв, SMTP-catcher, коли ви контролюєте вихідні налаштування, і хостований API скриньки для наскрізних тестів без нагляду.

Для ручних випадків кейсів відкрийте тимчасову вхідну скриньку і почніть із потоку реєстрації, який ви випускаєте наступним. Тимчасова пошта має чимало практичних застосувань поза QA.