Уявіть тікет у підтримку з темою з чотирьох слів: заплатив, нічого не сталося, допоможіть. Він приходить о 8:52 у понеділок — найгірший момент, щоб почати дізнаватися щось про свій білінг. Якщо ви хоч якийсь час працювали над платним продуктом, якась версія цієї історії вам знайома.
Клієнт не робив нічого незвичайного. Зареєструвався в неділю ввечері, відволікся, не відкривши лист підтвердження, повернувся наступного ранку, пішов просто на сторінку з цінами й заплатив. Платіж пройшов. А далі — нічого: ні квитанції, ні підвищення тарифу, ні вітального листа. З погляду продукту це незавершена реєстрація, яка чомусь вам заплатила.
Усі тести зелені. Реєстрацію протестовано. Розсилку протестовано. Checkout протестовано ретельно, людьми, яким не байдуже. Баг живе в єдиному місці, яке нікому не належить: задача, що формує квитанцію, читає поле, яке заповнюється лише тоді, коли хтось клікає посилання підтвердження, а цей клієнт заплатив раніше, ніж клікнув. Для нього це абсолютно звичайна послідовність дій, а жоден тест у наборі її ніколи не виконував, бо кожен тест починається з уже підтвердженого користувача.
Ось у чому річ зі стиками. Команда реєстрації відповідає за реєстрацію. Команда білінгу — за білінг. А простір між ними належить тому, хто випадково ним пройде, — і якщо ніхто не робить цього свідомо, першим ним пройде клієнт, що платить, у понеділок зранку.
Чому ви ніколи їх не знаходите: ви не можете бути новим
Ось неприємна частина. Навіть коли ви вже знаєте про такий баг, відтворити його незручно — бо вам непросто стати новим користувачем. Ваша адреса вже є в таблиці користувачів. А ще вона — запис клієнта в платіжного провайдера, контакт у маркетинговому інструменті, рядок в аналітиці й учасник двох когорт feature-flag, про які ви вже забули. Ваш браузер несе сеанс, збережену картку й закриту підказку онбордингу з минулого кварталу.
Коли ви тестуєте реєстрацію зі своєю адресою, ви йдете шляхом, яким не пройде жоден реальний клієнт. Ви оминаєте саме ту ділянку, де вони застрягають, і ніколи не бачите порожнього стану, першої пропозиції апгрейду чи вітального листа, який тихо перестав надсилатися ще в березні.
Щоб справді бути новим, потрібні дві речі одночасно: особа, якої система ще ніколи не бачила, і браузер, який ще ніколи не бачив системи. На обидві — приблизно хвилина підготовки. Пропустите будь-яку — і прогін нічого вам не скаже.
Готуємо сцену
Скринька одноразової пошти закриває половину, що стосується особи: адреса, якої немає ніде у вашому стеку, готова за секунду й досі доступна, коли через двадцять хвилин надійде квитанція. Решта — просто дисципліна щодо стану:
- Чистий профіль браузера, а не лише приватне вікно. Режим інкогніто розв’язує питання cookie, але окремий профіль ще й означає відсутність розширень і автозаповнення картки — і те, і те непомітно змінює поведінку checkout.
- Адреса, якої цей продукт ще не бачив, щоб ви створили запис, а не наштовхнулися на наявний.
- Нова платіжна особа теж. Повторно використовувати тестового клієнта — означає повторно використовувати його збережені картки й історію рахунків, а саме такого стану в покупця, що платить уперше, немає.
- Інше ім’я та компанія. Дані, що виглядають як тестові, проходять іншу валідацію, ніж дані, що виглядають як справжня людина.
- Staging, підключений до платіжного провайдера в тестовому режимі. Ніколи не продакшен, ніколи не справжня картка.
Крок 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-середовища в листах, які були за один прапорець конфігурації від того, щоб потрапити до клієнтів.
- Серії нагадувань про борг, що досі переслідують когось, хто вже заплатив.
Одне застереження, прямо
Це техніка тестування ПЗ, за яке ви відповідаєте, у середовищі, яке ви контролюєте, з платіжною пісочницею. Це не спосіб накручувати безкоштовні пробні періоди, обходити платний доступ чи масово створювати акаунти в чужому сервісі. Це зловживання, саме через нього сервіси одноразової пошти потрапляють під блокування, і цей інструмент створено не для цього.
Обмеження діє й у протилежний бік: одноразова скринька свідомо тимчасова, тож ніколи не прив’язуйте її до акаунта, який вам потрібно зберегти. Якщо без скриньки ви не зможете його відновити, використайте справжню адресу. Якщо не впевнені, з якого боку цієї межі стоїте, прочитайте статтю аліас чи тимчасова адреса.
Зробіть це ритуалом, а не подвигом
Команди, які ловлять такі речі, — не ті, що мають найвитонченіші тест-плани. Це ті, хто проходить увесь шлях як незнайомець, перш ніж випустити щось важливе: нова скринька, чистий профіль, реєстрація, підтвердження, оплата тестовою карткою, прочитати кожен лист, скасувати, повернути кошти. Пів години, повністю вручну, і це раз у раз знаходить те, чого автоматизований набір структурно не може знайти, бо набір побудовано на тих самих припущеннях, що й код.
Внесіть це в календар — раз на два тижні або перед кожним релізом, що зачіпає реєстрацію чи білінг. Перший прогін майже завжди знаходить щось, чого ніхто не помічав, і тікет у понеділок зранку перестає бути тим, що з вами стається. Візьміть свіжу скриньку тимчасової пошти й пройдіть цей шлях.