Test hele kjøpet: Bygg en testmatrise for WooCommerce

Kategori: WooCommerce

En WooCommerce-butikk er ikke ferdig testet fordi én person har klart å betale for ett produkt. Profesjonelle nettbutikker har flere produktvarianter, fraktregler, betalingsmåter, kundetyper og integrasjoner. Hver kombinasjon kan påvirke hva kunden ser, hva som registreres på ordren, og hva som sendes videre til lager, økonomisystem og transportør.

En testmatrise gjør denne kompleksiteten håndterbar. I stedet for å klikke tilfeldig gjennom butikken lager dere et avgrenset sett med testkjøp som dekker de viktigste forretningsreglene. Matrisen kan brukes før lansering, etter større endringer og som fast kontroll ved oppdateringer.

Start med risiko, ikke med alle mulige kombinasjoner

Det er sjelden realistisk å teste absolutt alle kombinasjoner av produkter, adresser, fraktmetoder og betaling. Målet er å identifisere kombinasjonene som enten brukes ofte eller kan gi store konsekvenser hvis de feiler.

Begynn med å samle representanter fra nettbutikk, kundeservice, lager, økonomi og teknisk drift. Hver rolle kjenner forskjellige feilbilder. Kundeservice vet hvilke bestillinger som skaper spørsmål. Lageret kjenner problemene med varenummer og plukklister. Økonomi vet hva som må stemme for at oppgjør og bokføring skal kunne avstemmes.

Prioriter testtilfeller etter tre spørsmål:

• Hvor ofte oppstår denne typen kjøp?
• Hvor stor blir konsekvensen hvis kjøpet behandles feil?
• Hvor mange systemer og regler er involvert?

Et ordinært kjøp med butikkens mest brukte betalings- og fraktmetode skal alltid være med. Det samme gjelder sjeldnere tilfeller med høy risiko, som en ordre med rabatt, delvis utsolgt vare eller levering til et område med egne fraktregler.

Definer testprodukter som dekker produktstrukturen

Tilfeldige produkter gir tilfeldige tester. Velg i stedet et lite, fast sett med testprodukter som representerer strukturen i varekatalogen.

Testsettet kan for eksempel inneholde:

• Et enkelt produkt med lagerstyring.
• Et produkt med flere varianter, som størrelse og farge.
• En fysisk vare med høy vekt eller spesielle fraktkrav.
• En digital vare uten fysisk levering.
• Et produkt som er på salg eller inngår i en rabattregel.
• En restnotert vare dersom butikken tillater restordre.

Kontroller mer enn produktsiden. Varenavn, variant, varenummer, pris, avgift, antall og vekt må følge kjøpet korrekt gjennom handlekurv, checkout, ordrevisning, e-post og integrasjoner. En variant som vises riktig for kunden, kan fortsatt bli eksportert med feil varenummer til lageret.

Bygg matrisen rundt reelle kjøpssituasjoner

Hver rad i testmatrisen bør beskrive ett konkret kjøp. Unngå vage punkter som «test checkout». Skriv hva som skal kjøpes, av hvem, med hvilken adresse, fraktmetode, betalingsmåte og forventet resultat.

Et testtilfelle kan se slik ut:

• Kunde: Ny privatkunde uten brukerkonto.
• Kurv: Ett lagerført produkt og én variant.
• Levering: Ordinær innenlandsadresse.
• Betaling: Kortbetaling.
• Forventning: Riktig totalsum, lagerreduksjon, ordrebekreftelse og overføring til lager og økonomi.

Lag deretter varianter som dekker viktige avvik. Det kan være en bedriftskunde, en kupong, gratis frakt over en beløpsgrense, ulik faktura- og leveringsadresse eller et betalingsforsøk som avbrytes.

Kontroller checkout som en beregning

Checkout samler flere forretningsregler på ett sted. Pris, rabatt, avgift, frakt og betalingsgebyr må beregnes riktig og presenteres forståelig. Test derfor både tallene og opplevelsen.

For hvert testkjøp bør dere kontrollere:

• At obligatoriske felt er tydelige og kan fylles ut med tastatur.
• At feilmeldinger forklarer hva kunden må rette.
• At totalsummen oppdateres når adresse eller fraktmetode endres.
• At rabatter brukes på riktige produkter og beløp.
• At tilgjengelige betalingsmåter passer kundetype, land og ordreverdi.
• At kunden ser hva som skal betales før bestillingen bekreftes.
• At et dobbeltklikk ikke skaper to bestillinger eller betalinger.

Gjennomfør minst noen tester på mobil og med en tregere forbindelse. En checkout kan fungere teknisk på en rask kontormaskin, men bli utydelig når innlasting og svar fra betalingstjenesten tar tid. Kunden må få klar beskjed om at betalingen behandles, og knappen må ikke invitere til gjentatte forsøk.

