Myt #3: Agila team behöver inga testare
Agila team där programmerarna utvecklar kod med testdriven utveckling, automatiserar tester, använder sig av parprogrammering och kontinuerligt bygger och testar sin kodbas verkar vid första anblicken inte behöva testare.
Programmerarna står för kvaliteten och koden är vältestad. Som testare kan man till och med mötas av skepsis och motstånd när man försöker närma sig ett sådant team. Kan det vara så att testaren verkligen är överflödig?
Är myten “agila team behöver inga testare” sann?
Ursprung
Myten är troligen primärt sprungen ur att framför allt äldre litteratur om agil utveckling fokuserar mycket på utvecklaraktiviteter. Test omnämns knappt ens i det agila manifestet eller bland de agila principerna.
I boken ”Extreme Programming Explained” av Kent Beck är parprogrammering, Continuous Integration och Test-First Programming, s.k. ”Primary practices”. I samma bok diskuteras även testarens roll, men mer som en bisats i ett senare kapitel.
I den officiella Scrum-guiden står följande att läsa: “Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis”. Därefter lär vi oss dock att “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”
I boken “Crystal Clear: A Human-powered Methodology for Small Teams” av Alistair Cockburn beskrivs testarrollen enligt följande: ”Tester and writer are likely to be rotating or temporary assignments. […] in many Crystal Clear projects there are only four to eight people, all programmers […]. Some teams may get use of a writer for periods of time, or have a dedicated tester working and even sitting with them.”
Den “klassiska”, eller i alla fall ofta citerade litteraturen, fokuserar inte jättemycket på testarens arbetsuppgifter, men man kan läsa mellan raderna att saker ska vara testade när allt kommer till kritan.
Att test på senare tid setts som en aktivitet snarare än en roll i det agila tvärfunktionella teamet bidrar också till myten. Om test bara är en aktivitet, kan den utföras av vem som helst. Alltså behöver agila team inga (dedikerade) testare.
Mytens ursprung och källor verka enkla att härleda och kanske känns svaret uppenbart för många.
Innan vi går vidare låt oss definera vad vi menar med ett agilt team. Först och främst är det ett team (till skillnad från en temporär projektgrupp). Teamet är litet, 5-9 personer, stabilt över tiden. Teamet jobbar med Scrum eller Kanban (eller annan agil metod/ramverk/process). Teamet är tvärfunktionellt och självorganiserande. Teamet har (oftast) nödvändig kompetens för att klara av att gå från ax till limpa vid utveckling. Teamet hålls själva ansvariga för att det de levererar håller hög kvalitet. I de bästa av världar är det även teamet som driftsätter det de byggt.
Så, nu när det var utrett – låt oss gå vidare. Stämmer myten att agila team inte behöver testare?
Approved… eller?
När vi började diskutera myten blev vi snabbt överens om att den var ”approved”, d.v.s. team kan klara sig utan testare om tillräcklig testkompetens finns i teamet och om kvaliteten får tillräckligt med fokus. Vi har själva erfarenheter av sådana team. Det centrala är att test behövs, men inte nödvändigtvis testare. Detta ledde oss in på funderingar kring vad en dedikerad testare tillför teamet.
Oavsett utvecklarnas testkompetens kommer testaren att vara expert inom testning och kvalitetssäkring. Testaren är troligtvis den som är mest erfaren inom kritisk granskning av den framtagna produkten. Detta kallar vi ”traditionell testning”, alltså verifiering av en färdig produkt/färdigt system efter att det anses ”färdigimplementerad”. Andra team-medlemmar än testaren kan givetvis också göra detta, men testaren är oftast bäst på det. Testaren har fokuserat på detta under lång tid och vässat sina färdigheter och verktyg för att göra det riktigt bra.
Testaren är också den som har mest erfarenhet av att testa ur ett black box-perspektiv utan att ta hänsyn till koden. Med detta menar vi att det är testaren som kommer på att rycka nätverkssladden vid test av en webbapplikation, och densamme skapar en partition på 1000 bytes när systemet gärna skriver till filer bara för att kolla hur systemet beter sig när disken är full.
Kravspecifikationerna är levande dokument som hela tiden förändras. Testaren tar ofta en roll att binda samman teamet, produktägaren och användarna och på så sätt är en ovärderlig teammedlem som fungerar som en brygga i arbetet med kraven. Testaren styr teamet i rätt riktning mot en korrekt implementation och hjälper till med att förtydliga kraven.
Slutligen är vår erfarenhet att testaren ofta har en bättre helhetsbild av systemet än utvecklaren. Den senare kan lätt ”fastna” inom en del av systemet och bli expert på en eller flera moduler, medan testarens granskande roll naturligt leder till att denne får en bättre överblick.
Förutom ovanstående, finns också mer specialiserade testarkompetenser: test av användarvänlighet och gränssnittsdesign, säkerhet och prestanda, för att nämna några. Dessa områden är tillräckligt stora i sig för att kräva dedikerad kompetens. Team måste stundtals utnyttja kompetens inom dessa områden, och det är vår erfarenhet att det är ovanligt att en säkerhets- eller användbarhetsexpert även knackar kod.
Sammanfattningsvis
Team där utvecklarna är duktiga på att säkerställa kvaliteten på sin egen kod med tekniker som testdriven utveckling, parprogrammering och Continuous Integration, och med ett intresse för test och med kvalitetsattityd kan klara sig utan testare. Dock berikas teamet väldigt mycket av att innehålla en eller flera testare. Dessa bidrar med expertkunskap inom test och gör teamet ännu mer tvärfunktionellt genom sina erfarenheter, perspektiv och mindsets. Ett tvärfunktionellt team förstärks av medlemmarnas olika kompetenser, expertisområden och verktygslådor.
Så, även om team kan klara sig utan testare behövs dom. De behövs för att stärka upp teamets kompetens, höja kvaliten, erbjuda fler infallsvinklar i designdiskussioner, planering och mjukvaruhantverket. Värdet av de synergieffekter som uppstår är ovärderlig.
Myten är med andra ord…
.
.
.
Utvikning: Vi utforskade också en relativt ovanlig roll – ”quality coach”. Utvecklare coachas av mer seniora utvecklare och arkitekter. Agila coacher smörjer processen. Varför skulle inte kvaliteten ha en egen förespråkare? En quality coach skulle arbeta med kvalitet på teamnivå, d.v.s. hjälpa teamen med att välja verktyg, infrakstuktur, teststrategier och coacha fram en kvalitetsattityd hos team-medlemmarna. En quality coach skulle således vara ett komplement till team som inte har testare i traditionell mening.
"Myter är som kamouflerad kollektiv visdom, det finns alltid något att lära.
Agila Myter BUSTED 
Välskrivet! Om slutsatsen blir ”det beror på” – vilket det brukar bli när man diskuterar dylika ting – så vill man gärna elaborera över vilka parametrar som spelar roll.
Ni tar upp att om tillräcklig testkompetens finns i teamet så kan man klara sig utan testare. Jag anser att den huvudsakliga parametern som avgör huruvida dedikerade testare behövs är hur säkerhetskritiskt systemet är. Det går tämligen utmärkt att utveckla en kaffebryggare utan dedikerade testare. Ska du däremot ta fram ett system för strålbehandling av patienter är behovet av dedikerade testare större. Mao ju mer säkerhetskritiskt ett system är desto större incitament för dedikerade testare.
Sedan kan man diskutera vilken kompetens som dessa dedikerade testare behöver, men det är en annan diskussion.
tack för en bra input, såklart beror det på vad man utvecklar, och som du säger tenderar behovet av dedikerade testare vara större vid komplexa och/eller kritiska system.
/Jagge
Riktigt bra genomgång, tack!
Jag tror särskilt på att dedikerade testare ofta har en bättre helhetsbild än utvecklare. Krav kan ibland vara otillräckliga och dessutom ändras när man arbetar agilt. Då är en testare som tar ansvar för helheten och analyserar krav värdefull för att leda utvecklingen rätt. Kravanalysen kommer naturligt när testfall ska designas och tillsammans med produktägare kan krav förbättras innan otillräckliga krav leder till buggar.
Jag tror jag håller med om det mesta av resonemangen. Skilj på roll, person och kompetens. Ju mer jag arbetar med mjukvaruutveckling desto mindre tror jag på de här fasta rollerna vi så gärna vill cementera – testare, programmerare, arkitekt, etc.
Förmågan att kunna tänka klart, annorlunda och med en större helhetsbild är oerhört värdefull, vem som än besitter den.
Visst är det så, man har tagit ett stort steg mot agilt när man börjar diskutera och tänka skiljt på person, kompetens och roll. Tyvärr så tycker vi fortfarande om att prata om roller och inte kompetens. Men det blir det snart ändring på:)
/Jagge
Tackar för en fin analys!
Jag håller till viss del med om slutsatsen ”det beror på” – nej förresten, det gör jag faktiskt inte alls även om jag skulle vilja 😉 – kanske som teoretiskt spekulerande men inte i praktiken om systemet inte är ett litet hack eller är extremt litet och okomplext.
Jag tror att det alltid behövs någon som känner att sin uppgift först och främst är att granska systemet ur ett användar-, drift- och underhållsperspektiv.
Jag tror att det är svårt (rent av omöjligt?) att ha det perspektivet som utvecklare. Jag tror att det behövs en uttalad roll som testare för att verkligen ta sig an det sättet att granska systemet. Framför allt är det ett naturligt motsatt mind set hos en utvecklare och en testare. En utvecklare vill helst inte hitta fel i det han har gjort, en testare vill inget hellre än att hitta fel! Det tror jag gör att en testare kan hitta andra fel än de en utvecklare skulle hitta. Likväl som utvecklaren hittar fel som testaren aldrig skulle hitta.
För att få ett system med så bra kvalitet som möjligt är det viktigt att alla i teamet testar utifrån sin vy – och egentligen är det inte begränsat till teamets medlemmar, men det är ofta det som är mest praktiskt genomförbart och tillräckligt bra. Det klarar inte en person som har en uttalad roll som testare lika lite som att en bilbesiktningsman skulle klara av att säkra upp att det tillverkas bilar av hög kvalitet. De kan bara upptäcka vissa kritiska fel på bilar. Ändå betraktas de som nödvändiga.