Tenk deg at du skal lage testcaser til et saksbehandlingssystem. Testcasene skal være verdikjedetester – de skal altså teste en hel verdikjede fra start til slutt, og det er kun flyten vi har fokus på. Verdikjeden består av et sett med oppgaver hvor saksbehandler skal gjøre ulike valg i hver oppgave. Vi kan ta som utgangspunkt at saksbehandler har to svaralternativer i hver oppgave; ja og nei. Dette vil typisk være svar på spørsmål som:
- Er søknaden komplett?
- Er alle delene av søknaden på rett format?
- Har søker grunnlag for å søke om det det søkes om?
- Er søknaden godkjent?
- Osv…
La oss si at saksbehandler må gjennom et visst antall oppgaver uansett hvilke svar som avgis underveis. Man kan enkelt regne ut hvor mange kombinasjoner av svar man kan få. Dersom det hadde vært to spørsmål hadde man fått 2•2 = 4 unike kombinasjoner av svar:
Ja/Ja
Ja/Nei
Nei/Nei
Nei/Ja
Dersom det er 10 spørsmål får man 2•2•2•2•2•2•2•2•2•2 = 1024 kombinasjoner.
Bare tanken på å kartlegge og skrive 1024 testcaser kan gjøre den mest ivrige testcase-skriveren matt. Strengt tatt, så trenger man gjerne ikke alle disse testcasene en gang, og kanskje leder en god del av de til samme konklusjon til slutt? Men hvordan vet man hvilke av disse kombinasjonene man skal fokusere på å teste? Det er her det kan være nyttig å lage et tankekart.
Få oversikt
Hovedgrunnen for å sette opp et tankekart er å få oversikt. I eksempelet over fikk saksbehandler like mange oppgaver uansett hva som ble svart underveis, men ofte er ikke det tilfellet. Hvor mange og hvilke oppgaver man får avhenger av hva man har svart tidligere, og det blir vanskeligere å regne ut hvor mange ulike kombinasjoner som finnes. Man kan selvfølgelig starte med å skrive testcaser med ord, men jeg får ofte mye bedre oversikt av en god figur. Prøv bare å skrive opp de ulike casene dersom man i eksempelet øker fra to spørsmål til 4, og får 16 unike kombinasjoner av svar. De fleste vil synes at det er lettere å komme på alle de ulike kombinasjonene dersom de tegner de opp.
Vurdere
Når du har fått opp et tankekart over alle de mulige veiene man kan ta i systemet, kan du vurdere hvilke av veiene du skal fokusere på å teste. Med kunnskap til løsningen som skal testes vet du gjerne hvilke av veiene som er mest kritiske, hvilke av veiene er mest vanlige. Kanskje er det noen av veiene som er teknisk mulig å gå, men som for en saksbehandler vil være helt usannsynlig at man kan velge? Kanskje er det lurt å teste den korteste og den lengste veien? Kanskje er det så få veier at du ønsker å teste alle? Uansett hvilke vurderinger man gjør, så er tankekart nyttig for å visuelt kunne se hvilke kombinasjoner det er du skal teste.
Gjennomføre
Når du har satt opp tankekart og fått oversikt over hvilke valg som skal tas underveis, så er min erfaring at tankekartene er så gode at de kan brukes som testcaser, og jeg slipper å skrive ned stegvise testcaser. I stedet for å skrive et testcase hvor det står at man skal svare ja på første spørsmål, og så nei på andre spørsmål, så kan du si at man skal følge rute 1 i tankekartet.
Man kan selvfølgelig legge inn steg i tankekartene som ikke er spørsmål, men som er instruksjoner til brukeren, som fyll inn navn, last opp dokument, last opp en fil som ikke er på godkjent format, og så videre. Poenget er at testeren får en visuell testcase som kan følges, og som gjerne er lettere å følge med på enn et langt stegvist tekstdokument.
Det vil ikke alltid være slik at tankekart er det beste å bruke for å lage testcaser, men min erfaring er at tankekart er ekstremt nyttig når man skal få oversikt over flyt gjennom et system, hvilke veier man kan ta, og hvilke utfall det genererer. Det er nyttig for å få en visuell oversikt over hva man skal teste og hvordan. Tankekart kan også brukes av testere som ikke har vært borti systemet som skal testes før, og det loser testerne fint gjennom de ulike veiene i systemet. I tillegg synes jeg det er gøy å lage testcaser når jeg gjør det ved å bruke tankekart.
