BLOG
SOFTWARETEST

Blog: Agil testkvadranter

Kender du de agile testkvadranter?

[18. marts 2015] Et af de spørgsmål jeg hører mest omkring agil test er, hvordan man laver en teststrategi. Hvis
man tidligere har arbejdet meget i projekter der følger en V-model e.lign., er det naturligt at man
også gerne vil lave en for et agilt projekt, og det er bestemt også relevant. De agile testkvadranter
er en del af svaret og en af de modeller jeg bruger mest i agile projekter. De er oprindeligt
opfundet af Brian Marick og ser sådan her ud:

 

Agile Testkvadranter

 Klik her for at hente "De Agile Testkvadranter"  (20mb) ned som PDF til print i op til A0+ 

 

Som navnet antyder er der fire kvadranter der hver indeholder nogle test typer. Testtyperne er
fordelt efter, hvilken værdi de bidrager til projektet.


Kvadrant 1
Indeholder unittest og lign. test der ofte håndteres af team medlemmer der kan kode. Disse tests
giver fokus på intern kvalitet og hjælper med at bygge kvalitet ind i produktet. De hjælper også
teamet med at få lavet mere, ved hurtigt at kunne give feedback da det er testtyper der normalt
automatiseres og dermed nemt og hurtigt kan bruges som regressionstest.


Kvadrant 2
Indeholder testtyper der tester en given funktionalitet i produktet. F.eks. de tests der tester en
storys acceptkriterier. Her styrker testen samarbejdet mellem forretningen og teamet. De giver
fokus på at bygge den funktionalitet forretningen ønsker og vil i vid udstrækning også kunne
automatiseres og dermed supportere teamet i form af regressionstest.


Kvadrant 3
Indeholder testtyper der ser på produktet som en helhed og ofte benytter testernes erfaring med
enten domænet eller produktet som en aktiv del af testen. Det er f.eks. tests, hvor man afprøver
realistiske brugsscenarier og forretningsgange. Dermed får man afprøvet om produktet rent
faktisk kan bruges til det brugerne ønsker. Det betyder samtidig at disse tests er meget svære at
automatisere, men i højere grad hjælper med at afgøre om teamet er på rette vej og leverer det
rigtige produkt.


Kvadrant 4
Indeholder en hel gruppe af tests som vi ofte glemmer - de non-funktionelle. Dvs. tests der ikke
så meget har fokus på hvad produktet kan, men mere på hvordan. Den mest kendte testtype er
de forskellige typer af performance (svartid, load, stress osv.) men her testes også sikkerhed,
brugervenlighed m.m. Ligesom testtyperne i kvadrant 1 er det tests der har fokus på produktets
kvalitet, men nu mere den eksterne kvalitet. Gør produktet det det skal godt nok? Hvorvidt disse
test kan automatiseres svinger meget fra produkt til produkt, men de kræver ofte en eller anden
form for værktøj og ofte er specialister også involveret.


Konklusion
Når vi nu har været igennem alle de kvadranter, hvad kan de så bruges til og hvad har de med en
teststrategi at gøre? Det man kan bruge dem til, er at man skal tænke over hver kvadrant når man
har noget der skal testes. Dvs. teststrategien grundlæggende er: For alle elementer der skal
testes, skal der være noget test fra hver kvadrant, eller man skal have taget en bevidst beslutning
om, at det ikke er nødvendigt.

Jeg skriver “elementer” og ikke “stories", “features” eller “epics” fordi man netop kan bruge strategien på alle niveauer. Når man taler om, hvordan vi tester hele produktet skal vi tænke over hver kvadrant, og når vi tester en enkelt klasse skal vi tænke over hver kvadrant. På den måde skal strategien ikke hele tiden ændres for at følge med de mange ændringer der hele tiden sker i agile projekter. Det er samtidig også en strategi der hurtigt kan præsenteres og som hele teamet aktivt kan anvende. Print den ud i plakatstørrelse og hæng den centralt i projektlokalet.

Hans-Henrik Olesen
Hans-Henrik Olesen
Managing Consultant
+45 52189718
todo todo