Testledelse i endring: Moderne utviklingsmetoder utfordrer testlederrollen

Måten vi utvikler IT-systemer er i endring. Det er ikke lenger slik at vi har alle kravene til løsningen klare idet vi starter utviklingen. Det skal leveres hyppigere enn tidligere, og graden av kompleksitet knyttet til IT-systemene øker. Smidige metoder som Scrum og Kanban, DevOps og stadig hyppigere leveranser utfordrer den tradisjonelle testlederrollen mer enn noen gang.

Samtidig er sluttbrukernes forventninger til brukervennlige og stabile løsninger høyere enn tidligere.

Hvordan påvirker dette måten vi tester og kvalitetssikrer systemene på? Hva med testlederrollen? Hvordan påvirkes den av disse endringene?

La oss starte med utgangspunktet og se hvordan kravene til rollen har endret seg over tid.

Hva er egentlig test og testledelse?

ISTQB Norge definerer test som:

• Å finne feil – Programvare blir utviklet av mennesker. Dermed vil de (nesten) alltid inneholde feil. Testingen skal finne eventuelle feil før produktet blir tatt i bruk.
• Å demonstrere kvalitet – Testing skal vise at kvalitetskrav er oppfylt – men hva betyr egentlig kvalitet? Her gjelder to aspekter:
• At produktet oppfyller spesifiserte krav. Det vil si at programvaren fungerer og at egenskaper som blant annet svartider, kapasitet, brukbarhet, og sikkerhet er oppfylt i tilstrekkelig grad.
• At produktet oppfyller kundens og brukerens behov.

Testleders rolle handler om å planlegge, lede, overvåke og rapportere testgjennomføringen – nettopp for å finne feil og demonstrere kvalitet.

Fossefallsmodellen – manuell testing separat fra utviklingsprosessen

Tradisjonelt har testlederrollen handlet om å lede arbeidet med test av IT-løsninger. Oppgavene er hovedsakelig administrative og handler om å utarbeide teststrategier, testplaner og testrapporter basert på definerte krav, lede testteamet gjennom å delegere testoppgaver og følge med på testgjennomføringen og innrapporterte feil.

I fossefallsmodellen blir testing sett på som en fase i utviklingsløpet. Testledelse og testing utføres ofte av et separat testteam. Testleder eier teststrategien og blir sett på som ansvarlig for kvalitet. Testingen er stort sett manuell, har fokus på funksjonalitet og gjennomføres ofte etter at programvaren er fullt utviklet og like før den blir produksjonssatt.

Fossefallsmodellen gjør at det tar tid å levere programvare. Egne driftsmedarbeidere er ansvarlige for å sette leveransene i produksjon, ofte så sjelden som et par ganger i året.

Agile metoder – testerne blir en integrert del av utviklingsteamet

Da den smidige utviklingsmodellen oppstod tidlig på 2000-tallet skapte den en endring i utviklings- og testmetodikken, samt for releasefrekvensen. Programvare ble utviklet iterativt og trinnvis. Scrum, som er en smidig utviklingsmetode, ble raskt populær.

I den smidige utviklingsmodellen blir utviklingsarbeidet brutt ned i en rekke korte iterasjoner, som vanligvis varer to til fire uker. Hver iterasjon vil skape en ny leveranse med forbedret kvalitet ved å legge til nye funksjoner eller forbedre eksisterende funksjoner.

Ved innføring av smidig utviklingsmetodikk ble testerne en integrert del av utviklingsteamet, og testing foregikk parallelt med programvareutviklingen, snarere enn en fase på slutten av hver leveranse. Testaktivitetene ble et felles ansvar i utviklingsteamet. Rollen som testleder er ikke en del av smidig utviklingsmetodikk, men testlederens oppgaver er definitivt det. Det er fremdeles behov for et teammedlem som tar ansvar for å lede arbeidet med å finne feil og å kontrollere at produktet har ønsket kvalitet.

DevOps – automatisert og kontinuerlig testing gjør sitt inntog, men behovet for en testleder består

DevOps og hyppige leveranser utfordrer den tradisjonelle testlederrollen mer enn noen gang. Mens smidig utviklingsmetodikk opererer med to til fire uker mellom hver leveranse, tar DevOps det ett skritt lenger og opererer med flere leveranser hver dag. Dette gjøres gjennom å ta i bruk nye utviklings- og driftsplattformer som legger til rette for økt grad av automatisering i alle ledd.

Tradisjonelt har utvikling hatt fokus på å levere mest mulig ny funksjonalitet, mens drift har hatt fokus på sikker og stabil drift. Dette skaper fort en interessekonflikt.

DevOps handler først og fremst om å rive ned skillet mellom utvikling og drift, samt å sette fokus på felles mål for brukernes beste. For å oppnå dette etableres autonome produktteam som tilføres all kompetanse som er nødvendig for å utvikle, forvalte og drifte IT-systemene.

Utviklingssyklusen i DevOps er illustrert i denne skissen:

Det kan være vanskelig å se hvor testlederen passer inn i en modell hvor testing ikke er nevnt i det hele tatt. Svaret er at test er viktig i hvert eneste punkt i denne modellen.

Testing i DevOps spenner over hele leveransens livssyklus. Fokuset er ikke lenger bare på gjennomføring av en funksjonell test, men blir i større og større grad rettet mot monitorering og analyse av stabilitet, ytelse, sikkerhet og brukeropplevelse.

Til å veilede teamet i hvordan man skal sikre kvalitet i leveransene, og til å styre og lede denne testingen, er det behov for en testleder. For å kunne ivareta denne type testlederrolle, krever det at testlederen utvikler en helt ny kompetanse. Hun må i tillegg til de tradisjonelle testferdighetene også utvikle sin kunnskap om utviklingsplattform, verktøy og automatisering. Der hvor man tidligere utførte manuell strukturert testing, vil fokus nå være på automatisert testing.

Selv om det meste av testingen i DevOps vil gjennomføres gjennom automatiserte testscripts, og man ikke lenger bruker begreper som systemtest og akseptansetest, vil det fremdeles være behov for å involvere sluttbrukerne for å teste om løsningen dekker deres behov og lever opp til deres forventninger. Dette krever ytterligere en ny type kompetanse hos testlederen. Der hvor sluttbrukerne tidligere utførte manuell testing etter strukturerte testscripts, vil det nå være nødvendig å lede disse gjennom utforskende tester hvor de gjennom sin domenekompetanse utfordrer og tester IT-systemene, uavhengig av leveransesyklusen.

Utviklernes automatiserte tester sammen med sluttbrukernes utforskende testing vil kunne gi testlederen og produktteamet et bilde av leveransens kvalitet.

Oppsummert vil jeg si at selv om det er tydelig at testlederrollen er i endring, og at det kreves nye ferdigheter i rollen, er det ingen tvil om at det er behov for kompetanse på test og testledelse i IT-utviklingsprosjekter. For å sikre at utviklingsteamet har tilstrekkelig fokus på kvalitet og brukernes behov, bør teamet alltid ha et medlem med dybdekompetanse på testledelse, testmetoder og testteknikker, uavhengig om man velger fossefall, smidig eller DevOps som metode.