Blog

Tips, guides, and privacy advice

← Back to Blog
Поради розробникам

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

24 липня 2026 р.·11 min read

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

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

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

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

Чому ви ніколи їх не знаходите: ви не можете бути новим

Ось неприємна частина. Навіть коли ви вже знаєте про такий баг, відтворити його незручно — бо вам непросто стати новим користувачем. Ваша адреса вже є в таблиці користувачів. А ще вона — запис клієнта в платіжного провайдера, контакт у маркетинговому інструменті, рядок в аналітиці й учасник двох когорт feature-flag, про які ви вже забули. Ваш браузер несе сеанс, збережену картку й закриту підказку онбордингу з минулого кварталу.

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

Щоб справді бути новим, потрібні дві речі одночасно: особа, якої система ще ніколи не бачила, і браузер, який ще ніколи не бачив системи. На обидві — приблизно хвилина підготовки. Пропустите будь-яку — і прогін нічого вам не скаже.

Готуємо сцену

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

  • Чистий профіль браузера, а не лише приватне вікно. Режим інкогніто розв’язує питання cookie, але окремий профіль ще й означає відсутність розширень і автозаповнення картки — і те, і те непомітно змінює поведінку checkout.
  • Адреса, якої цей продукт ще не бачив, щоб ви створили запис, а не наштовхнулися на наявний.
  • Нова платіжна особа теж. Повторно використовувати тестового клієнта — означає повторно використовувати його збережені картки й історію рахунків, а саме такого стану в покупця, що платить уперше, немає.
  • Інше ім’я та компанія. Дані, що виглядають як тестові, проходять іншу валідацію, ніж дані, що виглядають як справжня людина.
  • Staging, підключений до платіжного провайдера в тестовому режимі. Ніколи не продакшен, ніколи не справжня картка.
Перш ніж почати, додайте URL скриньки в закладки. Адреса живе за власним посиланням, тож можна закрити вкладку, провести двадцять хвилин у checkout і повернутися до тієї самої скриньки — це важливо, коли квитанція приходить набагато пізніше за лист реєстрації.

Крок 1: зареєструйтеся й справді прочитайте лист

Вставте адресу й надішліть форму. Лист має надійти за кілька секунд — якщо це займає тридцять, запишіть, бо користувач, що пів хвилини дивиться на екран «перевірте пошту», починає у вас сумніватися. Потім прочитайте лист як слід, а не просто шукайте кнопку:

  • Час доставки. Виміряйте його. Саме ця метрика деградує під навантаженням, і ніхто цього не помічає до дня запуску.
  • Від кого лист. Зрозуміла людині назва бренду чи no-reply-адреса? Відповідь дійде до людини чи зникне?
  • Посилання, клікнуте двічі. Раз — щоб підтвердити. Ще раз — щоб переконатися, що токен одноразовий і друга спроба ввічливо не вдається, а не кидає 500.
  • Строк дії. Залиште одне посилання невикористаним довше за строк його дії й перевірте, що його відхилено з повідомленням, як отримати нове.
  • Регістр. Зареєструйтеся знову з іншими великими й малими літерами. Домен за RFC 5321 не залежить від регістру, і майже кожен продукт так само поводиться з локальною частиною, тож другого акаунта тут бути не повинно.
  • Непідтверджений стан — саме той, що з історії на початку. Перш ніж щось клікати, подивіться, що застосунок уже дозволяє робити. Чи можна запросити колег? Чи можна заплатити? Іноді це зроблено свідомо. А іноді це тікет у понеділок зранку, який тільки чекає своєї години.

Якщо вас найбільше турбує саме підтвердження, воно заслуговує на окремий сеанс — ми докладніше розібрали токени й граничні випадки в статті як розробники тестують підтвердження email.

Крок 2: тиха ділянка до того, як рухаються гроші

Між підтвердженням і оплатою є невеличка група автоматичних листів — вітальний, нагадування онбордингу, «завершіть налаштування акаунта». У більшості продуктів це найменш протестовані листи, бо їх надсилають фонові задачі, а не кнопка, яку хтось клікає під час тесту.

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

Крок 3: оплата — завжди в пісочниці

Тепер частина, яку люди обходять навшпиньки, бо платежі страшно чіпати. Небезпечні вони лише в неправильному середовищі. Кожен серйозний провайдер має пісочницю саме для цього: Stripe публікує повний набір тестових карток, а PayPal надає sandbox-акаунти, які поводяться як справжні, не рухаючи ні копійки.

