Redaktørens merknad: Velkommen til serien Ledelse innen testing fra programvaretestingsguru og konsulent Paul Gerrard. Serien er laget for å hjelpe testere med noen års erfaring – særlig de som jobber i smidige team – med å lykkes i rollene som testledere og ledere.
I den forrige artikkelen skisserte vi et risikomanifest for å hjelpe ledere. I denne artikkelen skal vi stille det tidløse spørsmålet «Hvor mye testing er nok?». Avsløring: Det er opp til interessentene.
Abonner på nyhetsbrevet The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls kurs i ledelse innen testing, som vi på det sterkeste anbefaler for å gå dypere inn i dette og andre temaer. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få 60 dollar i avslag på full kurspris!
Hvor mye testing er nok? Dette er det klassiske, ubesvarlige, filosofiske spørsmålet som alle testere stiller, fordi interessentene deres stiller det til dem.
Interessentene vil vite det fordi de ønsker trygghet for at systemene er tilstrekkelig testet, men siden de betaler for det og har tidsfrister å overholde, vil de også vite hva testing kan koste, og hvor lang tid det vil ta.
Derfor er det interessentene som skal vurdere hvor mye testing som er nok. Din jobb som testleder er å skape så mye verdi for dem som mulig ved å hjelpe dem med å ta en beslutning. I denne artikkelen skal vi dekke:
- Verdien av testing for interessenter
- Kvanteteorien og relativitetsteorien (ikke fysikk)
- Å bruke riktig språk
- Estimater, budsjetter og forhandlinger
La oss begynne.
Verdien av testing for interessenter
Hver test vi kjører, bør ha verdi for interessentene ved at den gir bevis som støtter beslutningstakingen deres på fire måter:
- Bevis på at systemet vil oppfylle prosjektets forretningsmål.
- Bevis på at systemet ikke vil feile, eller at konsekvensene av en eventuell feil er håndterbare.
- Bevis som kan brukes til å gjenskape og diagnostisere feil, samt reparere og teste det feilende systemet på nytt.
- Bevis som støtter beslutningstaking i prosjektets kontekst (om systemet skal godtas, lanseres, avvises osv.)
Målet vårt med testing er å lage tester som trinnvis øker testdekningen av systemet med hensyn til en gjenkjennelig testmodell. Testene våre bør vise at systemet vil oppfylle forretningsmålene, og at risikoen for feil er kjent og forhåpentligvis akseptabel.
Av de fire typene bevis ovenfor danner de tre første grunnlaget for den fjerde. Til syvende og sist må interessentene ta en beslutning basert på bevis. Det er deres beslutning å ta, ikke testernes, så det er opp til dem å vurdere om de har nok informasjon til å føle seg trygge. Uansett ligger verdien av testing i interessentens øyne.
Alle testere tar valg om hva som skal testes ved å bruke en formell modell eller bare magefølelsen. Disse valgene tas på grunnlag av en oppfattet verdi.
Med mindre testeren også er interessenten, vurderer testeren vanligvis verdi basert på et mål på fullstendighet eller dekning. Eller, hvis de kjenner interessentenes tanker, basert på om testen vil støtte en bestemt godkjenningsbeslutning.
Prinsippene ovenfor har noen viktige konsekvenser.
For det første: Hvis du ikke kjenner interessentens synspunkter, er det lite sannsynlig at din oppfatning av testverdi er den samme som deres. Hvis du velger tester uten å ta hensyn til verdiene deres, kan interessentene dine oppleve at de har for lite data på noen områder og et overskudd på andre når tiden kommer for å presentere resultatene dine. De vil definitivt ikke føle seg så trygge som de burde.
For det andre: Når du utformer eller kjører en test, hva bidrar den med til interessentenes beslutningstaking? Hvis en test ikke gir noe trinnvis ny informasjon som støtter en beslutning, eller hvis interessentene ikke bryr seg om testen består eller feiler, har den ingen plass i en testplan.
Vi sa i artikkel 3 om modeller at testmodellene du bruker, må være relevante for interessentene. Hvis testresultatene dine kan knyttes til modeller som interessentene forstår og verdsetter, vil de verdsette bidraget ditt.
Have an account? Log In
Kvanteteorien og relativitetsteorien
Det finnes ytterligere to prinsipper knyttet til testenes verdi og betydning. Jeg kaller det ene kvanteteorien og det andre relativitetsteorien. Disse betegnelsene høres pretensiøse ut (de er helt klart ment med glimt i øyet), men de beskriver to fenomener som ligger til grunn for alle diskusjoner om testverdi, prioritering og avgrensning.
Når vi gjennomfører en test, tolker vi vanligvis resultatet som bestått eller ikke bestått. Bestått/ikke bestått-vurderingen er et binært resultat – sant eller usant, ja eller nei, én eller null. Testresultatet genererer en avgrenset mengde evidens. Evidensen bygger seg opp etter hvert som vi gjennomfører flere og flere tester. Uansett utfall øker testen gradvis dekningen av testmodellen vår og kunnskapen vi har om systemets atferd. Tester som ikke øker kunnskapen vår, tilfører ingen verdi.
Hvis en test ikke gradvis øker dekningen på en eller annen måte, har den liten verdi.
Det andre aspektet er verdien av en test. Hva er verdien av en test? Kan du virkelig sette en verdi i dollar, pund eller euro på én enkelt test? Sannsynligvis ikke. Men det vi kan gjøre – og ofte ganske enkelt – er å si «denne testen er mer verdifull enn den andre».
La oss anta at vi bruker en modell for kodedekning, for eksempel setningsdekning. Vi kan kjøre en test som utøver fem kodelinjer eller fem tusen kodelinjer. Hva er verdien av hver av dem? Det er vanskelig å si. Men hvis målet vårt er setningsdekning, har den andre testen større verdi.
Vi kan ikke sette en absolutt verdi på noen test, men vi kan vanligvis sammenligne tester og utlede den relative verdien av hver av dem. Det vil si at hvis vi er under tidspress, kan vi vanligvis si at én test har mindre verdi enn en annen, og derfor ta den første testen ut av omfanget hvis vi må.
Vi kan sammenligne verdien av tester, men bare hvis de bygger på den samme modellen.
Vi må imidlertid understreke at disse sammenligningene egentlig bare er meningsfulle hvis de deler den samme modellen. En test som dekker et stort spekter av ekstreme forhold i en prosess, har sannsynligvis større verdi enn en test av den «rett gjennom»-banen. Tester fra ende til ende av en kompleks prosess kan for eksempel ikke sammenlignes direkte med enhetstester av kritiske komponenter.
Selv om teoriene om kvantefysikk og relativitet kanskje ikke gjelder direkte for testing, gjør prinsippene om tilpasningsevne og perspektiv det. Finn et teststyringsverktøy som er i tråd med disse prinsippene, for å optimalisere teststrategien din.
Bruk riktig språk
Nå som vi har fastslått hvem som har ansvaret for å avgjøre «hvor mye testing som er nok», hvordan kan vi som samvittighetsfulle testere støtte denne beslutningsprosessen?
Merk at behandlingen vår av verdien av tester ligner svært mye på vår risikovurdering. Som omtalt i den forrige artikkelen er det svært vanskelig å sette numeriske verdier på omfanget av eller eksponeringen for risiko. Det er imidlertid vanligvis mulig å sammenligne én risiko med en annen og rangere dem for å ta valg om hvilke risikoer som skal omfattes av testingen.
Ved å bruke risikospråket vil testere bli hørt av ledelsen.
Ledere for utviklingsteam ser ofte ut til å bli lyttet til av ledere, selv når de snakker i tekniske termer. Forskjellen er at de presenterer teknologien som spennende og nyttig. Når testere snakker i sine egne tekniske termer – om «kontorarbeidsdetaljene» ved tester, som hendelsesstatistikk – har budskapet en tendens til å bli negativt, og ledere kan bli lei eller irriterte.
Ledelsen mener kanskje allerede at testere som gruppe er litt kjedelige, men dette skyldes antakelig at mange ledere ikke egentlig forstår hva testere gjør, og hvilken verdi de tilfører. Testere bør derfor løfte språket sitt opp på ledelsesnivå.
Risikobasert testing kommuniserer med bruker- og prosjektledelsen på deres språk.
Dette er mennesker som i stor grad tenker i form av risikoer og fordeler. Hvis testere henvender seg til dem i lignende termer, er det mer sannsynlig at ledelsen lytter til testerne og dermed tar bedre beslutninger. Ved å knytte tester til prosjektets mål kan vi rette oppmerksomheten mot de leveransene som har størst verdi for interessentene, slik at vi bruker tiden vår på å teste de viktigste tingene.
Etter hvert som testingen gjør fremskritt, kan vi dessuten vise at de mest verdifulle fordelene nå er tilgjengelige. Utgivelsesbeslutningen er til syvende og sist en vurdering av om fordelene som er oppnådd, veier opp for risikoene, så testingen vil gi ledelsen bedre data som beslutningene kan baseres på.
Bruk risikospråket (og fordelsspråket) til å definere omfanget av, planlegge og rapportere fremdrift i testingen.
Testere må selvsagt snakke teknisk med utviklere og annet teknisk personell. Kvaliteten på hendelsesrapportene er for eksempel en viktig faktor for å få feil rettet raskt og pålitelig. Jeg sier ganske enkelt at testeren, når vedkommende snakker med ledelsen, snakker om risikoer som er håndtert og utestående, i stedet for tester, hendelser og feil.
More Articles
Estimater, budsjetter og forhandlinger
Tidlig i et nytt prosjekt spør prosjektlederen deg: «Jeg trenger å planlegge og skaffe ressurser til testingen i god tid. Kan du gi meg et estimat på hvor mange personer du trenger, og hvor lang tid du trenger til systemtestingen?»
Du tenker deg om og går for å snakke med sjefen.
«Jeg trenger seks testere i åtte uker.»
Prosjektlederen tenker seg om et øyeblikk og rådfører seg med utkastet til tidsplanen og ressursplanen.
«Du kan få fire testere i seks uker, og det er alt.»
Du protesterer og sier: «Men det vil ta lengre tid enn seks uker! Det vil koste mer enn det du har satt av til å teste dette systemet. Systemet er større enn sist. Det er mer komplisert. Det er definitivt for risikabelt for oss å spare inn på testingen denne gangen. Det er rett og slett ikke nok.»
Men lederen står på sitt og mumler noe om andre avhengigheter, høyere instanser og så videre …
Hva tror du var poenget med å lage et estimat hvis lederen visste hva budsjettet måtte være hele tiden? Hvilken relevans har et vilkårlig budsjett for jobben som skal gjøres? Hvorfor tar de aldri testing på alvor? Utviklerne får alltid tiden de ber om, gjør de ikke? Det virker ikke rettferdig.
Du kan føle deg forurettet og at den faglige vurderingsevnen din blir undergravd. Men problemet er, og har alltid vært, at testbudsjettet i denne situasjonen var fastsatt. Alt du kan gjøre, er å finne ut hvilken testing som er best eller mest verdifull, og som du kan presse inn i budsjettet.
Men ofte ønsker prosjektlederen faktisk å vite hvor lang tid ting vil ta, slik at planen kan justeres. Hvis du tror at du er i en forhandling, trenger du noen forhandlingskort. Du må også diskutere resultatene av planen, ikke innsatsfaktorene. Omfanget er et resultat av planleggingen, mens innsatsen du legger inn, er en innsatsfaktor.
Du må forhandle om omfanget.
Forhandlinger om testbudsjetter bør alltid handle om omfang, ikke innsats.
Omfang kan presenteres i ett eller flere formater, og måten du presenterer og diskuterer omfanget på, vil variere, men her er noen vanlige mønstre. Uansett hvilket omfang du har, vil du bruke det som grunnlag for estimatet og forsvaret av det:
Omfang som en oversikt over krav eller funksjoner
Når estimatet reduseres med 30 %, spør: «Hvilke 30 % av systemet skal jeg ikke teste?»
Omfang som en oversikt over risikoer
Når estimatet reduseres med 30 %, spør: «Hvilke interessentrisikoer skal jeg fjerne fra planen?»
Omfang som en tabellarisk eller grafisk modell
Når estimatet reduseres med 30 %, spør: «Hvilke stier/reiser/elementer skal jeg fortelle interessentene at ikke vil bli testet?»
Jeg håper du ser hva som foregår her.
- Testomfanget er basert på en modell som først er diskutert med og godkjent av interessentene. Dette omfanget er foreløpig, avhengig av at ressurser og tid er tilgjengelige, og du bør gjøre interessentene oppmerksomme på dette.
- Du estimerer på grunnlag av dette foreløpige omfanget. Bruk modellen (risikoer, krav, forretningsprosess eller en annen modell) til å fastsette et dekningsmål, tell dekningsenhetene og estimer på dette grunnlaget.
- Ta en diskusjon med prosjektlederen. Hvis estimatet er for høyt, bruker du svarene ovenfor til å sette i gang diskusjoner med interessentene.
Som tester eller testleder er du ikke i en god posisjon til å forhandle om testing med prosjektlederen. Interessentene har bekymringene, og hvis du deler modellene som definerer testomfanget, vil de ha meninger, slutte seg til omfanget og kunne forsvare det. Interessentene er også ansvarlige for å begrunne budsjettet for systemet sitt, så de er best egnet til å avveie kostnadene ved testing mot behovet for å håndtere bekymringene deres.
Noe å tenke over
Tenk over hvem som i prosjektene dine tar ansvar for mengden testing som skal utføres:
- Definerer du som tester omfanget og mengden testing?
- Fastsetter prosjektlederen et budsjett, og gjør du så godt du kan med tiden du har fått tildelt?
- Forhandles omfanget med prosjektlederen og interessentene for å bli enige om en balanse mellom innsatsen og testomfanget som skal gjennomføres?
Et av testerens viktigste ansvarsområder er å sørge for at prosjektet er kjent med produktrisikoene som tas, og å dokumentere dem. Først når disse risikoene er synlige, kan ledelsen erkjenne risikoene de tar ved å redusere testingen.
Det finnes ingen formel for riktig mengde testing. I de fleste miljøer kan testnivået bare fastsettes gjennom enighet mellom prosjektledelsen, kundens sponsorer, utviklerne, tekniske spesialister og testerne – tester regnes som en del av omfanget hvis de håndterer risikoene man er bekymret for.
Tilstrekkelig testing bør fastsettes gjennom enighet, der testeren legger til rette for og bidrar med informasjon til enighetsprosessen.
Meld deg på nyhetsbrevet til The QA Lead for å få beskjed når nye deler av serien publiseres. Disse innleggene er utdrag fra Pauls Leadership In Test-kurs, som vi på det sterkeste anbefaler hvis du ønsker en dypere gjennomgang av dette og andre emner. Hvis du gjør det, bruk vår eksklusive kupongkode QALEADOFFER for å få $60 rabatt på full kurspris!
Relaterte artikler:
