Навіщо тестувальникам одноразова скринька
Майже кожен застосунок надсилає листи: підтвердження замовлень, одноразові коди, рахунки, бронювання, нагадування та сповіщення. Ці листи — частина продукту, і ламаються вони частіше, ніж здається. Посилання веде на тестове середовище. Код приходить, коли вже прострочений. Відправником значиться сира назва сервера на кшталт ip-10-0-3-17.internal. Ніхто цього не помічає, доки не поскаржиться справжній клієнт.
Тестувати на власному Gmail незручно. Закінчуються аліаси з «+», скринька засмічується тестовими листами, а адресу не передаси колезі по команді. Одноразова скринька це вирішує: відкриваєте сторінку, копіюєте адресу, вводите її в застосунку й дивитеся, як лист приходить у реальному часі. Коли закінчите, нічого робити не треба. Усе видаляється само через 7 днів.
Це справжня скринька на справжньому домені, тож застосунок надсилає лист звичайним SMTP, так само як клієнтові. Ви тестуєте весь шлях — від коду через сервіс розсилки й DNS до доставки, а не мок.
Як перевірити листи застосунку менш ніж за хвилину
- Скопіюйте адресу вгорі цієї сторінки.
- Введіть її в застосунку (локально, на staging чи в продакшені) там, де надсилається лист: реєстрація, замовлення, бронювання, оплата, сповіщення.
- Стежте за скринькою. Лист з’являється без оновлення сторінки, зазвичай за кілька секунд.
- Перевірте лист: відправника, тему, текст, кожне посилання й кожен код.
- Перейдіть за посиланнями або введіть код, щоб пройти весь сценарій і переконатися, що кожен крок працює.
Приклад: тест купівлі тарифу з eSIM перед релізом
Припустімо, ви QA-інженер у мобільного оператора, і реліз наступного тижня змінює те, як клієнти купують тариф онлайн. Клієнт обирає тариф, вводить email, оплачує, а далі майже все відбувається через листи. Кожен із них має бути правильним із першого дня, бо хибне посилання означає клієнта, який не може активувати свою eSIM.
З одноразовою скринькою ви пройдете весь шлях як новий клієнт, на тестовому середовищі, ще до виходу в продакшен:
- Купіть тариф на тестовому середовищі з адресою з цієї сторінки.
- Підтвердьте email кодом із листа.
- Перевірте підтвердження замовлення: правильну назву тарифу, ціну на місяць у гривнях і номер замовлення.
- Перевірте лист про оплату карткою, Apple Pay чи Google Pay: чи збігається сума із замовленням?
- Перевірте лист з eSIM: QR-код відображається, має альтернативний текст, а посилання для активації веде на продакшен, а не на тестовий сервер.
- Повторіть для кожного типу тарифу (передплата, контракт, сімейний) у новій вкладці, щоб у кожного тестового клієнта була своя скринька.
Так само це працює в будь-якій галузі, де після дії клієнта приходять листи: банки, страхування, інтернет-магазини з доставкою, бронювання подорожей чи пробні періоди SaaS. Перевірте кожен лист, який отримає клієнт, до релізу, а не після першої скарги.
Баги, які ви знайдете раніше за користувачів
- Тестові посилання в продакшен-листах. Базовий URL, скопійований не з того середовища. Дуже поширено й непомітно, доки хтось не натисне.
- Коди, що спливають надто швидко. Лист іде 40 секунд, а код дійсний 30.
- Зламані шаблони. Змінна на кшталт
{{first_name}}, яка не підставилася, або порожня тема. - Немає автентифікації відправника. Якщо ваші листи потрапляють у спам, перевірте SPF, DKIM і DMARC. Пояснення — у статті SPF, DKIM і DMARC простими словами.
- Не та мова чи формат. Український клієнт отримує англійський шаблон, або дата й сума в неправильному форматі (23.10.2026, 249,99 грн).
Тестування з кількома користувачами одночасно
Запрошення, ролі в команді та погодження потребують більше ніж однієї людини. Відкрийте цю сторінку в новій вкладці або приватному вікні, і ви отримаєте зовсім окрему скриньку. Одна вкладка на тестового користувача — найшвидший спосіб: запросіть користувача B з акаунта A, прийміть запрошення в скриньці B і перевірте, що побачить A. Докладніше — у статті тестування з кількома користувачами для QA.
Коли не варто використовувати одноразову скриньку
Одноразові скриньки — для тестування. Будь-хто з посиланням на скриньку може її читати, а все видаляється через 7 днів. Тож не використовуйте її для адмін-акаунтів у продакшені, нічого, пов’язаного з платежами, чи акаунтів, які згодом доведеться відновлювати. Для цього потрібна справжня скринька, якою керує ваша команда.
І не вводьте адреси справжніх клієнтів на тестових середовищах: окрім ризику надіслати клієнтові тестовий лист, це ще й питання захисту персональних даних — і за законом України «Про захист персональних даних», і за GDPR, якщо ви працюєте з клієнтами з ЄС. Тестова адреса знімає це питання.
Часті запитання
- Це справжня скринька чи мок?
- Справжня скринька на справжньому домені. Застосунок надсилає звичайним SMTP, як і клієнтові, тож ви тестуєте весь шлях: код, сервіс розсилки, DNS і доставку.
- HTML-листи відображаються?
- Так. HTML-листи показуються так, як їх побачать ваші користувачі.
- Скільки зберігаються тестові листи?
- Кожен лист автоматично видаляється через 7 днів після надходження, а скринька спливає через 7 днів після створення. Ви також можете будь-коли видалити все самі.
- Чи можна тестувати з кількома користувачами одночасно?
- Так. Відкрийте сторінку в новій вкладці браузера (або приватному вікні), і ви отримаєте окрему скриньку. Одна вкладка на тестового користувача добре підходить для запрошень, ролей і погоджень.
- Чому мій тестовий лист не прийшов?
- Спершу перевірте, чи немає помилки в адресі. Деякі сервіси блокують відомі одноразові домени, а деякі поштові провайдери затримують перший лист від нового відправника на хвилину-дві. Якщо надсилає ваш застосунок, подивіться його логи й панель сервісу розсилки.
- Чи можна використовувати це для продакшен-акаунтів?
- Ні. Будь-хто з посиланням може читати скриньку, і вона спливає через 7 днів. Використовуйте її для тестування, а не для акаунтів, які доведеться відновлювати.