Forfatter: Lena Jonhaugen, Promis Qualify
I blant hører vi motforestillinger mot bruk av en dedikert testleder i IT-prosjekter, i denne artikelen har vi plukket ut noen av disse som vi vil se nærmere på.
Topp seks grunner til å (ikke) leie inn en testleder
* De stiller bare spørsmål og er så kritiske
* De påpeker bare feil og blir aldri fornøyde. Dessuten løper de alltid kundens ærend
* Dessuten bruker vi smidige metoder og TDD – utviklerne klarer dette fint på egenhånd så da trenger vi ikke testleder
* Og så har vi DevOps så dette går av seg selv – vi trenger ikke noe kvalitetspoliti!
* Testledere er så dyre å ha gående
* Og prosjektlederen kan ta seg av resten
“Testleder stiller så kritiske spørsmål”
Få kjenner kravene og løsningen som helhet bedre enn testleder og ofte arkitekt, som tradisjonelt jobber mye sammen. Vi arbeider begge med å se løsningen som helhet, og som testleder planlegger vi for test av dette. Men vi går også ned i detaljer i planleggingen. Vi drøfter hvert enkelt krav og funksjon for å vurdere kvaliteten, gyldigheten og testbarheten av dem. Dette gjelder både tekniske og funksjonelle krav, og vi kan gi viktige innspill om konsekvenser av valg og endringer. Dette mens løsningen er under utvikling, men også ved rettelser, endringsordre og annet også i forvaltning.
Grunnen til å stille spørsmål er fordi vi forventer kvalitet, dette er meislet inn i ryggraden vår, og det er den vi holder strak gjennom prosjektene. Og dette er bakgrunnen for at vi aldri går tom for spørsmål. Men overdrevent fokus på dette fører bare til dårlig stemning. Det vil føles som om testleder er ‘ute etter noen’, og det er ingen tjent med. Og det er heller ikke meningen. Det skal være spørsmål som fremmer kvalitet, men også bidrar til progresjon og produksjon. Og ikke for å ‘pirke på alle andre’.
“Testleder blir aldri fornøyde og løper alltid kundens ærend”
Dessverre oppfattes det ofte som problematisering når vi stiller spørsmål ved krav og nye/endrede funksjoner. Det kan oppfattes som vi påpeker svakheter ved andres kvalitet, er illojale i egne rekker, og at vi hindrer fremdrift i prosjektet. Realiteten er imidlertid at testlederen vet at disse innsigelsene kan spare prosjektet for mye jobb i senere faser, og dermed bidra positivt i det store bildet. Men det er et viktig poeng som testleder at dette ikke skal være det eneste fokuset, og det skal fremføres med omhu. Ingen tjener på et ensidig fokus på dette slik at det skaper et dårlig samarbeidsmiljø.
Testleder for leverandør er kvalitetsansvarlig for leveranser, og således kundens representant i prosjektet i tillegg. Dette gjør at vi ofte kan oppfattes som motarbeidende av egne rekker, da vi påpeker svakheter ved egen leveranse. Vi påpeker kvalitet og mangel av dette, både sett ut fra krav men også kundens faktiske og funksjonelle behov.
Dette gjør vi fordi vi ikke bare verifiserer at leveransen fungerer i henhold til løsningsbeskrivelsen, men også validerer at vi faktisk bygger det riktige systemet. Vi ønsker både å oppnå kravdekning og sikre at vi leverer en løsning som dekker det behovet kunden har.
På kundesiden kan testleder bli oppfattet som trenerende når de fremhever at for sluttbrukere er det ikke nødvendigvis slik at gleden over nye løsninger vil overdøve støyen fra manglende kvalitet.
En god testleder på kunde- eller leverandørsiden vil knytte seg til sin motpart på den andre siden, og jobbe sammen om kvalitet, istedenfor å sitte på hver sin side å søke etter å finne feil hos den andre. Holdningen ‘jeg skal finne flere feil enn deg’ er heldigvis som oftest fraværende, og man jobber sammen for å komme frem til den kvalitet man mener løsningen skal ha.
Det er lett å glemme kundene/brukerne av den utviklede programvaren i iveren etter å produsere. Testleder kan her bidra med å spørre om/belyse/organisere brukertester/betagrupper m.m som også vil øke kvaliteten på produktet. En viktig egenskap en testleder må ha er å kunne si at ‘dette er godt nok’, å kunne vurdere at det faktisk dekker kundens krav og behov, og legge seg på minnet at det er rom for forbedringer i senere faser. Dette også for å kunne dempe designere som ofte kan oppfattes å være enda mer på kundens side. Slik at testleder må bidra for å moderere alt for fancy løsninger, sett opp mot hva behovet er, men også opp mot den tiden dette vil ta i tillegg ved å utvikle det. Samt vurdere for test av mer kompleks funksjonalitet.
“Utviklerne bruker jo allerede TDD og klarer dette på egen hånd”
I senere tid har også testbegrepet blitt utvidet til å inkludere kvalitetssikring. At test nå ikke bare skal planlegges for å finne feil, men også å bygge kvalitet inn i løsningen fra begynnelsen. Det er en sannhet at man ikke kan teste kvalitet inn i løsningen – dette må arbeides inn allerede fra validering av krav og valgt funksjonell og teknisk løsning.
Det har også være et skifte fra fossefallsmetoden, hvor test var det siste som skjedde, til at teamet løser oppgaver i fellesskap, og det er tett samarbeid mellom fag, utviklere og testere. Vi har mer kontinuerlig testing og test er integrert i teamet.
TDD (Test driven development) er en programvareutviklingsmetodikk som skal møte dette. Med prinsipp om korte iterasjoner, hvor tester som skal dekke ny funksjonalitet eller forbedringer skrives først, for så å implementere selve koden som skal løse behovet. Koden programmeres da på en slik måte at testene passerer feilfritt.
TDD og automatiske enhets- og integrasjonstester hjelper langt på vei å ta unna de grunnleggende feilene for f.eks. valideringer av felt etc., slik at testleder ikke trenger å bruke så mye av tiden sin på å planlegge for test av dette. I stedet er det nå muligheter for å bruke mer av tiden på å planlegge ende-til-ende tester og verdikjedetester. Dette er ikke tester som dekkes av TDD, men krever en stødig testleder som evner å se løsningen som helhet.
Test som inkluderer kvalitetssikring vil gi tilbakemelding til resten av prosjektet om mulige forbedringer, og ikke bare finne feil og mangler.
En overivrig testleder derimot vil stjele tid fra utvikling. Det er mer verdiskaping i å la utviklere bruke tiden på koding i stedet for å legge inn uproduktive testperioder, hvor løsningen allikevel ikke er klar for strukturert test. Dette vil bare skape misnøye. Det er bedre at testleder bruker tid sammen med utviklere i forkant, og gir en gjennomgang av funksjonelle testteknikker. På den måten vil utviklere levere bedre kvalitet allerede fra begynnelsen av, og testleder kan fokusere mer på de funksjonelle testene som også ofte knytter flere deler av løsningen sammen. Utviklere vil naturlig ha fokus på implementasjon, men innrømmer ofte at det er er betryggende å ha testleder på plass som har funksjonelt fokus.
“Med DevOps samhandler vi så raskt at det er ikke behov for et kvalitetspoliti”
“Hadde testing vært et nødvendig fokus hadde det hett DevTestOps!. (Development, Test, Opps vi fant feil!)”
I DevOps legges det stor vekt på samarbeid mellom utviklings- og driftsteamene (Development/Dev, Operations/Ops).
Det benyttes tilbakemeldingsrutiner for å raskere kunne dele informasjon og gi tilbakemeldinger mellom teamene. Det vil også si at det er en kultur med rom for kontinuerlig ‘prøv, feil og meld tilbake’. Og målet er mye oftere og raskere produksjonssettinger.
Allikevel vil det behøves noen med overblikk over teknikk, funksjoner og avhengigheter, som kjenner løsningen og har det nødvendige kunde- og sluttbrukerfokus. Ikke minst for å kunne planlegge tester av verdikjedene, rådgi i prioritering av testene som må kjøres, og som ser og har overblikk over sammenhenger og konsekvenser.
Gode regresjonstester er særdeles viktig, og her kommer testleder inn som en naturlig leder. Og vedkommende må også ha vurderingsevnen som nevnt over, at ‘per nå er dette godt nok for å gå i produksjon, det er en verdiøkning i det som er produsert’.
“Testleder er så dyre i drift”
Så hvorfor skal et prosjekt befolkes med en testleder, når vi tilsynelatende skaper så mye uro i et prosjekt? Og i tillegg er dyre å ha gående?
Noen vil argumentere for at testleder utgjør en unødvendig kostnad: Utviklerne i teamene kan teste på egenhånd og så tar vi resten i piloter og betagrupper.
Men så er det slik at den tiden og kostnaden det tar å finne de riktige feilene tidlig nok, er veldig liten sett mot kostnaden som følger med å måtte rette feil i produksjon, eller i verste fall ha utviklet feil produkt og gå flere steg tilbake. Ny kode må så gjennom mange steg med utvikling, test fra leverandør, ny test fra kunde før en eventuell produksjonssetting. Spørsmålet blir heller om man tør la være å ha noen med et ekstra ansvar for kvaliteten i løsningen?
Avvik kan også avdekkes før utvikling finner sted med en dreven testleder ombord, og det vil fort komme frem om det er krav som ikke dekkes av løsning, om kravene er uklare og hvordan de skal kunne testes og godkjennes. Og en testleder vil med sine kritiske spørsmål redusere omfanget av det som utvikles (feil), og dermed bidra til en billigere løsning.
Testleder vil også ut fra både sin dybde- og breddekunnskap om løsningen kunne hjelpe med konsekvensanalyser og estimater ved eventuelle endringer, og dermed si noe om kompleksitet ved (test av) løsning og minimere risiko.
“Prosjektleder kan håndtere dette”
Det er ingen tvil om at den god prosjektleder kan gjøre deler av testlederens jobb. Men kvalitetsmessig er det mye å tjene på la prosjektleder gjøre sin jobb med å følge fremdrift og kostnader, og planmessig holde prosjektet i hånden. Så kan testleder være den som holder kvaliteten i sin hånd.
Men. Dette er tema for en egen betraktning om hvorvidt testleder er “Prosjektleder light”.
Så – oppsummert mener vi at ja, det er en kostnad ved å engasjere testleder i store, komplekse og kritiske leveranser.
Men vi mener uten tvil at det er verdt investeringen å ha noen med et særskilt kvalitetsfokus i prosjektet.
Tør du la være?