Користуйтеся ними. Ніколи не вводьте справжній номер картки в тестовому середовищі — ні свій, ні тим паче колеги чи клієнта. Справжні дані картки затягують будь-яку машину, на якій ви працюєте, у сферу дії PCI DSS, а staging-серверу там точно не місце. Тестові номери існують саме для того, щоб тут не доводилося нічого зважувати.

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

  • Чистий успіх. Платіж схвалено, тариф справді активовано, користувач потрапляє кудись змістовно, а не на порожній дашборд.
  • Звичайна відмова. Чи отримує користувач зрозуміле пояснення й чи зберігаються дані форми — чи бачить stack trace і порожній кошик?
  • Недостатньо коштів. Це не те саме, що загальна відмова, і заслуговує на окреме формулювання.
  • Перевірка 3-D Secure. Посилена автентифікація клієнта обов’язкова на багатьох ринках. Пройдіть її один раз — а потім запустіть знову й покиньте на півдорозі. Покинута перевірка не має залишати по собі напівстворену підписку.
  • Прострочена картка й неправильний CVC. Два шляхи помилки, які обожнюють зливатися в одне некорисне повідомлення.
  • Подвійне надсилання. Клікніть «Оплатити» двічі, швидко. Одне списання, а не два. Якщо цей баг прослизне, він буде найдорожчим у цьому списку.
  • Кнопка «Назад». Оплатіть, поверніться назад, надішліть знову. Те саме запитання, інші двері.
  • Валюта й податки. Якщо для різних регіонів у вас різні ціни, проведіть два прогони. Податок розраховується в одному місці, а показується в трьох, і ці три розходяться.

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

  • 4242 4242 4242 4242 — чистий успіх. Ваша базова точка.
  • 4000 0000 0000 0002 — загальна відмова.
  • 4000 0000 0000 9995 — недостатньо коштів; для користувача це має звучати інакше, ніж загальна відмова.
  • 4000 0000 0000 0069 — прострочена картка.
  • 4000 0000 0000 0127 — неправильний CVC.
  • 4000 0025 0000 3155 — примусово викликає перевірку 3-D Secure. Проведіть двічі: раз до кінця, раз покиньте на півдорозі.

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

Спершу проганяйте сценарії з помилками. Коли тестовий користувач уже щасливо підписаний, повернути його в чистий стан до оплати морочливо — а нова скринька й свіжий профіль повертають вас на стартову лінію за секунди.

Крок 4: квитанція — частина продукту

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

  • Сума збігається зі сторінкою checkout. Очевидно, але неправда частіше, ніж хотілося б, щойно в гру вступають знижки, пропорційні нарахування й конвертація валют.
  • Податок правильно виокремлено для регіону, який ви тестували.
  • Назва тарифу — та, що бачить клієнт, а не plan_pro_v2_2024.
  • Номер рахунку, дата й реквізити компанії на місці й зрозумілі людині.
  • PDF чи посилання на онлайн-рахунок відкривається для того, хто не ввійшов у систему. У бухгалтера, якому переслали лист, акаунта немає.
  • Кожне посилання веде в публічне місце. Staging із неабияким ентузіазмом протягує в листи URL на localhost.

Крок 5: продовження й невдалі платежі — без очікування місяця

Баги підписок ховаються в майбутньому, тому вони й живуть так довго. Списання за продовження, попередження про закінчення строку дії картки, серія нагадувань про борг (dunning), фінальне повідомлення про скасування — усе це відбувається через тижні після релізу, коли вже ніхто не дивиться в скриньку.

Чекати не обов’язково. Test clocks у Stripe за секунди проганяють тестового клієнта крізь білінгові цикли, і в більшості провайдерів є аналог. Спрямуйте це на одноразову скриньку, і рік білінгового листування надійде за кілька хвилин:

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

Крок 6: скасуйте, а потім поверніть кошти

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

Перевірка, яку варто проводити для кожного листа

Хоч що його надіслало, кожен лист проходить той самий швидкий огляд. Коли це стане звичкою — лічені секунди:

  • Він надійшов, і у «Вхідні», а не був тихо відкинутий.
  • Ніщо не відображається як сирий плейсхолдер. Непідставлений токен у привітанні — найганебніший баг у цій статті, і його випускають постійно.
  • Текстова версія існує й читається нормально. Чимало клієнтів і скрінрідерів використовують її замість HTML.
  • Посилання абсолютні й публічні.
  • Маркетингові листи мають робоче посилання для відписки, зокрема заголовок відписки в один клік з RFC 8058, який тепер фактично обов’язковий для масових відправників згідно з вимогами Google до відправників. Транзакційні квитанції — не повинні.
  • Автентифікацію пройдено. Якщо тестові листи доходять погано, з’ясуйте це зараз — у статті чому транзакційні листи потрапляють у спам розібрано причини.

Чому одноразова скринька пасує цьому циклу

Усе це працює тому, що скринька одноразова, але не марно короткоживуча. Листи надходять у реальному часі, тож ви бачите кожен у ту ж мить, коли система його надсилає, і причина й наслідок лишаються очевидними. Адреса живе 7 днів — цього з запасом вистачає на реєстрацію, checkout, обхід через 3-D Secure і прискорений білінговий цикл, тоді як десятихвилинна скринька зазвичай зникає саме тоді, коли от-от має прийти квитанція.

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

Що це насправді ловить

Такий прогін стабільно виявляє одну конкретну родину дефектів — тих, що живуть між системами, а не всередині них:

  • Квитанції, які ніколи не надсилаються, бо подальшій задачі потрібне поле, яке встановлює не пов’язаний із нею крок. (Привіт, понеділку.)
  • Подвійні списання через один нетерплячий повторний клік.
  • Вітальні листи, що надходять двічі або жодного разу для тих, хто платить до підтвердження.
  • Платіж проходить, а тариф тихо не активується, і клієнт, що платить, лишається на безкоштовному тарифі.
  • Покинуті перевірки 3-D Secure, після яких лишаються осиротілі напівпідписки.
  • URL staging-середовища в листах, які були за один прапорець конфігурації від того, щоб потрапити до клієнтів.
  • Серії нагадувань про борг, що досі переслідують когось, хто вже заплатив.

Одне застереження, прямо

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

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

Зробіть це ритуалом, а не подвигом

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

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