Från Ad-Hoc testning till ordning och reda med xBTM.

Nu har det gått snart fyra månader sedan mitt förra blogginlägg, ”Från vattenfall till scrum” och det är nu hög tid att följa upp det jag då skrev.

Strax efter blogginlägget genomförde vi vår första workshop inom ämnet xBTM.

xBTM, som är en metod att kombinera de utforskande testmetodikerna SBTM (Session-Based Test Management) och TBTM (Thread-Based Test Management). Metoden är framtagen av Michael Albrecht här på AddQ och syftar till att skapa kontroll och struktur kring testarbetet i agila projekt samtidigt som den uppmuntrar kreativitet och flexibilitet.

Kortfattat innebär SBTM att man delar in sina utforskande tester i tidsbestämda sessioner vilka i sin tur innehåller en liten del testdesign och en större del testexekvering. Testdesignen och utfallet från sessionen dokumenteras i en ”test charter” där man kortfattat beskriver vad som testats och hur det har testats. Här har man också möjlighet att skapa spårbarhet mot sina krav.

I kontrast till SBTM är TBTM betydligt mer lättviktig och bygger på testidéer dokumenterade i till exempel en mind map. Här använder man sedan sin mind map till att följa sin progress samt rapportera sina resultat.

Som läxa inför första workshopen fick vi i uppdrag att ta fram effektmål som beskriver vad vi vill uppnå med införandet av xBTM. Bara denna övning i sig var väldigt nyttig då vi blev tvugna att föra diskussioner med både produktägaren samt företagets IT-avdelning.

Under vår första workshop pratade vi om xBTM i allmänhet samt hur xBTM passar in i just vårt projekt. Vi genomförde även ett arbete med att definiera ”Key Areas” i applikationen. Med oss från workshopen fick vi ett antal aktiviteter att jobba med till det var dags att träffas igen, bland annat att definiera vad begreppet risk betyder för oss.

Den andra workshopen ägnades åt diskussioner runt mallar, verktyg och rapportering samt testdesign med hjälp av modeller. En vanlig missuppfattning i den agila världen är att man inte ska dokumentera något över huvud taget.

Men tittar man i det ”agila manifestet” så framgår det att man mycket väl kan dokumentera men att man inte ska dokumentera mer än vad som verkligen är nödvändigt. Hur som helst så kom vi fram till att vår testdokumentation skall bestå av ”testplan”, ”progress rapportering” och ”testrapport” i samma dokument och detta i form av en mind map, ”testmodeller” samt charters och testbevis.

Sista tillfället ägnades åt en sammanfattning av vilka förbättringar vi hittills infört, uppföljning mot våra definierade effektmål samt hur vi ska forsätta utveckla oss själva och projektet.

Så här i efterhand kan vi konstatera att den tid vi har lagt ner på dessa workshops och förbättringsarbetet där mellan har varit väl investerad. Förutom att vi har fått ordning på vårt testarbete har vårt engagemang lett till positiv återkoppling från både programmerare och produktägare.

Den absolut största utmaningen vi har kvar att tackla är att få ordning på våra regressionstester. I dagsläget har vi väldigt lite automatiserat och vid varje ”release tillfälle” väldigt lite tid till manuella tester..