I en tidligere artikkel “Testledelse er ikke prosjektledelse light“ diskuterte vi ulikheter og likheter mellom Testleder og Prosjektleder. Der var vi såvidt innom Prosjekttrekantens ulike elementer, men drøftet ikke noe mer ulike prioriteringer og konsekvenser av disse.
En viktig oppgave for Prosjektleder er ofte å gjøre et valg av hvilke(t) av elementene i Prosjektstyringstrekanten det skal styres etter. Her brukes litt ulike begreper, vanligvis er disse: Tid, Penger eller Omfang (Kvalitet).
I alle fall i prosjekter med mer tradisjonell gjennomføringsmetodikk. I mindre prosjekter med metodikk nærmere DevOps, vil releasene være så små at trekanten i praksis forsvinner.
Så er det ulike ‘versjoner’ av denne trekanten. Med “Tid, kostnad, kvalitet” eller “Tid, kostnad, omfang (kvalitet)”, da med et ‘balansepunkt’ som skal vise vekting og balanse mellom disse.
Og på noen igjen er ‘kvalitet’ lagt som et fjerde element ‘inni’ trekanten som da også skal hensyntas.
Det hele starter med en vurdering av hva som er viktigst i prosjektet.
Er det å nå en fastsatt oppstartsdato ‘uansett’ slik at tid er mest kritisk? Eller er det sluttresultatet, for eksempel ved en internettløsning med flere tusen brukere hvor antall feil funnet av sluttbrukere gir nedsatt omdømme, eller om de i det hele tatt får bestilt og betalt det de skal. Dette gir at Omfang og Kvalitet er det viktigste.
Utfordringen med kvalitet er at denne ikke har noe fast definisjon. Dette avhenger av, og må defineres i, hvert enkelt prosjekt, og må i tillegg veies opp mot hva som er vektet mest.
Her må Testleder og Prosjektleder enes om hva som er ‘Kvalitet’ i dette aktuelle prosjektet, og Testleder må benytte sin erfaring, kompetanse og utdanning fra feks. ISTQB for å kunne gjøre vurderinger.
Så vil jo ofte denne prioriteringsrekkefølgen endre seg underveis i et prosjekt.
Hva er konsekvensene av dette for Testleder, og har det noen betydning på testplanlegging og prioritering av tester?
Ikke uvanlig må ett eller flere av trekantens elementer vike, og det som nedprioriteres må kommuniseres raskt og tydelig til Testleder, som må planlegge, evt. replanlegge, sin test ut fra dette.
Tid
Om det er Tiden man må gi eller ta på, så er dette kanskje det elementet som har mest påvirking på de andre. Om man må rekke en dato hugget i stein, eller må man replanlegge ut fra forsinkelser. Dette vil typisk påvirke Kostnader i stor grad, men også Omfang kan måtte vurderes på nytt.
Kostnad
Kostnader kan ved en endring kun reduseres eller økes.
Reduksjon ved å fjerne prosjektressurser feks. på innleide konsulenter eller noen roller, eller øke ved å sette alle kluter til for å nå en dato, og fylle på med de ressurser man ser nødvendig for å klare dette.
Kostander kan også reduseres eller økes ut fra teknologi, lisenser o.l. men vi går ikke videre på det her.
Omfang
Omfang kan også måtte endres. Feks. slik at bare ‘de viktigste’ delene av en løsning er godt nok for å kunne settes i produksjon, og deretter øke på med funksjonalitet.
Det å finne korrekt omfang prioritert etter Tid eller Kostnad er ingen lett oppgave. ‘Alt’ føles like vikitg ved første gjennomgang, og det er ikke alltid lett å se eller akseptere at man ikke får hele løsningen eller alt man ønsker seg med det samme.
Så hvordan komme frem til scope og hva som er virkelig nødvendig funsjonalitet. Det er ulike metoder for finne en minimumsløsning, men tanken ‘Hva kan vi leve med når penger eller tiden tar slutt’ er viktig, hva vil økt verdi eller hjelpe oss til å gjøre oppgavene våre. Og finne de viktigste brukerene av det nye som kommer.
MVP, Minimum viable product, på norsk “Minste brukbare produkt” er en slik strategi som kan ta oss dit.
Kvalitet
Så er det Kvalitet.
Uansett hva som skyves på av de andre elementene vil dette kunne påvirke testplanlegging og potensielt kvalitet i en eller annen grad.
Mindre tid gir mindre tid å planlegge og kjøre de testene man ønsker, og disse må prioriteres etter f.eks risiko. Det samme med penger, mindre penger til test gir samme utfordring.
Det kan være fristende å si at om kvalitet er det som er pri 1, er det da det er viktigst med de riktige testene. Men gjelder ikke dette uansett? Om det gis mindre tid til test grunnet forsinkelser, er det enda viktigere å kjøre de rette testene først for avdekke de mest kritiske feilene.
Og hva om det er få ressurser, eller man må spare penger på å ha færre (funksjonelle) testere? Ja da er det samme argument, tester må prioriteres ut fra en risikovurdering for hva som er viktigst for å komme igjennom på den tiden man har med de ressurser man har.
Og om omfang/kvalitet er det viktigste, ja da har man kanskje bedre tid til å rekke å kjøre enda flere tester for å ta unna enda flere ‘C-feil’. Men man må fortsatt prioritere de ‘viktigste’ først for å ta unna de mest kritiske. Og ikke minst er dette ofte også de mest kompliserte å korrigere.
Med andre ord. Dette er prioriteringer og vurderinger Testleder tar, basert på retningslinjer kommunisert fra Prosjektleder.
Og svaret er nesten alltid det samme, uansett hva det styres etter i prosjektet vil Testleder fokusere på Kvalitet, men selvfølgelig innenfor rammene som er gitt av de andre prioriteringene. Og det vil alltid kreve en riktig vekting av de andre elementene i prosjekttrekanten for å levere en løsning med god Kvalitet.
Denne artikkelen er skrevet av Lena Jonhaugen. Hun jobber som testleder i Promis Qualify.