Skal man lykkes med prosjektet, så må man lykkes med testingen. Og skal man lykkes med testingen, så må man engasjere alle de gode kreftene man har til rådighet.
Men det viktigste er tross alt å få inn kvalitetsmentaliteten i det daglige arbeid, slik at at dette blir en integrert del av måten å jobbe på gjennom hele sprintforløpet / utviklingsløpet.
Jeg vil i denne artikkelen beskrive en smidig setting, men overnevnte setning gjelder for de fleste, kanskje alle, typer utviklingsmetodikker og -prosesser. Jeg har også valgt å benevne teamet i entall, men dette er selvfølgelig også relevant i prosjekter med flere utviklingsteam. Man kan etterstrebe denne måten å jobbe på i ett, flere eller alle teamene i prosjektet.
Det finnes mange måter å rigge et smidig prosjekt på, men i alle tilfellene legges det et visst testansvar på utviklingsteamet. I virkelig autonome team har teamet ansvaret til og med systemtest innenfor hver sprint. Dette er ofte en krevende øvelse, spesielt når det som oftest er fokus på å levere flest mulig brukerhistorier. Dermed er det fort gjort at man i løpet av sprinten setter av for lite tid til test. Men det man da ofte erfarer, er at man leverer med for høy risiko og ender opp med å bruke mye av utviklingskapasiteten i de kommende sprintene til feilretting.
Tradisjonelt sett er det vanlig å ha en testleder som planlegger, skriver og gjennomfører testingen. Testleder gjør dermed testingen, mens utviklerne lager løsningene. Det er ganske vanlig at man kjører såkalt testdrevet, ved at utviklerne lager automatiserte enhetstester som skal verifisere at implementert kode er riktig. Men testing etter det overlates til testleder.
Så hvordan får man til dette?
Man må få til en holdning i teamet slik at hele teamet er med på test. Og at man begynner å jobbe med test helt fra starten av i hver sprint. Det gjelder alle testoppgaver innenfor mandatet til teamet. Test lead påser at alt testarbeid blir gjort, men gjør på ingen måte alt testarbeid selv.
Test må inn i sprintestimeringen og sprintplanleggingen. Testaktiviteter må få egne lapper pr brukerhistorie, f.eks.:
- Skrive systemtestcaser
- Basert på brukerhistorier, testbetingelser og akseptansekriterier. Ofte så vil det her være behov for avklaringer som igjen gir øket forståelse for hva som ønskes levert. Til nytte i både test og utvikling.
- Gjøre løpende utforskende test i sprinten etterhvert som funksjonaliteten legges i testmiljøet for utvikling.
- Kjøre systemtestcaser i systemtestmiljøet.
- Dette er den formelle systemtesten i slutten av hver sprint som danner grunnlaget for suksessen til sprintdemo og er med i underlaget for kontrollpunktstestingen.
- Kjøre regresjonstester. Det beste er at man har et automatisert opplegg for dette. Men det kan likevel være nyttig i slutten av hver sprint å kjøre en begrenset manuell regresjonstest av den aller viktigste funksjonaliteten.
Disse lappene må opp på sprinttavla og kan plukkes blant alle medlemmene i teamet. Man må derfor få formidlet tydelig at det ikke er bare test lead som skal plukke disse lappene. Når de henger på tavla blir det veldig synlig hvilke oppgaver som må gjøres som neste. Bl.a. “skrive testcaser” gjør seg ikke så godt i kolonnen for ikke påbegynte saker etterhvert som tiden går.
Det er min erfaring at hvis test lead setter i gang med utforskende testing, med mål om å fjerne de fleste feil før brukerhistorien går inn i systemtest, så er det en oppførsel som har en tendens til å spre seg. I de tilfellene så blir systemtesten først og fremst formelt å verifisere at funksjonaliteten fortsatt virker når man skal kjøre demo. Fordi de fleste feilene er allerede funnet og rettet før systemtesten har begynt. Rapportering og retting av feil funnet i den utforskende testingen gjøres vha et en tabell på en wiki-side.
Eksempel på wiki-tabell brukt til å rapportere og følge opp bugs og avvik som oppdages i uformell test før systemtest:
Sakene som ikke rettes og verifiseres før systemtest er startet, må rapporteres som bugs i feilrapporteringssystemet.
Det er viktig få opp bevisstheten for at det å skrive systemtestcaser er med på å øke forståelsen for den brukerhistorien man skal implementere. Så denne aktiviteten kan, allerede før man begynner implementeringen, være med på å øke kvaliteten på både krav og implementasjon.
I en organisasjon der det finnes testleder både på kunde og leverandørsiden er det meget viktig at kundens testleder backer leverandørens testleder i arbeidet med å bevisstgjøre og engasjere hele teamet i kvalitetsarbeidet.
Ekstraservice – testaktiviteter som kan arrangeres på utsiden av sprintene
I tillegg til det pågående iterative arbeidet kan man arrangere eventer og arrangementer der man ønsker å oppnå at man dykker enda dypere ned i kvaliteten, f.eks. ved å gjøre det lystbestont.
Man kan arrangere “testcamp“eller “bughunt“, f.eks. en halv dag hvor designere tester hverandres design, android utvikler tester iOS og motsatt. Kundefront tester usability, prosjektleder gis et område av scope som skal testes, marked får beskjed om “make it break”.
Man kan med fordel legge det opp som en konkurranse. Med heder, ære og premier.
Etter at alle utviklingssprintene i en delleveranse er fullført, kan man planlegge inn en “herdingssprint”. Dette er en sprint for å fullføre feilretting og gjøre en helhetlig regresjonstest av ny og gammel funksjonalitet. En fare med slike herdingssprinter er at man bruker den til å øke scopet og levere ny funksjonalitet. Det er viktig at dette unngås. Dette er kun et kvalitetshevende tiltak etter at all kontrollpunktstesting er kjørt, men før akseptansetesten skal i gang.
Avslutningsvis
Testcamps og lignende tiltak fungerer bra til bl.a. å promotere testing, men bør helst være et tillegg til et vellykket testopplegg, ikke en kvikkfiks for å bøte på manglende testarbeid underveis i sprintene. Det kan være et vellykket avbrudd i det daglige arbeidet, men det er viktig at det ikke gir deltagerne inntrykk av at dette på noen måte er et tilstrekkelig bidrag. Men det kan f.eks. skape en konkurransesituasjon mellom utviklingsteam som kan gi økt fokus på å levere god kvalitet. Ingen liker at et annet team finner feil i den delen av løsningen man selv skal være ekspert på.
