Запитайте будь-якого QA-інженера, де ховаються найнеприємніші баги, і почуєте те саме: не в щасливому сценарії для одного користувача, а в проміжку між користувачами. Двоє людей реєструються в ту саму мить. Лист-запрошення йде не тій людині. Адміністратор і учасник із правами лише на читання відкривають ту саму сторінку, і один із них бачить те, чого не мав би бачити. Ніщо з цього не відтворюється, коли ви тестуєте самі зі своєю адресою, бо в базі даних ви завжди лише один користувач.
Справжні продукти за своєю природою розраховані на багатьох користувачів — команди, робочі простори, ролі, запрошення, реферальні програми, тенанти. Щоб чесно протестувати ці сценарії, потрібно кілька окремих робочих скриньок одночасно. Саме тут тимчасова пошта непомітно стає одним із найкорисніших інструментів тестувальника, і цей сценарій не має нічого спільного з тим, щоб ховатися від спаму.
Чому однієї справжньої скриньки (чи спільного QA-акаунта Gmail) замало
Проблема з вашою власною адресою проста: вона вже є в системі. Ви не можете зімітувати «зовсім нового користувача, якого ще ніхто не бачив», коли ваш запис уже є в базі, і вже точно не можете бути трьома новими користувачами одночасно. Команди часто беруть спільний QA-акаунт Gmail і користуються plus-адресацією — [email protected], [email protected] і так далі. Це працює, поки не перестає: чимало застосунків обрізають або нормалізують тег +, деякі відхиляють його взагалі, і навіть коли його приймають, усі листи однаково потрапляють в одну скриньку, де потім доводиться розплутувати, який «користувач» що отримав.
Для справжнього тестування з кількома користувачами потрібні скриньки, які справді окремі — окремі адреси, окремі поштові скриньки, жодного спільного стану. Саме це ви й отримуєте, відкривши кілька вкладок.
Яке місце одноразова пошта займає в QA
Кожна вкладка тимчасової пошти — це повністю незалежна скринька з власною унікальною адресою. Відкрийте три вкладки, і у вас три справжні користувачі, яким можна надсилати листи й від яких можна їх отримувати — без створення акаунтів, без спільної скриньки, яку потім треба чистити, а оскільки кожна адреса згенерована щойно, жоден залишковий стан від учорашнього прогону не спотворює сьогоднішніх результатів. Коли ви закінчите, усе автоматично видаляється через 7 днів, тож у вас не накопичується кладовище тестових акаунтів, прив’язаних до вашої особистої пошти.
Сценарії з кількома користувачами, які справді варто тестувати
Ось сценарії, де кілька живих скриньок поруч себе окуповуються — ті, що тихо ламаються в продакшені, бо до релізу ніхто не міг легко їх відтворити:
- Запрошення в команду та робочий простір: користувач A створює робочий простір і запрошує B і C. Кожне запрошення має дійти на правильну адресу з робочим, безпечно згенерованим посиланням, а прийняття запрошення має додати кожну людину до правильного робочого простору з правильною роллю. Стежте за всіма трьома скриньками одночасно, і неправильно спрямоване запрошення ви помітите миттєво.
- Ролі та права доступу: зареєструйте власника, адміністратора й учасника з правами лише на читання як трьох окремих користувачів. Потім переконайтеся, що кожен бачить — і не бачить — саме те, що дозволяє його роль. Баги з правами доступу непомітні, доки ви справді не ввійдете як користувач із меншими правами, бажано одночасно з користувачем із більшими. OWASP Authorization Cheat Sheet — добрий чек-лист того, що тут перевіряти.
- Обробка дублікатів акаунтів: зареєструйте два акаунти з різними адресами, а потім спробуйте використати одну з них повторно. Чи виявляє застосунок дублікат так, як ви очікуєте? А якщо та сама адреса в іншому регістрі або з зайвою крапкою в кінці? Зі свіжими адресами такі граничні випадки налаштовуються елементарно.
- Реферальні програми та бонуси за запрошення: того, хто запросив, зазвичай винагороджують лише після того, як запрошений зареєструється й підтвердить адресу. Потрібні дві справжні скриньки, щоб побачити обидві сторони — як іде запрошення і як надходить винагорода (або, як і належить, не надходить), коли другий користувач завершить процес.
- Ізоляція тенантів: створіть акаунти у двох різних організаціях і переконайтеся, що дані одного тенанта ніколи не просочуються в екрани, сповіщення чи листи іншого — саме такий збій окремо згадують рекомендації NIST щодо мультитенантності в хмарі. Чужа адреса не в тій скриньці часто стає першою помітною ознакою бага з ізоляцією даних.
- Одночасні реєстрації: зареєструйте кількох користувачів у межах однієї секунди, щоб виявити стани гонитви під час генерації токенів, конфлікти унікальних обмежень і затримки черг, через які одні листи підтвердження приходять набагато пізніше за інші.
- Ліміти місць і тарифів: заповніть тариф окремими користувачами до межі кількості місць, а потім спробуйте додати ще одного. Ліміт має втриматися — а помилка, яку побачить зайвий користувач, має бути зрозумілою, а не 500.
- Розсилка сповіщень: виконайте дію в одному акаунті й переконайтеся, що лист-сповіщення отримали потрібні колеги — і лише вони. Легко випадково надіслати лист усім або нікому.
Робочий процес, який не дає заплутатися
Практичний прийом — сприймати кожну вкладку як окремого персонажа вашого тесту. Відкрийте вкладку на кожного користувача й заздалегідь вирішіть, хто є хто — Owner, Admin, Member, — а потім скопіюйте кожну адресу в окрему реєстрацію. Розташуйте вкладки так, щоб бачити їх одним поглядом. Оскільки доставка фактично миттєва, ви побачите запрошення в ту ж мить, коли його надішлете, і причина й наслідок стануть очевидними так, як ніколи не бувають під час опитування спільної скриньки.
Запишіть поруч із кроками тесту, яка випадкова адреса відповідає якій ролі — адреси генеруються, а не обираються, тож коротка нотатка позбавить плутанини згодом. А виграш такий: щойно лист з’являється не в тій вкладці, ви на місці ловите баг маршрутизації чи ізоляції, задовго до того, як він перетвориться на звернення в підтримку.
Що перевірити, коли лист надійшов
Отримати лист — це лише половина справи. Коли повідомлення надійшло, приділіть кілька секунд, щоб справді його перевірити:
- Правильний одержувач: чи надійшло запрошення на запрошену адресу — і більше нікуди?
- Правильне посилання: чи веде URL для прийняття або підтвердження на правильне середовище й чи містить правильний контекст робочого простору та ролі, а не жорстко прописане посилання на продакшен?
- Правильний підсумковий стан: після прийняття запрошення чи опинився новий користувач у правильній організації саме з тими правами, які має давати його роль?
- Відображення: чи правильно виглядає лист у справжній скриньці — кнопки клікабельні, ім’я одержувача підставлено, немає забутого шаблону «Hi {{firstName}}»?
- Ізоляція: чи не згадує лист одного користувача помилково дані іншого? Це тривожний сигнал, який варто дослідити до кінця.
- Час доставки: усе має надходити за кілька секунд. Постійна затримка вказує на проблему з чергою чи DNS, яку відчують і ваші справжні користувачі.
Чисті тестові дані безкоштовно
Одна недооцінена перевага: кожна нова одноразова адреса починається порожньою й сама видаляється через 7 днів, тож кожен прогін стартує з відомо чистого стану. Тест, що починається з «гарантовано порожньої скриньки й абсолютно нового користувача», — це тест, якому можна довіряти й який можна повторити, не гадаючи, чи не спотворюють результат залишки минулого тижня. Повторюваність — половина доброго QA, і тут ви отримуєте її без жодного прибирання.
Найкраще для дослідницького тестування та регресії перед релізом
Цей підхід справді розкривається під час дослідницького тестування та ручного регресійного прогону перед релізом. За кілька хвилин ви можете зібрати реалістичну невелику команду користувачів — власника, кількох учасників, зовнішнього запрошеного — і пройтися продуктом так, як це зробила б справжня команда, спостерігаючи, як надходять листи. Це найближче до того, щоб «користуватися застосунком як п’ять різних людей одночасно», не заводячи п’ять справжніх поштових скриньок. Якщо ви також тестуєте частини для одного користувача, до цього природно доповнюються наші посібники про тестування підтвердження email і тестування скидання пароля.
Де чесно визнати обмеження
Про кілька речей варто сказати прямо, бо вдавати інакше — лише марнувати ваш час. Деякі застосунки блокують відомі домени одноразової пошти під час реєстрації — якщо ваша форма реєстрації відхиляє адресу, це власна політика застосунку, і для таких тестів вам, можливо, знадобиться внутрішній домен із білого списку. Крім того, це ручний, дослідницький процес: ви керуєте браузером, а не викликаєте API, тож він доповнює автоматизовані наскрізні тести пошти в CI, а не замінює їх. І перед релізом зробіть фінальну перевірку зі справжньою скринькою на кшталт Gmail чи Outlook — особливості доставлюваності й поведінка папки «Спам» проявляються лише в справжніх поштових сервісах.
Коротко
Тестування з однією скринькою знаходить баги одного користувача. Ті, що справді доходять до продакшену, живуть у проміжках між користувачами — запрошеннях, ролях, тенантах, лімітах і станах гонитви. Одноразова пошта дає одному тестувальнику змогу зіграти цілу команду, з чистим станом на кожному прогоні, приблизно за той час, що потрібен, аби відкрити кілька вкладок. Перейдіть на temp-email.ai, відкрийте вкладку на кожного користувача й почніть тестувати сценарії, які справді важливі.