Ledarskap inom testning: Hur mycket testning är tillräckligt?
Redaktörens anmärkning: Välkommen till serien Leadership In Test från gurun inom programvarutestning och konsulten Paul Gerrard. Serien är utformad för att hjälpa testare med några års erfarenhet – särskilt de som arbetar i agila team – att lyckas i roller som testledare och testchefer.
I föregående artikel beskrev vi ett riskmanifest som hjälp för chefer. I den här artikeln ska vi ställa den tidlösa frågan ”Hur mycket testning är tillräckligt?”. Avslöjande: det är upp till intressenterna.
Anmäl dig till nyhetsbrevet från The QA Lead för att få ett meddelande när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls Leadership In Test-kurs, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det kan du använda vår exklusiva kupongkod QALEADOFFER för att få 60 dollar rabatt på det ordinarie kurspriset!
Hur mycket testning är tillräckligt? Det här är den klassiska, obesvarbara, filosofiska frågan som alla testare ställer eftersom de själva får den från sina intressenter.
Intressenterna vill veta eftersom de vill vara säkra på att systemen har testats tillräckligt, men eftersom de betalar för det och har deadlines att hålla vill de också veta den potentiella kostnaden för testningen och hur lång tid den kommer att ta.
Därför är det intressenterna som ska avgöra hur mycket testning som är tillräckligt. Ditt jobb som testchef är att ge dem så mycket värde du kan genom att hjälpa dem att fatta ett beslut. I den här artikeln går vi igenom:
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
- Värdet av testning för intressenter
- Kvantteorin och relativitetsteorin (inte fysik)
- Att använda rätt språk
- Estimat, budgetar och förhandling
Vi börjar.
Värdet av testning för intressenter
Varje test vi kör bör ha ett värde för intressenterna genom att det ger belägg som stödjer deras beslutsfattande på fyra sätt:
- Belägg för att systemet kommer att uppfylla projektets affärsmål.
- Belägg för att systemet inte kommer att fallera, eller att konsekvenserna av ett fel är hanterbara om det ändå gör det.
- Belägg för att återskapa och diagnostisera fel samt reparera och testa om det felaktiga systemet.
- Belägg som stöd för beslutsfattande i projektets sammanhang (att godkänna, att släppa, att avvisa osv.)
Vårt mål med testningen är att skapa tester som stegvis ökar testtäckningen av systemet i förhållande till en igenkännbar testmodell. Våra tester bör visa att systemet kommer att uppfylla affärsmålen och att risken för fel är känd och förhoppningsvis acceptabel.
Av de fyra typerna av belägg ovan ligger de tre första till grund för den fjärde. I slutändan måste intressenterna fatta ett evidensbaserat beslut. Det är deras beslut att fatta, inte testarnas, så det är de som ska avgöra om de har tillräckligt med information för att känna sig trygga. Hur som helst ligger värdet av testning i betraktarens öga.
Alla testare gör nu val kring vad som ska testas genom att använda en formell modell eller till och med magkänsla. Dessa val görs utifrån något upplevt värde.
Såvida testaren inte också är intressenten bedömer testaren vanligtvis värdet utifrån något mått på fullständighet eller täckning. Eller, om testaren känner till intressenternas tankar, utifrån om testet kommer att stödja något godkännandebeslut.
Ovanstående grundsatser får några viktiga konsekvenser.
För det första: om du inte känner till intressentens uppfattning är det osannolikt att din uppfattning om testvärdet överensstämmer med deras. Om du väljer tester utan hänsyn till deras värderingar kan dina intressenter, när det är dags att presentera resultaten, upptäcka att de har otillräckligt med data inom vissa områden och ett överskott inom andra. De kommer definitivt inte att känna sig så trygga som de borde.
För det andra: när du utformar eller kör ett test, vad bidrar det med till intressenternas beslutsfattande? Om ett test inte ger någon ny information som stödjer ett beslut, eller om intressenterna inte bryr sig om huruvida ditt test klarar eller misslyckas, har det ingen plats i en testplan.
Vi sade i artikel 3 om modeller att de testmodeller du använder måste vara relevanta för intressenterna. Om dina testresultat kan kopplas till modeller som intressenterna förstår och värdesätter, kommer de att värdesätta ditt bidrag.
Kvantteorin och relativitetsteorin
Det finns ytterligare två principer som rör testernas värde och betydelse. Jag kallar den ena kvantteorin och den andra relativitetsteorin. Dessa benämningar låter pretentiösa (de är definitivt skämtsamt menade), men de beskriver två fenomen som ligger till grund för alla diskussioner om testvärde, prioritering och avgränsning.
När vi genomför ett test tolkar vi vanligtvis resultatet som godkänt eller underkänt. Bedömningen godkänt/underkänt är ett binärt resultat – sant eller falskt, ja eller nej, ett eller noll. Testresultatet genererar en diskret mängd evidens. Evidensen byggs upp allt eftersom vi genomför fler och fler tester. Oavsett resultat ökar testet stegvis täckningen av vår testmodell och den kunskap vi har om systemets beteende. Tester som inte ökar vår kunskap tillför inget värde.
Om ett test inte stegvis ökar täckningen på något sätt har det litet värde.
Den andra aspekten är värdet av ett test. Vad är värdet av ett test? Skulle du verkligen kunna sätta ett dollar-, pund- eller eurovärde på ett enskilt test? Förmodligen inte. Men vad vi kan göra – och ofta ganska enkelt – är att säga: ”det här testet är mer värdefullt än det där”.
Anta att vi använder en modell för kodtäckning, till exempel instruktionstäckning. Vi skulle kunna köra ett test som kör fem kodrader eller fem tusen kodrader. Vad är värdet av vart och ett? Det är svårt att säga. Men om vårt mål är instruktionstäckning har det andra testet större värde.
Vi kan inte sätta ett absolut värde på något test, men vi kan vanligtvis jämföra tester och dra slutsatser om det relativa värdet av vart och ett. Det innebär att vi, om vi har ont om tid, vanligtvis kan säga att ett test har mindre värde än ett annat och därför avgränsa bort det första testet om vi måste.
Vi kan jämföra värdet av tester, men bara om de härstammar från samma modell.
Vi måste dock betona att dessa jämförelser egentligen bara är meningsfulla om de bygger på samma modell. Ett test som täcker ett stort spektrum av extrema förhållanden i en process har förmodligen större värde än ett test av den ”raka genomgående vägen”. Ände-till-ände-tester av en komplex process kan till exempel inte jämföras direkt med enhetstester av kritiska komponenter.
Även om teorierna om kvantmekanik och relativitet kanske inte är direkt tillämpliga på testning, är principerna om anpassningsförmåga och perspektiv det. Hitta ett testhanteringsverktyg som överensstämmer med dessa principer för att optimera din teststrategi.
Att använda rätt språk
Nu när vi har fastställt vem som ansvarar för att avgöra ”hur mycket testning som är tillräckligt”, hur kan vi som samvetsgranna testare stödja detta beslutsfattande?
Observera att vår behandling av testernas värde liknar vår riskbedömning mycket. Som vi diskuterade i föregående artikel är det mycket svårt att sätta numeriska värden på riskens omfattning eller exponering. Det är dock vanligtvis möjligt att jämföra en risk med en annan och rangordna dem för att fatta beslut om vilka risker som ska omfattas av testningen.
Genom att använda riskens språk blir testare hörda av ledningen.
Ledare för utvecklingsteam verkar ofta bli lyssnade på av chefer, även när de talar i tekniska termer. Skillnaden är att de presenterar tekniken som spännande och fördelaktig. När testare talar med sina egna tekniska termer – om testernas ”administrativa” detaljer, såsom statistik över incidenter – tenderar budskapet att bli negativt, och chefer kan bli uttråkade eller irriterade.
Ledningen kanske redan tycker att testare är något tråkiga som yrkesgrupp, men det beror rimligen på att många chefer inte riktigt förstår vad testare gör och vilket värde de tillför. Testare bör därför höja sitt språk till ledningsnivå.
Riskbaserad testning talar till användar- och projektledningen på deras språk.
Det här är personer som i hög grad tänker i termer av risker och fördelar. Om testare vänder sig till dem med liknande termer är det mer sannolikt att ledningen lyssnar på testarna och därigenom fattar bättre beslut. Genom att relatera testerna till projektets mål kan vi rikta uppmärksamheten mot de leveranser som har störst värde för intressenterna, så att vi ägnar vår tid åt att testa de viktigaste sakerna.
Dessutom kan vi, allt eftersom testningen fortskrider, visa att de mest värdefulla fördelarna nu är tillgängliga. Beslutet om lansering är i slutändan en bedömning av om de uppnådda fördelarna överväger riskerna, så testningen kommer att ge ledningen bättre data att basera sina beslut på.
Använd riskernas (och fördelarnas) språk för att avgränsa, planera och rapportera om testningens framsteg.
Testare behöver självklart tala tekniskt med utvecklare och annan teknisk personal. Kvaliteten på incidentrapporter är till exempel en nyckelfaktor för att få fel korrigerade snabbt och tillförlitligt. Jag säger helt enkelt att testaren, när han eller hon talar med ledningen, talar i termer av hanterade och kvarstående risker i stället för tester, incidenter och fel.
Uppskattningar, budgetar och förhandling
Tidigt i ett nytt projekt frågar projektledaren dig: ”Jag behöver planera och bemanna testningen i god tid. Kan du ge mig en uppskattning av hur många personer du behöver och hur lång tid du behöver för att genomföra systemtestningen?”
Du tänker efter en stund och går för att prata med chefen.
”Jag behöver sex testare i åtta veckor.”
Projektledaren tänker efter en stund och rådfrågar sitt utkast till tidplan och sin resursplan.
”Du kan få fyra testare i sex veckor, och det är allt.”
Du invänder och säger: ”Men det kommer att ta längre tid än sex veckor! Det kommer att kosta mer än det du har avsatt för att testa det här systemet. Systemet är större än förra gången. Det är mer komplicerat. Det är definitivt för riskabelt för oss att spara in på testningen den här gången. Det räcker helt enkelt inte.”
Men projektledaren är orubblig och mumlar något om andra beroenden, högre chefer och så vidare …
Vad tror du var poängen med att göra en uppskattning om projektledaren hela tiden visste hur stor budgeten måste vara? Vilken relevans har en godtycklig budget för det aktuella arbetet? Varför tar de aldrig testning på allvar? Utvecklarna får alltid den tid de ber om, eller hur? Det verkar inte rättvist.
Du kanske känner dig kränkt och att ditt professionella omdöme undergrävs. Men problemet är, och har alltid varit, att testbudgeten i den här situationen var fastställd. Allt du kan göra är att ta reda på vilken testning som är bäst eller mest värdefull och som ryms inom din budget.
Men ofta vill projektledaren faktiskt veta hur lång tid saker kommer att ta, så att planen kan justeras. Om du tror att du befinner dig i en förhandling behöver du ha några förhandlingsargument att använda. Du behöver också diskutera planens resultat, inte dess indata. Omfattningen är ett resultat av planeringen, medan den arbetsinsats du tillför är en indata.
Du behöver förhandla om omfattningen.
Förhandlingar om testbudgetar bör alltid handla om omfattning, inte arbetsinsats.
Omfattningen kan uttryckas i ett eller flera format, och hur du presenterar och diskuterar omfattningen kommer att variera, men här är några vanliga mönster. Oavsett vilken omfattning du har använder du den som grund för din uppskattning och för att försvara den:
Omfattning som en förteckning över krav eller funktioner
När uppskattningen minskas med 30 % frågar du: ”Vilka 30 % av systemet ska jag inte testa?”
Omfattning som en förteckning över risker
När uppskattningen minskas med 30 % frågar du: ”Vilka intressentrisker ska jag ta bort från planen?”
Omfattning som en tabellbaserad eller grafisk modell
När uppskattningen minskas med 30 % frågar du: ”Vilka vägar, användarresor eller objekt ska jag meddela intressenterna inte kommer att testas?”
Jag hoppas att du ser vad som pågår här.
- Testningens omfattning baseras på någon modell som först har diskuterats och godkänts tillsammans med intressenterna. Denna omfattning är preliminär och förutsätter att resurser och tid finns tillgängliga, och du bör göra intressenterna medvetna om detta.
- Du gör uppskattningen utifrån denna preliminära omfattning. Använd modellen (risker, krav, affärsprocess eller någon annan modell) för att fastställa ett täckningsmål, räkna antalet täckningsobjekt och göra uppskattningen utifrån det.
- Ha en diskussion med projektledaren. Om uppskattningen är för hög använder du svaren ovan för att inleda diskussionerna med intressenterna.
Som testare eller testledare har du inte ett bra utgångsläge för att förhandla om testningen med projektledaren. Intressenterna har invändningarna, och om du delar de modeller som definierar testningens omfattning kommer de att ha åsikter, ställa sig bakom omfattningen och kunna försvara den. Intressenterna ansvarar också för att motivera budgeten för sitt system, så de har bäst förutsättningar att balansera kostnaden för testningen mot behovet av att hantera deras invändningar.
Något att fundera på
Fundera på vem i dina projekt som tar ansvar för hur mycket testning som ska utföras:
- Definierar du som testare testningens omfattning och mängd?
- Fastställer projektledaren en budget och gör du så gott du kan med den tid du har tilldelats?
- Förhandlas omfattningen med projektledaren och intressenterna för att komma överens om en balans mellan arbetsinsatsen och omfattningen av den testning som ska utföras?
Ett av testarnas viktigaste ansvarsområden är att se till att projektet är medvetet om de produktrisker som tas och att dokumentera dem. Endast om dessa risker är synliga kan ledningen förstå vilka risker de tar genom att minska testningen.
Det finns ingen formel för rätt mängd testning. I de flesta miljöer kan testningens omfattning endast fastställas genom konsensus mellan projektledning, kundernas sponsorer, utvecklare, tekniska specialister och testare – tester anses ingå i omfattningen om de hanterar de risker som är aktuella.
Tillräcklig testning bör fastställas genom konsensus, där testaren underlättar och bidrar med information till konsensusprocessen.
Anmäl dig till nyhetsbrevet från The QA Lead för att få ett meddelande när nya delar av serien publiceras. Dessa inlägg är utdrag ur Pauls kursen Ledarskap inom testning, som vi varmt rekommenderar om du vill fördjupa dig i detta och andra ämnen. Om du gör det, använd vår exklusiva rabattkod QALEADOFFER för att få 60 USD i rabatt på hela kurspriset!
Relaterade artiklar:
