På min vej i softwarens verden i projekter eller i organisationer møder jeg den dag i dag stadig mange personer i Danmark der har et snævert syn på test af software – alt for snævert. Og ja, ordene “test cases” dukker op i næsten alle de samtaler jeg har med disse personer, når dialogen falder på emnet “test”.
Jeg bryder mig ikke om, at den professionelle karriere jeg har valgt som levevej, som jeg har taget uddannelser indenfor, betragtes som noget simpelt og nemt.
Jeg forstår godt de spørgsmål jeg umiddelbart bliver mødt af, når jeg befinder mig blandt ikke-testkyndige, men beslutningsdygtige personer. F.eks. “Hvorfor skal du bruge så meget tid til test?”, “Er det værktøj virkelig nødvendigt?”, “Hvorfor automatiserer du ikke bare testen?”, “Hvorfor har du brug for design dokumentation?”, “Hvor mange test cases tror du der er brug for i dette projekt?”. Og mange flere lignende spørgsmål.
Nogle gange føler jeg at mine kompetencer bruges mere på at lære beslutningstagere op i testfaget end at jeg får lov til at udføre mit arbejde. Det er blevet et vilkår i mit fag – at oplære andre i det.
I magasinet “Testing Trapez”, udgave februar 2014 kan du finde en rigtig god og også vigtig artikel, som jeg foreslår at du læser, hvis du er tester.
TEST CASES ARE NOT TESTING: TOWARDS A CULTURE OF TEST PERFORMANCE (side 30)
Af James Bach, Washington, USA og Aaron Hodder, Wellington, New Zealand
Testing is the evaluation of a product by learning about it through experiment; by seeing it in action. The reason we test is to analyse product risk: the danger that the product will cause trouble for its users or otherwise fail in some way to fulfill its purpose. In other words, we look for anything about the product that might significantly impair its value. We are looking primarily for “bugs.” We want to find every important bug, although there will be no way to know for sure that we have succeeded.
Jamen, hvad er en test case så?
Nu vil jeg forklare det med en analogi. Her skal man huske på at der er en fælde ved at anvende analogier. Nemlig, at man altid kun fokuserer på hvor analogien passer sammen med det man gerne vil forklare. Men man glemmer at forklare hvor og hvorfor analogien ikke passer helt. (det var et side spring).
En test case kan bedst beskrives som en opskrift. Altså en beskrivelse af hvordan man gennemfører en bestemt aktivitet. Her vil jeg sammenligne det med en opskrift på en omgang aftensmad (min analogi).
En opskrift indeholder ingredienserne du skal bruge i de rette mængder, beskrivelse af fremgangsmåde, den forventede tilberedningstid og nogle gange endda den ernæringsmæssige energifordeling og om det færdige resultat er fryseegnet.
Opskriften fortæller nogle gange om hvilke værktøjer du skal bruge, men ikke hvordan du bruger dem og sjældent om alle værktøjerne. Der står aldrig, hvordan opskriften er opstået eller blevet udviklet, måske noget om oprindelsessted. Nogle opskrifter anvender endda fagudtryk, hvor du må slå op andetsteds, for at forstå hvad det betyder.
Sidst, men ikke mindst: Det er heller ikke forklaret hvilken oplevelse du får når du spiser retten – det ved du først når du smager på det færdige resultat.
Hvis jeg skal konkludere på ovenstående:
En test case er en opskrift (dokumentation).
En test case kræver ofte forkundskaber og altid viden.
En test case er ikke en internationalt defineret enhed.
Test case indholdet vil variere – fra test case til test case.
En test case kan hjælpe dig frem til information om dit produkt, men først når du bruger dit produkt.
