Mandag morgen-sagen: at teste vejen fra tilmelding til betaling, som en rigtig bruger oplever den

Forestil dig en supportsag med en emnelinje på fire ord: betalt, intet skete, hjælp. Den lander 8:52 en mandag, hvilket er det værst tænkelige tidspunkt at begynde at lære nyt om sit betalingsflow. Har du arbejdet på et betalt produkt i nogen tid, vil en version af det her føles bekendt.

Kunden gjorde ikke noget usædvanligt. Tilmeldte sig søndag aften, blev afbrudt inden han nåede at åbne verificeringsmailen, kom tilbage næste morgen, gik direkte til prissiden og betalte. Betalingen gik igennem. Og så skete der ingenting — ingen kvittering, ingen planopgradering, ingen velkomstbesked. Set fra produktets side er det her en halvfærdig tilmelding, der tilfældigvis har betalt.

Alle test er grønne. Tilmeldingen er testet. Mailudsendelsen er testet. Betalingsflowet er testet grundigt, af folk der går op i det. Fejlen bor det ene sted, ingen ejer: jobbet, der genererer kvitteringen, læser et felt, som først bliver udfyldt, når nogen klikker på verificeringslinket, og denne kunde betalte, før han klikkede. En rækkefølge af hændelser, der er helt almindelig for ham, og som ingen test i suiten nogensinde har udført, fordi enhver test starter med en bruger, der allerede er verificeret.

Sådan er det med sømme. Tilmeldingsteamet ejer tilmeldingen. Faktureringsteamet ejer faktureringen. Rummet imellem tilhører den, der tilfældigvis går igennem det — og hvis ingen gør det bevidst, er den første, der går igennem, en betalende kunde en mandag morgen.

Derfor finder du dem aldrig: du kan ikke være ny

Her kommer den ubehagelige del. Selv når du kender til sådan en fejl, er den besværlig at genskabe — for du kan ikke bare være en ny bruger. Din mailadresse står allerede i brugertabellen. Den er også en kundepost hos betalingsudbyderen, en kontakt i marketingværktøjet, en række i analytics og medlem af to feature flag-kohorter, du har glemt alt om. Din browser slæber rundt på en session, et gemt kort og et bortklikket onboarding-tip fra sidste kvartal.

Når du tester tilmelding med din egen adresse, går du en vej, ingen rigtig kunde nogensinde kommer til at gå. Du springer præcis den strækning over, hvor de går i stå, og du ser aldrig den tomme tilstand, førstegangsopsalget eller velkomstmailen, der stille holdt op med at blive sendt i marts.

At være ægte ny kræver to ting på én gang: en identitet, systemet aldrig har set, og en browser, der aldrig har mødt systemet. Begge dele tager cirka et minut at sætte op. Springer du en af dem over, fortæller kørslen dig ingenting.

At sætte scenen

En indbakke med midlertidig e-mail klarer identitetshalvdelen — en adresse, der ikke findes nogen steder i din stak, klar på et sekund og stadig læsbar, når kvitteringen dukker op tyve minutter senere. Resten handler udelukkende om disciplin omkring tilstand:

• En ren browserprofil, ikke bare et privat vindue. Inkognito tager sig af cookies, men en separat profil betyder også ingen udvidelser og intet autoudfyldt kort — begge dele ændrer stille og roligt, hvad betalingsflowet gør.
• En adresse, som produktet aldrig har set, så du opretter en post i stedet for at kollidere med en eksisterende.
• En frisk betalingsidentitet også. At genbruge en testkunde betyder at genbruge deres gemte kort og fakturahistorik, hvilket er præcis den tilstand, en førstegangskøber ikke har.
• Et andet navn og en anden virksomhed. Data, der ligner testdata, udløser andre valideringer end data, der ligner et menneske.
• Staging, peget mod betalingsudbyderen i testtilstand. Aldrig produktion, aldrig et rigtigt kort.

Trin 1: Tilmeld dig, og læs faktisk mailen

Indsæt adressen og send. Beskeden bør lande inden for et par sekunder — tager det tredive, så skriv det ned, for en bruger, der stirrer på en "tjek din indbakke"-skærm i et halvt minut, er en bruger, der begynder at tvivle på dig. Læs den derefter ordentligt i stedet for bare at jagte knappen:

