Testmodenhedsevaluering – også i en agil kontekst

Der er gennem årene udviklet et antal forskellige formelle tilgange til testmodenhedsevaluering, hvoraf TMMI® og TPI NEXT® er de mest udbredte. De har efterhånden eksisteret i en del år – TMMI® siden 2005 og TPI NEXT® siden 2009 (den oprindelige version af TMM er fra 1996, og den oprindelige TPI fra 1998). Nogle vil måske mene, at de har udlevet deres værdi med udbredelsen af de forskellige agile udviklingsmetoder, da man i dag ikke i samme grad taler om testproces som en separat proces men som en række aktiviteter inde i udviklingsprocessen. Men især de senere års udbredelse af diverse skalerede agile metoder som SAFe®, LESS, Scrum@Scale osv. gør, at det i høj grad stadig er værdifuldt at have blikket rettet mod metoder, hvormed man kan afdække styrker og svagheder i tilgangen til test og kvalitetssikring og identificere aktiviteter, der kan afhjælpe de problemer, som evalueringen afdækker.

Hvis du f.eks. ser på tallene fra World Quality Report 2019/20 (de blå) eller The Definitive Quality Survey fra Forrester (de grønne) nedenfor, så kan de måske give lidt stof til eftertanke.

Nu står der godt nok ”have challenges with testing in SAFe”, men min erfaring er, at det ikke er meget anderledes, uanset hvilken skaleringsmetode man så vælger. Når systemlandskabet bliver stort og komplekst, når mange mennesker skal arbejde på tværs af disse, og når måden, man skal arbejde på, er under stadig forandring, så bliver det også svært at få styr på testaktiviteterne.

Der kan være rigtig meget værdi at hente i at se nærmere på den problematik – at fokusere på at få en mere effektiv og værdiskabende tilgang til test, men hvordan? Man vil ofte se nogle af problematikkerne blive rejst på retrospective-møderne i de enkelte teams, og man vil forhåbentlig sætte målrettede aktiviteter i gang til at løse teamets konkrete problemer i forhold til test og kvalitetssikring. Men her er test bare én af potentielt mange problematikker, der skal diskuteres. Hvad nu hvis historien gentager sig, hvis der er problematikker, der går på tværs af teams – på tværs af organisationen? Hvad nu hvis man med fordel kunne hjælpe forbedringer på vej, der kunne give værdi for større dele af organisationen?

Det er så her testmodenhedsevaluering kommer ind i billedet. Før vi tager hul på at lave forbedringer til højre og venstre i organisationen, så er det godt at få et fælles billede af, hvad udfordringerne er, hvor er det vi er gode, og hvor er det, vi kunne blive bedre. At skabe det fælles billede kan hjælpe med at prioritere, hvor det er der først skal tages fat, og hvordan vi kan løfte kvaliteten af den test, der bliver lavet på tværs af organisationen og i de enkelte teams bedst muligt.

Tænk på det som en GPS…

Et billede på det er lidt ligesom, når du bruger en GPS; du har som minimum brug for to ting, for at din GPS virker: din nuværende placering, og hvor det er du vil hen. Med de informationer (og kontakt til relevante satellitter forstås) kan den komme med et oplæg til din rute – nogle gange kommer den endda med flere du kan vælge imellem. Undervejs holder din GPS øje med forholdene, og er det nødvendigt så ændrer den ruten eller flager i hvert fald som minimum for dig, at det måske var værd at overveje, hvis ikke du skal hænge fast i en kø.

En testmodenhedsevaluering er din nuværende placering, hvis vi skal blive i GPS-analogien. Den kan du lave selv, eller du kan få hjælp – det afhænger helt af din situation, hvad der virker bedst. I nogle organisationer har man stærke testkompetencer, der kan gå ind og lave en sådan evaluering, og man har også rammerne, der gør, at resultatet af en sådan intern evaluering vil have tilstrækkelig tyngde, til at man kan bruge den som løftestang til efterfølgende forbedringstiltag. Ofte vil der dog være værdi i at få hjælp til det ”udefra” – at få et sæt friske øjne på måden, man arbejder på, uden at være påvirket af kultur og politiske problematikker i organisationen.

Det næste er så, hvordan det kan gennemføres, og igen er der flere muligheder – uanset om man vælger at gøre det internt, eller om man får hjælp udefra. Der findes som nævnt formelle metoder til dette, både generelle testmodenhedsevalueringer og metoder, der er specialiserede i forhold til agil kontekst – og man kan naturligvis også definere sin egen metode og lave en uformel evaluering. Det sidste kræver dog, at man har ret tunge testkompetencer i organisationen, der både kan definere og drive en sådan evaluering.

TPI NEXT®-tilgangen

Jeg har ad mange omgange kigget på de forskellige formelle tilgange til testmodenhedsevalueringer gennem de sidste 10 år og har blandt andet fået en del praktisk erfaring med brugen af TPI NEXT® både i forhold til evaluering og den efterfølgende implementering af forbedring på basis af en sådan evaluering, så det er den jeg tager mit udgangspunkt i denne artikel. En af de væsentligste grunde til denne præference er desuden, at den er offentligt tilgængelig i sin helhed. Fundamentet kan findes i Bogen ”TPI® Next”, og du kan finde værktøjet til dokumentation af evalueringen på www.tmap.net. Samtidig er den er meget praktisk orienteret. Den fokuserer ikke på, at du skal opfylde specifikke niveauer, men kan tilpasses det forretningsmæssige fokus, og den findes i både en generel og bredt anvendelig udgave og i en udgave specialiseret i forhold til agil udvikling og test.

