Från vattenfall till Scrum

Tillbaka från semestern och dags att återuppta arbetet med att få till en väl fungerande agil testverksamhet i ett projekt som efter cirka två års utveckling övergav vattenfallsmodellen till förmån för ”Scrum”.

Ingen av oss som arbetar med testning i projektet hade från början några egentliga erfarenheter av testarbete i agila projekt. Så det var bara att kavla upp skjort ärmarna och sätta igång att leta information, referenser och dokumentation på nätet och i böcker.

Vi hittade en del generell och övergripande information men tyvärr hittade vi inte mycket matnyttigt annat än att det är viktigt med automatisering..

Så fram med tänkarhatten och försöka få till ett fungerande scrum-upplägg med 4-veckors sprintar där vi fåtalet testare både förväntas fungera som ”sprint testare” samt utföra regressionstest under perioden. Resultatet blev ett upplägg med tre veckors utveckling samt en veckas manuellt regressionstest för oss testare (vilket egentligen inte var tillräckligt men löstes med riskbaserad testning) medan programmerarna städade kod.

Vi insåg redan från början att en veckas manuell regressionstest inte var optimalt i en agil miljö men då automatiserade tester (annat än unittester) inte har prioriterats i projektet från start så hade vi inte så mycket att välja på. Det tar ju ett tag att komma ifatt med implementation av automatiserade tester när projektet redan har pågått en längre tid…

Efter att ha kört detta upplägg skarpt ett tag dök det upp en del punkter…
 

• Inte populärt med ”regressionstestvecka”, varken från testare, programmerare eller produktägare.
• Svårt för oss testare att få vara med från början och diskutera/påverka implementationsförslag.
• Testdokumentationen blev väldigt bristfällig om den ens existerade vilket gjorde att vi inte kunde gå tillbaka och se vad och hur vi hade testat samt att vi hela tiden var tvugna att börja om från början.

Vi har nu börjat arbetet med att korta ner tiden för regressionstest genom att lägga mer fokus på automatiserade regressionstester, men vi har ändå en lång väg kvar att vandra. En annan åtgärd för att korta tiden för regressionstest har varit att ”tvinga” programmerarna att hjälpa till att exekvera regressionstesterna, vilket även har fått ”bieffekten” att programmerarnas generella förståelse för applikationen har förbättrats (och faktiskt även uppskattas av vissa programmerare).

Dock får vi fortfarande slita för att få vara med och ta fram och påverka implementationsförslag utifrån de User Stories vi tilldelas. Men det är bara att bita i.

Det verkar i varje fall som att man börjar få upp ögonen för att vi som testare faktiskt kan bidra på detta tidiga stadium…

När det gäller testdokumentation har vi börjat införa en del idéer från xBTM, speciellt testplaner i form av mind maps. Vårt nästa steg inom detta område är att genomföra ett antal workshops för att kombinera xBTM med de förutsättningar vi har i projektet och för hoppningsvis få ut den optimala testprocessen för just vårt projekt.

Jag avslutar med några lärdomar som jag hoppas och tror att ni kan ha nytta av:
 

• Våga testa olika angreppssätt och var inte rädda för att göra justeringar för att hitta fram till den ”optimala” lösning för just er.
• Kräv att få vara med från start när en ny user story påbörjas i teamet.
• Visualisera testplaner och tester med mind maps och modeller samt delge dessa till programmerarna (Ta en titt på xBTM om du inte redab har gjort det).
• Fokusera på att automatisera så mycket tester som möjligt redan från början i projektet.

Frågor, synpunkter eller kommentarer tas tacksamt emot.

Micke Ulander
mikael.ulander@addq.se
072-300 42 95