Test hva som skjer når betalingen ikke lykkes

Den normale kjøpsreisen er bare halve bildet. Feil oppstår ofte i overgangene mellom WooCommerce og betalingstjenesten. Kunden kan lukke vinduet, avbryte godkjenningen eller oppleve at forbindelsen brytes etter betaling.

Lag egne tester for avbrutt, avvist og forsinket betaling. Kontroller hvilken ordrestatus som settes, om lager reserveres eller reduseres, og hvilken informasjon kunden mottar. Kundeservice må kunne se forskjell på en ordre som aldri ble betalt, og en betaling som er registrert eksternt, men ikke ferdig oppdatert i nettbutikken.

Test også hvordan en ny betaling håndteres. Kunden bør ikke måtte gjette om det er trygt å prøve igjen. Samtidig må løsningen redusere risikoen for at samme ordre betales flere ganger.

Følg ordren gjennom alle systemene

Et vellykket kjøp i nettleseren er ikke nødvendigvis en vellykket ordreprosess. Testen må fortsette etter takkesiden.

Kontroller ordren på hvert trinn:

1. Er ordren opprettet med riktige kunde-, produkt- og prisdata?
2. Har ordren riktig status etter valgt betalingsmåte?
3. Er lagerbeholdningen oppdatert på riktig produkt og variant?
4. Er korrekte e-poster sendt til kunde og interne mottakere?
5. Er ordren overført til lager, økonomi eller andre fagsystemer?
6. Har mottakersystemet tolket varenummer, avgift, rabatt og frakt riktig?
7. Kan sporingsinformasjon og senere statusendringer sendes tilbake?

Ikke stol bare på at integrasjonen melder «fullført». Sammenlign innholdet i begge systemer. En ordre kan være overført uten at alle linjer, rabatter eller adressefelt er korrekte.

Ta med endringer etter kjøpet

Mange feil oppstår når en ordre må endres. Derfor bør testmatrisen også dekke kansellering, refusjon og eventuell retur.

Test en full refusjon og, dersom virksomheten bruker det, en delvis refusjon. Kontroller hva som skjer i betalingstjenesten, WooCommerce, økonomisystemet og lageret. Det må være avklart om varer automatisk legges tilbake på lager, eller om dette først skal skje etter at en fysisk retur er kontrollert.

Prøv også en ordre som endres manuelt. Hvis kundeservice legger til et produkt, endrer frakt eller justerer antall, må dere vite hvilke beregninger og integrasjoner som kjøres på nytt. Manuelle rutiner bør dokumenteres når systemene ikke kan holde alt synkronisert automatisk.

Mål ytelse der kundene faktisk venter

Testkjøpene gir en god anledning til å vurdere ytelse gjennom hele reisen. Registrer hvor dere opplever tydelig venting: når handlekurven oppdateres, når frakt beregnes, når checkout lastes, og når bestillingen sendes.

Skill mellom treghet i nettbutikken og venting på eksterne tjenester. Betaling, adresseoppslag, fraktberegning og integrasjoner kan påvirke responstiden. Dette bør være synlig i teknisk logging, slik at driftsansvarlig kan finne flaskehalsen uten å gjette.

Test også med realistisk størrelse på handlekurven. En butikk der kunder ofte kjøper mange varelinjer, bør ikke bare testes med ett produkt.

Gjør testmatrisen til en driftsrutine

En testmatrise mister verdi hvis den bare brukes ved første lansering. Oppdater den når dere innfører nye betalingsmåter, fraktregler, produkttyper eller integrasjoner. Fjern testtilfeller som ikke lenger er relevante, og legg til nye når kundeservice oppdager gjentakende problemer.

Gi hvert testtilfelle en ansvarlig person, forventet resultat og status. Registrer også hvilket miljø og hvilken dato testen gjelder. Ved feil bør dere notere om problemet ligger i WooCommerce, en utvidelse, integrasjonen eller en intern rutine.

Før en større lansering eller oppdatering bør virksomheten definere hvilke tester som må være godkjent. Kritiske kjøpsløp skal ikke ha åpne feil. Mindre avvik må være vurdert, dokumentert og tildelt en ansvarlig.

Et lite testsett er bedre enn tilfeldig klikking

Dere trenger ikke starte med et omfattende kvalitetssystem. Begynn med de fem til ti kjøpssituasjonene som står for mest omsetning eller høyest risiko. Sørg for at hver test følger ordren helt fra produktvalg til betaling, lager, integrasjoner og etterbehandling.

Da blir testing en kontroll av virksomhetens faktiske salgsprosess, ikke bare av nettsidens knapper. Det gir tryggere lanseringer, raskere feilsøking og færre ordre som må repareres manuelt etter at kunden har betalt.