Der er reelt to forskellige tilgange til TPI® i dag. Den ene er den verdenskendte TPI NEXT®, som ofte genkendes via den modenhedsmatrice, der illustrerer resultatet af en analyse:

Den anden tilgang er en agil udgave, der er udviklet gennem de sidste år. Formatet på visningen ligner TPI NEXT® en del, dog er der ikke identificeret de fire modenhedsniveauer – der er i stedet fokuseret på modenhed på professional, team og organisatorisk niveau:

Princippet for de to tilgange er dog det samme; der arbejdes med key areas, check points og clusters i konteksten af matricen.

• Key areas: Test er delt op i 16 forskellige key areas som f.eks teststrategi, testmetode, testmiljø mv.
• Check points: For hvert key area er defineret en række spørgsmål (eller check points) – illustreret ved de enkelte felter pr. key area. Disse skal besvares med enten ja, nej eller ikke relevant. På basis af disse besvarelser kan man så tegne modenhedsmatricen som vist i de to tegninger.
• Clusters: Spørgsmålene er grupperet, efter hvilke der med fordel kan laves forbedringer for sammen – det kaldes ”clusters”. Disse er indikeret med bogstaverne i felterne.

Selve evalueringsdelen bør være en kombination af en række interviews med forskellige roller som f.eks. tester, udvikler, produktejer, kunde, testmanager, arkitekt, ledelsen, samt en analyse af de forskellige arbejdsprodukter, der relaterer sig til test og kvalitetssikring. På basis af dette udarbejdes resultatet, og både styrker og svagheder belyses i den efterfølgende gennemgang. Samtidig bør der komme en række forslag til forbedringer, og dette gerne i form af et overordnet roadmap. Output kan indeholde to forskellige aspekter:

• Forbedringstiltag: Tiltag, der fokuserer på forbedring af selve testprocessen
• Enablers: Tiltag, der ligger udenfor testprocessen, men hvor man kan drage fordel af hinandens bedste praksis. Dette kan være aktiviteter, der påvirker testprocessen, eller som testprocessen påvirker.

Resultatet af analysen samt forslag til forbedringer inklusiv et roadmap er det, du får i hånden efter en testmodenhedsevaluering. Så nu står du med en rapport og måske en præsentation – her er et billede af jeres nu-situation. Nu skal du så ”bare” i gang med at lave forbedringerne, at implementere roadmap. Og det er lige her, det går galt for mange – det er nemlig langt fra ”bare”; et hurtigt skud fra hoften er, at det at definere en proces er ca. 10-20 % af indsatsen, mens de 80-90 % er at implementere den og at få den integreret i den nuværende tilgang og få den til at være en del af kulturen i teams, trains, projekter osv. Men det er en helt anden historie. Et hurtigt tip er dog: lad være med at sætte jer ned og tegne hele den forkromede løsning og så efterfølgende gå i gang med at implementere det hele på bedste ”big bang”-vis. Bryd i stedet jeres roadmap ned i en masse små forbedringstiltag, og tag dem lidt efter lidt – og husk PDCA (plan-do-check-adjust/act).

Jeg har i den sidste måneds tid været i gang med en TPI® evaluering hos en kunde, og her blev vi enige om at vælge den fulde TPI NEXT®-tilgang, selvom de arbejder i en agil kontekst, da der var et ønske om en generel evaluering af tilgangen til test i organisationen. Vi har gennemført en analyse af nu-tilstanden gennem interviews og analyser og kunne inden juleferien levere rapporten til dem. Rapporten er dels en detaljeret gennemgang af analysen og det deraf følgende resultat, og dels en gennemgang af oplæg til forbedringstiltag, der kan løfte modenheden både i de enkelte teams og på tværs af organisationen – denne suppleret med oplæg til overordnet roadmap. Den står naturligvis ikke alene men bliver suppleret med en gennemgang for ledelsen i starten af det nye år. Dette for at give lejlighed, til at der kan stilles spørgsmål til resultatet, men også for at diskutere, hvad det næste logiske skridt så er for organisationen. Med det har de et klart billede af, hvor de står lige nu, og hvilke aktiviteter der kan igangsættes for at modne test i organisationen.

Hvis du er blevet nysgerrig efter at vide mere, er der nedenfor listet en række kilder op, som du kan dykke ned i. Du er også velkommen til at række ud til mig på telefon 4940 8552 eller e-mail gitte@key2quality.dk, så vi kan tage en diskussion om, hvad der er smart i din kontekst.

TPI NEXT®: Test Process Improvement (TPI) | TMap

TPI NEXT® bog: TPI® NEXT – Business Driven Test Process Improvement (ict-books.com)

TPI NEXT® agile whitepaper: Microsoft Word – Agile Test Practice Improvement 2.4.doc (tmap.net)

TMMI® modellen: TMMi Model – TMMi

TMMI® assessment method: About TMMi Assessment Method – TMMi

TMMI® bøger: Books – TMMi

PDCA: PDCA Cycle – What is the Plan-Do-Check-Act Cycle? | ASQ