Har du tænkt over, hvad du kunne teste?

En af de vigtigste diskussioner, vi havde i Rob Sabourins lille tutorial-gruppe på Øredev, handlede om hvorfra ideerne til test objectives og test cases egentlig kommer fra.

En del af de fremmødte luftede frustrationer over sammenhænge, hvor alle test cases forventes at komme fra en mursten af en kravspecifikation; en enkelt havde sågar oplevet at have svært ved at få lov til at rapportere fejl, hvis ikke fejlen kunne henvises direkte til test af et navngivet krav! Meget ofte vil en test, hvis udformning drives for hårdt af krav, have et meget snæver indgangsvinkel, hvor Sabourins pointe var, at vi burde se på en hel række forskellige kilder til testideer, altså potentielle test objectives.

I den øvelse, vi blev sat til at lave for at finde testideer til et fiktivt system, benyttede vi os af små papkort i forskellige farver, hvor farverne repræsenterede forskellige kilder. Pointen med farvekodningen var, at man sikrer sig, at man ikke fokuserer for ensidigt på en enkelt kilde. De kilder, vi arbejdede med i øvelsen var (et mindre udvalg af de 10 kilder nævnt i denne artikel):

• Capabilities (har ikke helt kunne finde en god dansk oversættelse) – at man forsøger at bekræfte, at systemet faktisk kan gøre det, man forventer. Her er en kravspecifikation, hvis man har en sådan, en ganske udmærket hjælp. Man skal dog huske de mere implicitte krav som f.eks. bagudkompatibilitet, der kan være MINDST ligeså vigtige som de eksplicitte.
• Fejltilstande – hvordan kan det gå galt? Korrupt input, begrænset miljø (eks. diskpladsbegrænsninger), store datamængder etc. Her ser man på mulighederne for at slå det faktisk designede og implementerede system i stykker, og de oprindelige krav spiller derfor en mindre rolle.
• Kvalitetsfaktoren – her handler det i høj grad om ikke-funktionelle krav som brugervenlighed og performance. Sabourins erfaring (som jeg også har hørt andre steder fra) er, at det kan være svært at få en kunde eller andre stakeholders til at formulere kravene på forhånd, men man kan måske alligevel lokke noget brugbar information ud ved at spørge til forskellige konkrete scenarier som: ”Hvis der viser sig at være en fejl, som gør, at der kun kan være 10 samtidige brugere på, vil vi så forsinke releaset for at få det rettet?”
• Brugscenarier – meget ofte bruges systemet i praksis på en helt anden måde end tiltænkt, eller bruges ikke på samme måde af forskellige typer brugere.
• Kreative tilgange – alternative måder at generere testidéer på, f.eks. ved at forestille sig, hvad der ville ske, hvis Bart Simpson skulle bruge programmet. Læs også gerne mere om Soap Opera Testing, som Hans Buwalda har skrevet en artikel om i 2004, for kan man måske få forsikringssystemets regler til at bryde ned, når man lægger en Woody Allen ind, som gifter sig med sin (adoptiv)datter? Og det gør jo heller ikke noget, at det sjovt at gå på arbejde – heller ikke, når der skal testes! :-)

Hvor får du dine test-ideer fra?