Testaren som agil coach – från kval till kvalitet

Det agila projekttåget är i rullning. Men det går för långsamt. Något i projektet har sannolikt gått snett, men ingen verkar veta vad som behöver göras. Det är nu vi agila testare måste ta plats som coacher - i förarsätet. Här kommer argumenten till varför.

Du sitter som ensam testare i ett anonymt mötesrum med ledningen. Du kan svagt höra ljudet från det agila projekttåget strax utanför rummet. Det rullar redan. Ledningen förklarar för dig att projektet överväger att ta in en testare. På frågan om vilken utvecklingsprocess som används händer plötsligt något märkligt. Ledningens annars så självsäkra attityd förbytts till flackande ögon, obekvämt skruvande på stolen, och svaret blir: "Vi arbetar, hm, agilt, ungefär", eller kanske "Vi jobbar scrum-ish". Känner du igen dig? Du är inte ensam.

Om projektet hade gått enligt plan hade antagligen självsäkerheten varit i topp, men nu är det inte så. Något skaver på självförtroendet. Något i projektet har högst sannolikt gått snett. Tåget rullar långsamt. Det är här du som erfaren agil testare måste marknadsföra dig inte bara som testare, utan även som agil coach!

Varför är då en erfaren agil testare bra på coachning i ett stormigt projekt frågar man sig, kanske rentav lika bra som en renodlad projektcoach? Svaret är enkelt. Testdesign och exekvering kommer ofta in som aktiviteter i slutet av en lång process. Alla problem på vägen, från otydliga önskemål hörda på en kundträff till trasslig kod, ansamlas och synliggörs likt en perfekt storm hos testaren. Stormen avtar inte, utan blir allt värre i takt med att den tekniska skulden och berget av buggar ökar. De flesta agila testare är frispråkiga, envisa och ryggar inte för en kamp i motvind. En testare i denna situation ger inte upp sin kamp för förbättringar i  första taget. Är problem självupplevda och dagliga kommer i alla fall inte testaren att låta dem sopas under mattan i första taget!

Den som varit mitt i stormen ett flertal gånger är en person värd att lyssna på. Sannolikt har testaren erfarenhet sedan tidigare, och kan träffsäkert identifiera både orsaker och beprövade förslag att coacha projektet med för att rida ut stormen även denna gång!

Låt oss ta några exempel på vanliga orsaker till stormiga projekt :

·     Otydliga krav. Den erfarna agila testaren bemöter ofta detta med önskemål att plocka följande verktyg ur den agila verktygslådan:  Grooming-sessioner, placering nära utvecklarna, samt krav på godkända acceptanskriterier före testning.

·     Dålig kvalitet. Testare tröttnar snabbt på blockeringar och ständiga regressionstester (samma testfallskörningar om och om igen!) för att testa att de ideliga buggfixarna inte haft någon skadlig inverkan. Du som testare driver i en sådan situation antagligen på för att refaktorisering inplaneras, att Definition of Done (DoD) stramas åt, och att projektet avsätter resurser för analys och eliminerande av huvudorsakerna så att din och dina kollegers uthållighet, humör och självkänsla förbättras.

·     Dålig kommunikation. Agila testare kan inte göra sitt jobb utan bra informella kontakter med utvecklare i en atmosfär av ömsesidigt förtroende. Sådan kommunikation kan vara en bristvara i projektet. Den stressade agila testaren som ofta står utan skriftlig relevant information har dock inget val utan måste driva på för att skapa sådana informella kontaktytor. Detta sätter ofta tonen för resten av projektet som därefter på allvar börjar anamma ett mer agilt sätt att arbeta och kommunicera.

·     Riskhantering. En del tror att riskhantering kan man bortse ifrån i agila projekt då den genom någon form av magi ändå görs. Tyvärr är sanningen att magi endast existerar i sagoböckerna och att denna inställning kommer att straffa sig. I verkligheten är testaren en vital del i agil riskhantering. Testaren genomför varje dag riskanalys genom att fråga utvecklarna om risker - allt för att göra kommande tester i rätt ordning och med rätt omfång (i den oftast riskbaserade testningen). Genom att identifiera och testa områden med risk, lär man känna riskerna bättre och kan göra en mer korrekt bedömning av dessa, vilket gagnar hela projektet. Detta risktänk smittar av sig till övriga i projektet.

Detta var bara några exempel på hur den agila testaren ofta per automatik och utan att reflektera djupare hjälper till att coacha och få det agila projekttåget på banan igen. Varför pratas det då inte mer om detta? Jag tror att vi testare helt enkelt är för dåliga på att marknadsföra oss själva. Handen på hjärtat, vet de som håller i pengarna om att vi gör så mycket mer än att bara skriva felrapporter? Gör de inte det har vi faktiskt hittat ett nytt fel - hos oss själva.

Varför inte sätta upp en mognadsstege liknade CMMI på den agila projekttavlan eller bifoga den till ledningen i din månatliga testrapport och visa på de stegvisa förbättringar test tillför projektet? Gör du det rätt, så sitter ni nog mångdubbelt fler testare i det där anonyma mötesrummet nästa gång. Ledningen kommer att få en insikt och ett helt annat förtroende för utvecklingsprocessen då test öppnat och visat på innehållet i den agila verktygslådan genom sina förbättringsinitiativ.

Kan då något gå fel då med agil coachning som bedrivs av testare?

Ja, så klart. I retrospektivmöten kan problem som identifierats av testare konsekvent röstas ned i demokratisk anda (ofta är utvecklarna i majoritet och röstar kanske enbart på ”sina” isolerade problem). Risken är att viktiga processförbättringar därmed fördröjs "tills dess att snöbollen blivit en lavin".

Hm, detta låter ju inte enkelt att lösa, men låt oss återgå till att tänka på tåget. De flesta tåg har faktiskt passagerarna indelade i olika klasser, kan vi kanske klassa oss testare som lite högre stående och tillåta oss förmånen att alltid få igenom åtminstone en av våra käpphästar på varje retrospektivmöte? Är vi inte värda det?

Svaret på det, kära läsare, tar vi en annan gång i en diskussion om testarens demokratiska värdegrund och om verkligen alla är jämlika eller om testare faktiskt är lite mer jämlika än andra. Ni får gissa er till svaret än så länge.

/Björn Rux,

Test Engineer

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här