BLOG
SOFTWARETEST

Bruger du dine testdesignteknikker proaktivt?

Som testere har vi en lang række værktøjer i vores værktøjskasse som vi bruger til at identificere og specificere de mest relevante testcases, for at opnå den bedste dækning i forhold til de risici vi har identificeret - men bruger du dem proaktivt?

Værktøjerne er fantastiske og bør være en integreret del af enhver testers daglige arbejde i teamet eller på projektet. Men den største værdi fremkommer jo først, når koden er klar – ellers kan vi ikke afvikle vores testcase – reelt en aktivitet på bagkandt (i hvert fald afviklingen af dem). Men i følge diverse statistikker er op mod 50% af alle bugs introduceret allerede i den periode hvor kravene defineres, så kunne vi ikke finde en måde hvorpå vi hjælper til at identificere dem der – i stedet for ved dynamisk test? kunne vi bruge vores testdesignteknikker proaktivt?

Hvad nu hvis vi i stedet bare tænkte testdesignteknikker som ”modelleringsværktøjer”? Noget der også kan anvendes til afklaring af kravene, skabe et bedre billede af hvilke behov brugerne har, og hvilke arbejdsopgaver de skal løse?

Hvis vi nu i stedet bruger dem som et værktøj til dette, så kan vi være med til at skabe et mere solidt grundlag for den efterfølgende udvikling, uanset om vi er i en agil eller mere traditionel udviklingskontekst.

Eksempler på dette kunne f.eks være min yndlings testdesignteknik: Proces cyklus test. Den er perfekt til at afdække de forretningsgange/workflows som brugeren skal have supporteret, og den kommunikerer rigtig godt fordi den primært er dokumenteret som et data-flow diagram. Hvis man tegner flowet efterhånden som man diskuterer arbejdsgangen, så bliver det hurtigt synligt hvor der er brug for beslutninger og hvor der sker noget udover sekventielle aktiviteter – noget hele teamet har brug for at forstå. Man kan så bruge flowet til at identificere en række scenarier, som bør være ”acceptance scenarier” og disse er så efterfølgende dit testindspark, dine accepttestcases. Nedenstående er et simpelt eksempel på et flow gennem en webshop, et utroligt godt grundlag for en diskussion omkring arbejdsgange mens man afklarer scope, man kunne så lave detaljerede flows på ”søgning”, ”betaling” osv – det nedenstående er et eksempel på et overordnet acceptance flow.

Tallene ved beslutningerne benyttes til at identificere dine testcases – se mere om PCT på http://tmap.net/wiki/process-cycle-test-pct

Et andet eksempel kunne være State Transition Test. En gang imellem møder jeg teams, der faktisk tegner den State Machine der ligger inde i deres kode. Diagrammet og også gerne tabellen der kan udledes heraf, er en fantastisk måde at diskutere hvad der skal ske – hvilke transitioner er lovlige, og ikke mindst hvilke er ikke. Både diagrammet og tabellen er igen en letvægtsdokumentation, som er let at forstå – let at kommunikere. For nyligt havde jeg en diskussion med et team over et sådan diagram, de var vældig fokuserede og diskuterede omkring alle de transitioner, der skulle være mellem de forskellige States – men diskuterede slet ikke de, der IKKE skulle være der! Men ved at pege det ud på tegningen og spørge: ”i har selvfølgelig også tænkt håndtering af, at man ikke må gå fra X til Z ikke?” så flyttede vi fokus over til også at adressere de negative aspekter.

Eller har du tænkt på klassifikationstræet? Eller måske bare den helt klassiske visualisering af Equivalence Partitioning og Boundary Value Analysis – synliggørelsen af hvilke værdier der er med i hvilke partitioner? Hvorfor ikke diskutere dette ved rent faktisk at tegne og synliggøre det for både forretning og team.

Nogen af de mnemonics jeg bruger som en del af den Exploratory test, er også oplagte som værktøjer til at diskutere behov/krav. Min yndlings mnemonic er SFDIPOT – eller som den ofte kaldes San Fransisco Dipot. Bogstaverne står for Structure, Functionality, Data, Integrations, Platform, Operations, Time. Sæt det op på et whiteboard i et mindmap og brug det som grundlag for en diskussion; hvilke platforme skal vi understøtte? Er der specielle krav til/fra driften? Hvilke eksterne systemer er der, hvilke typer integrationer? Igen en meget simpel visualisering, men rigtig god at snakke ud fra – ikke kun med testperspektivet, men også for at teamet får et bredt fælles billede af opgaven. Det gælder uanset om det er i starten af et projekt eller et sprint, eller når teamet står overfor at starte udvikling af en ny feature – op på tavlen med den og diskuter de forskellige aspekter.

Så vi har masser af gode værktøjer i vores værktøjskasse der kan hjælpe teamet med at få det rigtige grundlag for at levere værdi for kunden, vi skal bare bruge dem på rette tid – proaktivt i stedet for som vores eget interne værktøj. Hvordan du kommer igang? Måske er du så heldig at du bare kan foreslå det i teamet og så vil de være med på den, men hvis ikke, så gør det på en indirekte måde. Jeg prøvede på et tidspunkt bare at sidde og tegne mens team og PO diskuterede, og da man så var ved at afslutte diskussionen for en feature, så havde jeg et antal spørgsmål jeg gerne ville have svar på – beslutninger der endte blindt. Jeg brugte min håndtegnede tegning som grundlag for spørgsmålet – og kunne derved påvise, hvordan man på min måde kunne skaffe et overblik. Så guerilla metoder hvor man sniger ind ”Bag fjendens linjer” er en anden måde at nå frem (og nej teamet er ikke fjenden – det er bare en metafor).

Men prøv det – hjælp dit team med at bygge kvalitet ind i løsningerne, i stedet for primært at fokusere på den dynamiske test når koden er udviklet.

Gitte Ottosen
Gitte Ottosen
Managing Consultant
+45 39778711
todo todo