• Tid til ankomst. Mål den. Det er den måling, der forringes under belastning, og ingen opdager det før lanceringsdagen.
• Hvem den er fra. Et læsbart brand eller et no-reply-værtsnavn? Når et svar frem til et menneske, eller forsvinder det?
• Linket, klikket to gange. Én gang for at verificere. Én gang mere for at bekræfte, at tokenet kun kan bruges én gang, og at andet forsøg afvises pænt i stedet for at kaste en 500.
• Udløb. Lad ét ligge ubrugt ud over sin levetid, og tjek at det afvises med en besked, der forklarer, hvordan man får et nyt.
• Store og små bogstaver. Tilmeld dig igen med en anden skrivemåde. Domænet skelner ikke mellem store og små bogstaver ifølge RFC 5321, og stort set alle produkter behandler også den lokale del sådan, så det her må ikke oprette en konto nummer to.
• Den uverificerede tilstand — det er præcis den fra scenariet i indledningen. Før du klikker på noget, så se hvad appen allerede lader dig gøre. Kan du invitere kolleger? Kan du betale? Nogle gange er det bevidst. Nogle gange er det en mandag morgen-sag, der venter på at ske.

Hvis verificering er din hovedbekymring, fortjener den sin egen session — vi gik dybere med tokens og kanttilfælde i sådan tester udviklere e-mailverificering.

Trin 2: Den stille strækning, før der flyttes penge

Mellem verificering og betaling ligger en lille klynge automatiske beskeder — velkomst, onboarding-påmindelse, "gør din konto færdig". Det er de mindst testede mails i de fleste produkter, fordi det er baggrundsjobs, der sender dem, og ikke en knap, nogen klikker på under en test.

Lad indbakken stå åben, og hold øje. En dobbelt velkomstmail, en påmindelse der udløses halvfems sekunder efter tilmelding, eller en hilsen stilet til et navn, du aldrig har skrevet, er alt sammen rigtige fejl — og alle usynlige, medmindre et menneske læser postkassen.

Trin 3: Betalingstrinnet — altid i sandbox

Nu den del, folk lister uden om, fordi betalinger føles farlige at pille ved. De er kun farlige i det forkerte miljø. Enhver seriøs udbyder leverer en sandbox til præcis det: Stripe udgiver et komplet sæt testkort, og PayPal stiller sandbox-konti til rådighed, der opfører sig som de rigtige uden at flytte en øre.

Brug dem. Indtast aldrig et ægte kortnummer i et testmiljø — hverken dit eget og bestemt ikke en kollegas eller en kundes. Rigtige kortdata trækker den maskine, du sidder ved, ind i PCI DSS-omfanget, og en staging-maskine er det sidste sted, det hører hjemme. Testnumre findes, så det aldrig behøver at være et skøn.

Værdien ligger i at nægte at stoppe ved den lykkelige sti. Et betalingsflow, der kun virker, når alt går godt, er ikke rigtigt testet:

• En ren succes. Betaling godkendt, plan faktisk aktiveret, bruger lander et meningsfuldt sted i stedet for på et tomt dashboard.
• Et almindeligt afslag. Får brugeren en tydelig forklaring og beholder sine formulardata, eller et stack trace og en tom kurv?
• Manglende dækning. Noget andet end et generisk afslag, og det fortjener sin egen formulering.
• En 3-D Secure-udfordring. Stærk kundeautentificering er obligatorisk på mange markeder. Gennemfør den én gang — kør den så igen, og afbryd den halvvejs. En afbrudt udfordring må ikke efterlade et halvbygget abonnement.
• Udløbet kort og forkert CVC. To fejlveje, der elsker at falde sammen til én ubrugelig besked.
• Dobbeltklikket. Klik betal to gange, hurtigt. Én betaling, ikke to. Det her er den dyreste fejl på listen, hvis den slipper ud.
• Tilbageknappen. Betal, naviger tilbage, send igen. Samme spørgsmål, anden dør.
• Valuta og moms. Opkræver du regioner forskelligt, så kør to. Skatten beregnes ét sted og vises tre, og de tre driver fra hinanden.

