Test af e-handelsløsninger – og hvorfor udforskende test er alt andet end spild af tid

Softwaretest er det vigtigste i verden. I hvertfald for mig. Eller… nej vent, hvis ikke der var softwareudvikling, ville der jo ikke være noget at teste. Så selvfølgelig er softwareudvikling også lidt vigtigt.

Jeg er QA-konsulent (Quality Assurance) i Vertica – og en af mine fornemmeste opgaver er at teste e-handelsløsninger og på den måde hjælpe udviklerne med at skabe velfungerende løsninger, som giver værdi for både slutbrugere og virksomheder.

For mig er test ikke test-cases, og test-cases er ikke test. Test er for mig at udforske en applikation, en ny feature, en ændret funktion eller måske en integration. Det betyder, at jeg ikke på forhånd ved, hvor testen bærer mig hen. Jeg har selvfølgelig nogle ideer til, hvad jeg gerne vil teste – f.eks. efter at have læst en one-liner-opgave og talt med en udvikler. Men undervejs bevæger jeg mig ofte væk fra idéerne, fordi jeg ser noget, der vækker min nysgerrighed. Måske noget der er inkonsistent – eller som ikke stemmer overens med min opfattelse af, hvordan f.eks. en validering bør agere.

Forleden sad jeg og testede en e-handelsløsning og ville egentlig se, om jeg kunne genskabe en fejl, rapporteret af en kollega. Jeg nåede ikke til at genskabe fejlen, før min nysgerrighed havde fået overtaget, og jeg begyndte at undersøge grænseværdierne i løsningen. Der var nemlig noget med, at man som minimum skulle handle for 400 kr. for at kunne gå videre fra kurven til kassen.

Test af grænseværdier

Et af testværktøjerne i min værktøjskasse hedder grænseværditest – og det går i al sin enkelhed ud på at undersøge de værdier, der ligger på, over og under en grænse. I det her tilfælde var grænseværdien 400 kr. Det interessante var, at shoppen skulle opføre sig på en bestemt måde, når man ramte grænseværdien – for så skulle man få lov til at gå videre til kassen og checke ud. Jeg ville derfor undersøge, om det nu også var tilfældet og fik derfor lavet en kurv på præcis 400 kr. Min antagelse var så, at den måtte validere og give mig lov til at gå videre til kassen. Men det gjorde den bare ikke. Det viste sig, at der var en fejl i valideringen. En del af websiden viste faktisk, at nu havde jeg opnået minimumbeløbet for min kurv til at fortsætte til kassen – men knappen til at klikke videre blev bare ikke aktiv. Der var altså en fejl i koden.

Jeg undersøgte også værdierne lige over, og lige under, nemlig 390 kr., og 410 kr. for at se, om de virkede som forventet. Det gjorde de. Så jeg havde indsnævret problemet til lige præcis at være en kurv på 400 kr. (Optimalt set havde jeg måske lavet tests med 399,99 kr og 400,01 – men det ville tage mig lang tid at finde data til at skabe præcis den kurv størrelse – så jeg vurderede, at det var godt nok med 390 og 410.)

Hvorfor er det en god idé at teste grænseværdier?

Erfaringen viser, at der ofte opstår fejl i nærheden af grænseværdier – fordi en udvikler feks. kan vende et tegn forkert. > er ikke det samme som <. Eller han kan skrive >=, hvor det i virkeligheden skulle have været >. Osv. Disse fejl finder man forholdsvist nemt med grænseværditest.

Tilbage til min test forleden. Jeg havde fundet en fejl. Men min udforskning stoppede ikke her. Jeg kunne jo se i skærmbilledet, at der var andre grænseværdier. Der var nemlig også en for billigere fragt ved 800 kr. Og en grænseværdi for gratis fragt ved 1300 kr.

Jeg ved af erfaring, at fejl ofte optræder sammen. Med det mener jeg, at er der fejl i validering af én grænseværdi, så er der måske også fejl med andre valideringer. Så dem undersøgte jeg selvfølgelig også. Det viste sig, at de faktisk virkede … sådan næsten da. I hvertfald hvis jeg trykkede F5 efter hver ændring af antal produkter i kurven. Jeg havde nemlig fundet et cachingproblem, som gjorde, at fragtbeløbene blev vist forkert på skærmen (medmindre jeg trykkede F5).

Af hensyn til performance havde udvikleren nemlig valgt ikke at genberegne fragt, hver gang man ændrede på antal af varer i kurven. Det gav så bare det resultat, at jeg faktisk kunne snyde kurven til at give mig gratis fragt for et langt lavere beløb, end det var meningen – eller omvendt kunne afslutte min ordre uden at få fri fragt, selvom jeg rent faktisk burde have fået det.

Sæt en tidsgrænse på udforskende test

Efter at have fundet og dokumenteret tre ret kritiske fejl omkring grænseværdier, kom jeg i tanker om, hvad jeg egentlig var startet ud med – og vendte derfor tilbage til min oprindelige ide om at genskabe en kollegas fejl.

Havde jeg så spildt tiden, fordi jeg glemte hvad jeg egentlig var igang med?

Nej.

Ikke i min optik.

Det er netop pointen med udforskende test – at man har lov til at bevæge sig ud i en løsning baseret på, hvad man observerer og erfarer undervejs i testen. Er man nervøs for at komme for langt væk fra sporet – og risikere ikke at have tid nok til at teste andre ting også – kan man vælge at timeboxe sin udforskning og feks. sætte sig for, at man har en time til at udforske et givent område af løsningen. Og så skal man selvfølgelig huske at stoppe, når tiden er gået.

Er du interesseret i at vide mere om, hvordan vi arbejder med test i Vertica, er du meget velkommen til at tage fat i mig.