Prosjektet kjører smidig. Sprintene ruller, demoene imponerer, og backloggen krymper. Men testingen? Den ligger som en egen oppgave nederst i hver sprint, og skyves til neste når tiden blir knapp. Etter åtte sprinter har teamet bygget mye og testet lite.
Dette er fossefall i smidig innpakning: utviklingen er iterativ, men testingen er fortsatt en fase som kommer «etterpå». Resultatet er opphopede feil som oppdages sent, akkurat det smidig metodikk skulle forhindre.
Her får du en praktisk gjennomgang av testgjennomføring i smidige prosjekter: hva som faktisk endrer seg fra tradisjonelle prosjekter, hvordan du legger testarbeidet inn i sprintene, og feilene som går igjen.
Hva er testgjennomføring?
Testgjennomføring er aktiviteten der planlagte tester faktisk utføres: testtilfeller kjøres, resultater sammenlignes med forventet oppførsel, og avvik registreres og følges opp. Der teststrategien beskriver hva som skal testes og hvorfor, er testgjennomføringen selve utførelsen, med testmiljøer, testdata og mennesker som gjør jobben.
I tradisjonelle prosjekter er testgjennomføring en egen fase mot slutten. I smidige prosjekter er den en løpende aktivitet i hver eneste sprint. Det høres ut som en liten forskjell. I praksis endrer det hele måten testarbeidet må organiseres på.
Fossefall vs. smidig: hva endrer seg i testarbeidet?
I et fossefallsprosjekt kunne testlederen planlegge en dedikert testperiode: seks uker med systemtest, tre uker akseptansetest, ferdig definerte testtilfeller klare på forhånd. Den luksusen finnes ikke i smidige leveranser.
I smidige prosjekter testes det som bygges, mens det bygges. Testerne jobber i teamet, ikke etter det. Ifølge pensum fra ISTQB Norge tester alle i et smidig team, også utviklerne, og omfattende testautomatisering er en forutsetning for å holde tritt med endringstakten.
For testlederen betyr det en ny rolle: mindre detaljplanlegging av én stor testperiode, mer løpende koordinering av testaktiviteter på tvers av sprinter, team og leverandører. Kvalitetsansvaret forsvinner ikke i smidig. Det flytter seg bare tettere på utviklingen.
Slik gjennomfører du testing i sprinter
Legg testkrav inn i Definition of Done
Den enkleste forsikringen mot skjøvet testing: en oppgave er ikke ferdig før den er testet. Definition of Done bør kreve at nye funksjoner har kjørende tester, at regresjonstestene er grønne, og at kjente feil er registrert med alvorlighetsgrad. Da kan ikke testingen skyves uten at det synes.
Bygg regresjonstesting på automatisering
Hver sprint endrer kode som fungerte i forrige sprint. Uten regresjonstesting oppdager du først i produksjon at endringen ødela noe annet. Og uten automatisering rekker du ikke regresjonstesting i hver sprint: manuell gjenkjøring av alle viktige flyter tar lengre tid enn sprinten varer.
Prioriter automatisering av de kritiske flytene først, slik vi også anbefaler for integrasjonstesting: betaling, innsending, pålogging og oppslag mot eksterne systemer. Målet er ikke hundre prosent dekning. Målet er at teamet tør å endre kode uten frykt.
Bruk utforskende testing som supplement
Automatiserte tester finner feilene du har tenkt på. Utforskende testing finner de andre: en erfaren tester som bruker løsningen slik ekte brukere gjør, med rare inndata, avbrutte flyter og utålmodige klikk. Sett av tid til dette i hver sprint, gjerne med tidsbokser og et tydelig fokusområde per økt.
Avklar hvem som eier kvaliteten
At alle tester, betyr ikke at ingen har ansvar. Noen må eie helhetsbildet: hvilke områder er godt dekket, hvor er risikoen størst, hva er status på tvers av teamene? I mindre prosjekter kan det være en erfaren tester i teamet. I større leveranser med flere team og leverandører trengs dedikert testledelse som koordinerer på tvers.
Vanlige feil i smidig testgjennomføring
Tre mønstre går igjen i prosjektene vi ser. Testing behandles som en «neste sprint»-oppgave, og gjelden vokser stille til den eksploderer før lansering. Regresjonsstrategien mangler, så hver sprint tester bare det nye, aldri det gamle. Og testmiljøene henger etter: teamet er klart til å teste, men miljøet mangler data, integrasjoner eller riktig versjon.
Aspiria har levert testledelse i snart 30 år, i bank, offentlig forvaltning og telekom. I smidige leveranser i offentlig sektor ser vi ofte at testmiljøene er den reelle flaskehalsen: sprintene er på to uker, men å få oppdatert testmiljøet tar tre. Da hjelper det lite at teamet jobber smidig. Miljøkabalen må planlegges like tidlig som teststrategien.
Ofte stilte spørsmål om testgjennomføring i smidige prosjekter
Når i sprinten bør testingen skje?
Løpende, ikke som en egen bolk på slutten. Testene for en oppgave skrives og kjøres mens oppgaven utvikles, og oppgaven er ikke ferdig før testene er grønne. Slutten av sprinten brukes til regresjonstesting og utforskende testing, ikke til å begynne på testarbeidet.
Trenger smidige team en testleder?
I små prosjekter med ett team kan kvalitetsansvaret ligge hos en senior tester. I leveranser med flere team, leverandører eller strenge dokumentasjonskrav trengs en testleder som koordinerer på tvers og eier det samlede kvalitetsbildet. Aspirias erfaring er at behovet øker med antall parter, ikke med metodevalget.
Hvor mye av testingen bør automatiseres?
De kritiske flytene og alt som må regresjonstestes hver sprint. En vanlig fordeling er automatiserte tester som grunnmur, med manuell utforskende testing på toppen. Automatiser der repetisjon gir verdi, test manuelt der menneskelig vurdering gjør det.
Hva er forskjellen på testgjennomføring og testledelse?
Testgjennomføring er å utføre testene: kjøre testtilfeller, registrere resultater og melde avvik. Testledelse er å planlegge, koordinere og styre hele testarbeidet: strategi, ressurser, miljøer, fremdrift og rapportering. Testgjennomføringen er en del av det testledelsen styrer.
Kvalitet bygges i sprinten, ikke etter den
Smidig testgjennomføring handler om én ting: å flytte testingen så tett på utviklingen at feil oppdages mens de fortsatt er billige å rette. Verktøyene er kjente: testkrav i Definition of Done, automatisert regresjon, utforskende testing og et tydelig kvalitetsansvar.
Sliter prosjektet ditt med testgjeld som vokser sprint for sprint? Ta kontakt med oss for en uforpliktende prat om hvordan testarbeidet kan komme på skinner.