Bruger du Stripe, dækker numrene nedenfor hele listen og sparer dig for at grave i dokumentationen midt i kørslen. Kombinér dem med en fremtidig udløbsdato og en vilkårlig trecifret CVC:

• 4242 4242 4242 4242 — den rene succes. Din baseline.
• 4000 0000 0000 0002 — et generisk afslag.
• 4000 0000 0000 9995 — manglende dækning, som bør læses anderledes for brugeren end et generisk afslag.
• 4000 0000 0000 0069 — udløbet kort.
• 4000 0000 0000 0127 — forkert CVC.
• 4000 0025 0000 3155 — fremtvinger en 3-D Secure-autentificering. Kør den to gange: én gang gennemført, én gang afbrudt halvvejs.

Andre udbydere udgiver tilsvarende sæt, så de samme seks scenarier rejser med — kun numrene ændrer sig. Det er værd at tjekke dem mod den aktuelle testdokumentation en gang imellem, for udbyderne reviderer dem.

Trin 4: Kvitteringen er en del af produktet

I samme øjeblik betalingen går igennem, bliver indbakken den mest interessante skærm i testen. Kvitteringer bygges sidst og glemmes først, men for kunden er det netop det dokument, der beviser, at det hele skete — filen han videresender til økonomiafdelingen, bilaget til en udgiftsrapport.

• Beløbet stemmer med betalingssiden. Indlysende, og usandt oftere end man bryder sig om, så snart rabatter, forholdsmæssig beregning og valutaomregning kommer i spil.
• Momsen er specificeret korrekt for den region, du testede.
• Plannavnet er det kundevendte, ikke plan_pro_v2_2024.
• Fakturanummer, dato og virksomhedsoplysninger er til stede og læsbare for et menneske.
• PDF'en eller det hostede fakturalink åbner for en, der ikke er logget ind. Bogholderen, der modtager videresendelsen, har ingen konto.
• Alle links peger et offentligt sted hen. Staging lækker localhost-URL'er ind i mails med stor entusiasme.

Trin 5: Fornyelser og mislykkede betalinger, uden at vente en måned

Abonnementsfejl gemmer sig i fremtiden, og derfor overlever de så længe. Fornyelsesbetalingen, advarslen om kort der udløber, rykkerforløbet, den endelige opsigelsesbesked — alt sammen sker uger efter udgivelsen, og på det tidspunkt holder ingen øje med en indbakke.

Du behøver ikke vente. Stripes testure spoler en testkunde gennem faktureringscyklusser på sekunder, og de fleste udbydere har noget tilsvarende. Ret det mod en engangsindbakke, og et års faktureringskorrespondance ankommer på få minutter:

• Fornyelseskvitteringen sendes på den rigtige dag med det rigtige beløb.
• Varslet om kommende betaling, hvis du sender et, kommer tidligt nok til at være til nytte.
• Rykkerforløbet eskalerer fornuftigt ved et kort, der bliver afvist — og stopper i samme sekund betalingen lykkes. Ingen, der allerede har betalt, bør få den tredje sure påmindelse.
• Beskeder om nedgradering og spærring stemmer overens med, hvad kontoen reelt stadig kan.

Trin 6: Opsig, og refundér derefter

Gå hele vejen til ende. Opsig, og tjek at bekræftelsen fortæller sandheden om, hvorvidt adgangen fortsætter til udgangen af den betalte periode eller stopper med det samme — den ene sætning genererer flere vrede opfølgende sager end nogen anden inden for fakturering. Refundér derefter fra udbyderens side, og bekræft at en kreditnota eller refusionsbekræftelse faktisk når frem til kunden i stedet for, at pengene flytter sig lydløst inde i et dashboard, kunden ikke kan se.

Gennemgangen, hver besked skal have

Uanset hvad der udløste den, får hver mail den samme hurtige gennemgang. Sekunder, når det først er blevet en vane:

• Den kom frem, og i indbakken frem for at blive smidt væk i stilhed.
• Intet vises som en rå pladsholder. Et uløst token i en hilsen er den mest pinlige fejl i denne artikel, og den går i produktion hele tiden.
• Alternativet i ren tekst findes og læses ordentligt. Masser af klienter og skærmlæsere bruger det i stedet for HTML.
• Links er absolutte og offentlige.
• Marketingmails har en fungerende afmelding, inklusive ét-klik-headeren fra RFC 8058, som nu reelt er et krav for masseafsendere ifølge Googles retningslinjer for afsendere. Transaktionelle kvitteringer bør ikke have den.
• Autentificeringen består. Hvis testmails leveres dårligt, så find ud af det nu — hvorfor transaktionsmails ender i spam gennemgår årsagerne.

Hvorfor en engangsindbakke passer til denne løkke

Det, der gør det her praktisk muligt, er, at indbakken er til engangsbrug uden at være ubrugeligt kortlivet. Beskeder ankommer i realtid, så du ser hver enkelt lande i samme øjeblik systemet sender den, og årsag og virkning forbliver tydelige. Adressen holder en time, hvilket rigeligt dækker en tilmelding, et betalingsflow, en 3-D Secure-omvej og en fremspolet faktureringscyklus — en ti-minutters indbakke har det med at udløbe præcis, når kvitteringen er på vej.

Og der er intet at rydde op bagefter. Ingen testkonti der hober sig op på din rigtige adresse, ingen delt QA-postkasse hvor seks personers kørsler flyder sammen, ingen tvivl om, hvorvidt beskeden på skærmen hører til dagens kørsel eller sidste torsdags. Næste forsøg starter helt blankt, hvilket er hele pointen. Vil du have detaljerne om, hvad der sker med det hele, når timen er gået, har vi skrevet om det i hvad der sker efter én time.

Hvad det her faktisk fanger

En kørsel som denne graver pålideligt én bestemt familie af fejl frem — dem der lever mellem systemer frem for inde i dem:

• Kvitteringer der aldrig sendes, fordi et efterfølgende job har brug for et felt, som et helt urelateret trin sætter. (Hej, mandag.)
• Dobbelte betalinger fra ét utålmodigt andet klik.
• Velkomstmails der udløses to gange, eller aldrig, for folk der betaler før de verificerer.
• Betalingen lykkes, mens planen stille undlader at aktivere, så en betalende kunde bliver hængende på gratisniveauet.
• Afbrudte 3-D Secure-udfordringer der efterlader forældreløse halve abonnementer.
• Staging-URL'er i mails, der var ét konfigurationsflag fra at nå kunderne.
• Rykkerforløb der stadig jagter en, som allerede har betalt.

En advarsel, sagt lige ud

Det her er en teknik til at teste software, du er ansvarlig for, i et miljø du kontrollerer, mod en betalingssandbox. Det er ikke en måde at høste gratis prøveperioder, snige sig uden om en betalingsmur eller fabrikere konti på en andens tjeneste. Det er misbrug, det er grunden til, at udbydere af engangsmails ender med at blive blokeret, og det er ikke det, værktøjet er til.

Begrænsningen går også den anden vej: en engangsindbakke er bevidst midlertidig, så knyt aldrig en konto til den, du har brug for at beholde. Kan du ikke gendanne den uden postkassen, så brug en rigtig adresse. Alias kontra midlertidig adresse er den rigtige læsning, hvis du er i tvivl om, hvilken side af den linje du står på.

Gør det til en rutine, ikke en heltedåd

De teams, der fanger den slags, er ikke dem med de mest udspekulerede testplaner. Det er dem, der går hele vejen som fremmede, før noget meningsfuldt bliver udgivet — ny indbakke, ren profil, tilmeld, verificér, betal med testkort, læs hver besked, opsig, refundér. En halv time, helt manuelt, og det bliver ved med at finde ting, den automatiserede suite strukturelt ikke kan finde, fordi suiten er bygget på de samme antagelser som koden.

Sæt det i kalenderen — hver fjortende dag, eller før enhver udgivelse der rører ved tilmelding eller fakturering. Den første kørsel graver næsten altid noget frem, som ingen havde bemærket, og mandag morgen-sagen holder op med at være noget, der sker for dig. Hent en frisk engangs e-mail, og gå hele vejen.