Redaktørens bemærkning: Velkommen til serien Lederskab inden for test fra softwaretestguru og -konsulent Paul Gerrard. Serien er designet til at hjælpe testere med nogle års erfaring – især dem på agile team – med at udmærke sig i roller som testledere og -chefer.
I den forrige artikel skitserede vi et risikomanifest, der kan hjælpe ledere. I denne artikel stiller vi det hævdvundne spørgsmål: “Hvor meget test er nok?”. Afsløring: Det er op til interessenterne.
Tilmeld dig nyhedsbrevet fra The QA Lead for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i lederskab inden for test, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, skal du bruge vores eksklusive kuponkode QALEADOFFER for at få $60 i rabat på den fulde kursuspris!
Hvor meget test er nok? Dette er det klassiske, ubesvarlige, filosofiske spørgsmål, som alle testere stiller, fordi interessenterne selv stiller det til dem.
Interessenterne vil vide det, fordi de ønsker sikkerhed for, at systemerne er blevet testet tilstrækkeligt, men eftersom de betaler for det og har deadlines, der skal overholdes, vil de også vide, hvad de potentielle omkostninger ved test er, og hvor lang tid det vil tage.
Det er derfor interessenterne, der skal vurdere, hvor meget test der er nok. Din opgave som testchef er at skabe så meget værdi for dem som muligt ved at hjælpe dem med at træffe en beslutning. I denne artikel gennemgår vi:
- Værdien af test for interessenter
- Kvanteteori og relativitetsteorien (ikke fysik)
- At bruge det rigtige sprog
- Estimering, budgetter og forhandling
Lad os begynde.
Værdien af test for interessenter
Hver test, vi kører, bør have værdi for interessenterne, idet den leverer dokumentation, der understøtter deres beslutningstagning på fire måder:
- Dokumentation for, at systemet vil opfylde projektets forretningsmål.
- Dokumentation for, at systemet ikke vil fejle, eller at konsekvenserne af en fejl er håndterbare, hvis det sker.
- Dokumentation, der kan bruges til at genskabe og diagnosticere fejl samt reparere og teste det fejlbehæftede system igen.
- Dokumentation, der understøtter beslutningstagning i forbindelse med et projekt (om det skal accepteres, frigives, afvises osv.)
Vores mål med test er at skabe test, der trinvis øger testdækningen af systemet i forhold til en genkendelig testmodel. Vores test bør demonstrere, at systemet vil opfylde forretningsmålene, og at risikoen for fejl er kendt og forhåbentlig acceptabel.
Af de fire typer dokumentation ovenfor understøtter de første tre den fjerde. I sidste ende skal interessenterne træffe en evidensbaseret beslutning. Det er deres beslutning at træffe, ikke testernes, så det er dem, der skal vurdere, om de har nok til at føle sig sikre. Under alle omstændigheder ligger værdien af test i interessentens øjne.
Alle testere træffer naturligvis valg om, hvad der skal testes, ved at bruge en formel model eller måske blot mavefornemmelsen. Disse valg træffes på baggrund af en oplevet værdi.
Medmindre testeren også er interessenten, vurderer testeren normalt værdien ud fra et mål for fuldstændighed eller dækning. Eller, hvis testeren kender interessenternes tankegang, ud fra om testen vil understøtte en bestemt acceptbeslutning.
Ovenstående principper har nogle vigtige konsekvenser.
For det første: Hvis du ikke kender interessentens tankegang, er det usandsynligt, at din opfattelse af testens værdi er den samme som deres. Hvis du udvælger test uden at tage hensyn til deres værdier, kan interessenterne, når tiden kommer til at præsentere dine resultater, opleve, at de har utilstrækkelige data på nogle områder og for mange på andre. De vil bestemt ikke føle sig så sikre, som de burde.
For det andet: Når du designer eller kører en test, hvad bidrager den så med til interessenternes beslutningstagning? Hvis en test ikke tilvejebringer ny information, der understøtter en beslutning, eller hvis interessenterne er ligeglade med, om din test består eller fejler, har den ingen plads i en testplan.
Vi sagde i artikel 3 om modeller, at de testmodeller, du bruger, skal være relevante for interessenterne. Hvis dine testresultater kan relateres til modeller, som interessenterne forstår og værdsætter, vil de værdsætte dit bidrag.
Have an account? Log In
Kvanteteori og relativitetsteorien
Der er yderligere to principper, der vedrører testens værdi og betydning. Jeg kalder det ene for kvanteteorien og det andet for relativitetsteorien. Disse betegnelser lyder prætentiøse (de er helt sikkert sagt med et glimt i øjet), men de beskriver to fænomener, der ligger til grund for alle diskussioner om testens værdi, prioritering og afgrænsning.
Når vi kører en test, fortolker vi normalt resultatet som bestået eller ikke bestået. Bedømmelsen bestået/ikke bestået er et binært resultat – sandt eller falsk, ja eller nej, et ettal eller et nul. Testresultatet genererer et diskret kvantum evidens. Evidensen bygges op, efterhånden som vi udfører flere og flere tests. Uanset resultatet øger testen gradvist dækningen af vores testmodel og vores viden om systemets adfærd. Tests, der ikke øger vores viden, tilfører ingen værdi.
Hvis en test ikke gradvist øger dækningen på en eller anden måde, har den kun ringe værdi.
Det andet aspekt er værdien af en test. Hvad er værdien af en test? Kan man virkelig sætte en værdi i dollar, pund eller euro på en enkelt test? Sandsynligvis ikke. Men det, vi kan gøre – og ofte ret nemt – er at sige: »Denne test er mere værdifuld end den anden.«
Antag, at vi bruger en model for kodedækning som f.eks. sætningsdækning. Vi kunne køre en test, der gennemgår fem kodelinjer, eller en, der gennemgår fem tusind kodelinjer. Hvad er værdien af hver af dem? Det er svært at sige. Men hvis vores mål er sætningsdækning, har den anden test større værdi.
Vi kan ikke sætte en absolut værdi på nogen test, men vi kan normalt sammenligne tests og udlede en relativ værdi for hver af dem. Det vil sige, at hvis vi er under tidspres, kan vi normalt sige, at én test har mindre værdi end en anden og derfor tage den første test ud af omfanget, hvis det er nødvendigt.
Vi kan sammenligne værdien af tests, men kun hvis de udspringer af den samme model.
Vi må dog understrege, at disse sammenligninger reelt kun er meningsfulde, hvis de deler den samme model. En test, der dækker en lang række ekstreme forhold i en proces, har sandsynligvis større værdi end en test af den »direkte gennemløbssti«. Ende-til-ende-tests af en kompleks proces kan f.eks. ikke sammenlignes direkte med enhedstests af kritiske komponenter.
Selv om teorierne om kvantefysik og relativitet måske ikke kan anvendes direkte på test, kan principperne om tilpasningsevne og perspektiv anvendes. Find et teststyringsværktøj, der stemmer overens med disse principper, for at optimere din teststrategi
Brug det rigtige sprog
Nu hvor vi har fastslået, hvem der er ansvarlig for at beslutte »hvor meget testning der er nok«, hvordan kan vi som samvittighedsfulde testere understøtte denne beslutningstagning?
Bemærk, at vores behandling af testenes værdi minder meget om vores vurdering af risici. Som omtalt i den foregående artikel er det meget svært at sætte numeriske værdier på risikoniveauet eller risikoeksponeringen. Det er dog normalt muligt at sammenligne én risiko med en anden og rangordne dem for at træffe valg om, hvilke risici der skal omfattes af testningen.
Ved at bruge risikosproget vil testere blive hørt af ledelsen.
Ledere af udviklingsteams synes ofte at blive lyttet til af ledere, selv når de taler i tekniske termer. Forskellen er, at de fremstiller teknologien som spændende og fordelagtig. Når testere taler i deres egne tekniske termer – om testenes »administrative« detaljer, såsom statistikker over hændelser – har budskabet en tendens til at være negativt, og ledere kan blive uengagerede eller irriterede.
Ledelsen synes måske allerede, at testere som gruppe er lidt kedelige, men det skyldes efter alt at dømme, at mange ledere ikke rigtigt forstår, hvad testere laver, og hvilken værdi de tilfører. Testere bør derfor løfte deres sprog til ledelsesniveau.
Risikobaseret testning taler til brugerledelse og projektledelse på deres eget sprog.
Det er mennesker, der i høj grad tænker i risici og fordele. Hvis testere henvender sig til dem i lignende termer, er ledelsen mere tilbøjelig til at lytte til testerne og dermed træffe bedre beslutninger. Ved at knytte tests til projektets mål kan vi rette opmærksomheden mod de leverancer, der har størst værdi for interessenterne, så vi bruger vores tid på at teste de vigtigste ting.
Efterhånden som der gøres fremskridt gennem testningen, kan vi desuden demonstrere, at de mest værdifulde fordele nu er tilgængelige. Beslutningen om at udgive er i sidste ende en vurdering af, om de opnåede fordele opvejer risiciene, så testningen vil give ledelsen bedre data at basere sine beslutninger på.
Brug risikosproget (og fordelene) til at afgrænse, planlægge og rapportere om fremskridt inden for testning.
Testere er naturligvis nødt til at tale teknisk med udviklere og andet teknisk personale. Kvaliteten af hændelsesrapporter er f.eks. en afgørende faktor for at få fejl rettet hurtigt og pålideligt. Jeg siger blot, at testeren, når vedkommende taler med ledelsen, taler om håndterede og udestående risici frem for tests, hændelser og fejl.
More Articles
Estimater, budgetter og forhandling
Tidligt i et nyt projekt spørger din projektleder dig: »Jeg har brug for at planlægge og bemande testningen i god tid. Kan du give mig et estimat for, hvor mange personer du har brug for, og hvor lang tid du skal bruge på at udføre systemtestningen?«
Du tænker dig om og går hen for at tale med chefen.
“Jeg har brug for seks testere i otte uger.”
Projektlederen tænker sig om et øjeblik og rådfører sig med sit udkast til tidsplan og sin ressourceplan.
“Du kan få fire testere i seks uger, og det er alt.”
Du protesterer og siger: “Men det kommer til at tage længere tid end seks uger! Det kommer til at koste mere end det, du har afsat til at teste dette system. Systemet er større end sidst. Det er mere kompliceret. Det er bestemt for risikabelt for os at spare på testningen denne gang. Det er bare ikke nok.”
Men projektlederen står fast og mumler noget om andre afhængigheder, højere instanser og så videre …
Hvad tror du var formålet med at lave et estimat, hvis projektlederen hele tiden vidste, hvad budgettet skulle være? Hvilken relevans har et vilkårligt budget for den opgave, der skal udføres? Hvorfor tager de aldrig testning alvorligt? Udviklerne får altid den tid, de beder om, ikke? Det virker ikke fair.
Du føler dig måske forurettet, og at din faglige vurdering bliver undermineret. Men problemet er, og har altid været, at testbudgettet i denne situation var fastlagt. Det eneste, du kan gøre, er at finde ud af, hvilken testning der er bedst eller mest værdifuld, og som du kan få presset ind i dit budget.
Men ofte vil projektlederen faktisk gerne vide, hvor lang tid tingene vil tage, så planen kan justeres. Hvis du mener, at du er i en forhandling, har du brug for nogle forhandlingsbrikker. Du skal også diskutere planens resultater, ikke inputtene. Omfanget er et resultat af planlægningen, mens den indsats, du lægger i det, er et input.
Du skal forhandle om omfanget.
Forhandling om testbudgetter bør altid handle om omfang, ikke indsats.
Omfanget kan præsenteres i ét eller flere formater, og måden, du præsenterer og diskuterer omfanget på, vil variere, men her er nogle almindelige mønstre. Uanset hvilket omfang du har, vil du bruge det som grundlag for dit estimat og din argumentation for det:
Omfang som en fortegnelse over krav eller funktioner
Når estimatet reduceres med 30 %, så spørg: “Hvilke 30 % af systemet skal jeg ikke teste?”
Omfang som en fortegnelse over risici
Når estimatet reduceres med 30 %, så spørg: “Hvilke interessentrisici skal jeg fjerne fra planen?”
Omfang som en tabel- eller grafisk model
Når estimatet reduceres med 30 %, så spørg: “Hvilke stier/rejser/elementer skal jeg fortælle interessenterne ikke vil blive testet?”
Jeg håber, du kan se, hvad der foregår her.
- Testningens omfang er baseret på en model, der først er blevet drøftet og aftalt med interessenterne. Dette omfang er foreløbigt og afhænger af, at der er tilstrækkelige ressourcer og tid til rådighed, og det bør du gøre interessenterne opmærksomme på.
- Du estimerer på grundlag af dette foreløbige omfang. Brug modellen (risici, krav, forretningsproces eller enhver anden model) til at fastsætte et dækningsmål, tæl dækningspunkterne, og lav estimatet på det grundlag.
- Tag en drøftelse med projektlederen. Hvis estimatet er for højt, så brug svarene ovenfor til at sætte gang i drøftelserne med interessenterne.
Som tester eller testleder er du ikke i en god position til at forhandle testningen med projektlederen. Interessenterne har bekymringerne, og hvis du deler de modeller, der definerer testningens omfang, vil de have holdninger, tage ejerskab over omfanget og kunne forsvare det. Interessenterne er også ansvarlige for at begrunde budgettet for deres system, så de er bedst placeret til at afveje omkostningerne ved testning mod behovet for at håndtere deres bekymringer.
Noget at tænke over
Overvej, hvem der i dine projekter tager ansvar for mængden af testning, der skal udføres:
- Definerer du som tester omfanget og mængden af testning?
- Fastlægger projektlederen et budget, og gør du det bedste, du kan, med den tid, du får tildelt?
- Forhandles omfanget med projektlederen og interessenterne for at blive enige om en balance mellem indsatsen og omfanget af den testning, der skal udføres?
Et af testerens vigtigste ansvarsområder er at sikre, at projektet er opmærksomt på de produktrisici, der løbes, og at dokumentere dem. Kun hvis disse risici er synlige, kan ledelsen erkende de risici, den påtager sig ved at begrænse testningen.
Der findes ingen formel for den rigtige mængde testning. I de fleste miljøer kan testniveauet kun fastlægges gennem enighed mellem projektledelsen, kundesponsorer, udviklere, tekniske specialister og testerne – test anses for at være en del af omfanget, hvis de håndterer de risici, der giver anledning til bekymring.
Tilstrækkelig testning bør fastlægges gennem enighed, hvor testeren faciliterer og bidrager med oplysninger til enighedsprocessen.
Tilmeld dig nyhedsbrevet for QA-ledere for at få besked, når nye dele af serien udkommer. Disse indlæg er uddrag fra Pauls kursus i ledelse inden for test, som vi varmt anbefaler, hvis du vil gå mere i dybden med dette og andre emner. Hvis du gør det, så brug vores eksklusive kuponkode QALEADOFFER for at få $60 i rabat på den fulde kursuspris!
Relaterede artikler:
