Ledarskap inom testning: Modellering och täckning
I programvarutestningens värld vet ett effektivt ledarskap hur man fastställer en tydlig riktning för hur teststrategier ska anpassas till utvecklingsmålen. När programvarusystem blir allt mer komplexa har traditionella testmetoder svårt att hålla jämna steg.
Det är här innovativa metoder som testmodellering och täckningsanalys blir avgörande. Dessa metoder säkerställer att teamen täcker kritiska flöden och kantfall samt möjliggör bättre samarbete, minskad risk och snabbare leveranser.
I den här artikeln utforskar vi vad det innebär att leda med modellering och täckning i åtanke. Vi diskuterar hur testledare kan använda dessa strategier för att optimera sina processer, förbättra produktkvaliteten och säkerställa en heltäckande testtäckning – samtidigt som de främjar en kultur av excellens och ansvarstagande. Oavsett om du är QA-chef, teamledare eller helt enkelt vill fördjupa din förståelse för testledarskap kommer den här guiden att ge dig praktiska insikter och tekniker för att höja nivån på ditt testarbete.
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
Låt oss börja.
Vad är en testmodell?
Testning är en process där vi skapar mentala modeller av miljön, programmet, människans natur och själva testerna. Varje modell används antingen tills vi accepterar att beteendet är korrekt eller tills modellen inte längre är tillräcklig för ändamålet.
Boris Beizer, Programvarutesttekniker, 1990
Testdesign är den process genom vilken vi väljer ut de tester som vi tror kommer att vara mest värdefulla för oss och våra intressenter, bland den uppsjö av tillgängliga alternativ. Testmodeller hjälper oss att välja tester på ett systematiskt sätt och är grundläggande för testning.
Så här använder testare modeller:
- Vi identifierar och utforskar kunskapskällor för att bygga testmodeller.
- Vi använder dessa modeller för att utmana och validera våra källor, vilket förbättrar både våra källor och våra modeller.
- Vi använder dessa modeller som underlag för både testning och utveckling.
Med ett testuppdrag framför oss är vår första uppgift att identifiera kunskapskällor. Dessa kan vara:
- Dokumentation: specifikationer, designer, krav, standarder, riktlinjer och så vidare.
- Människor: intressenter, användare, analytiker, designers, utvecklare och andra.
- Erfarenhet: din egen kunskap och erfarenhet av liknande (eller olikartade) system, dina preferenser, fördomar, gissningar, aningar, övertygelser och partiskheter.
- Nytt system: systemet som testas, om det finns, är tillgängligt och åtkomligt.
- Gammalt system: systemet som ska ersättas är uppenbarligen en källa – det kan inom vissa funktionsområden fungera som en orakelkälla för det förväntade beteendet.
Det är viktigt att notera att alla våra kunskapskällor är felbara och ofullständiga, och detsamma gäller våra modeller. Testare använder erfarenhet, kompetens och omdöme för att sålla bland dessa källor, jämföra dem, ställa dem mot varandra och utmana dem, och slutligen nå en konsensus.
Alla modeller är felaktiga, men vissa är användbara
George Box, ekonom.
En testmodell kan vara en checklista eller en uppsättning kriterier. Den kan också vara ett diagram som härletts från ett designdokument eller en analys av berättande text. Många testmodeller överförs aldrig till papper – de kan vara mentala modeller som konstruerats specifikt för att vägleda testaren när hen utforskar systemet som testas.
Modellernas syfte är att förenkla komplexa situationer genom att utelämna detaljer som inte är relevanta vid den aktuella tidpunkten. Vi använder modeller för att förenkla ett problem – till exempel för att välja vad som ska testas. Modellen påverkar vårt tänkande, och vi väljer tester genom att identifiera förekomster av någon viktig aspekt i modellen.
Vi kan välja grenar i ett flödesschema eller ett styrflödesdiagram, tillståndsövergångar i en tillståndsmodell, gränser i en modell av en indata- (eller utdata-)domän samt scenarier som härletts från användarberättelser skrivna i det domänspecifika språket Gherkin.
Men var försiktig: ibland gör modeller utelämnanden som inte är säkra – modellen kanske förenklar en situation alltför mycket – och vi måste vara uppmärksamma på detta. För att göra dina testmodeller effektivare är det viktigt att använda specialiserad programvara för testhantering.
Om vi inte har modeller direkt från våra källor måste vi skapa dem själva. När kraven till exempel presenteras som berättande text behöver vi använda kravens språk för att härleda funktioner och logiken bakom deras beteende. Detta kan vara svårt för utvecklare och testare och är ofta ett samarbete, men vi måste hålla fast vid det.
Att använda modeller för testning
Vi använder testmodeller för att:
- Förenkla testets sammanhang. Irrelevanta eller obetydliga detaljer ignoreras i modellen.
- Fokusera uppmärksamheten på ett perspektiv av systemets beteende. Det kan vara kritiska eller riskfyllda funktioner, tekniska aspekter, användaråtgärder av intresse eller aspekter av systemets konstruktion eller arkitektur.
- Generera en uppsättning unika tester (inom modellens sammanhang) som är varierade (i förhållande till modellen).
- Gör det möjligt att uppskatta, planera, övervaka och utvärdera testningen med avseende på dess fullständighet (täckning).
Ur testarnas perspektiv hjälper en modell oss att identifiera aspekter av systemet som kan vara föremål för ett test.
Modeller och täckning
Täckning är det begrepp vi använder för att beskriva hur grundliga eller fullständiga våra tester är i förhållande till vår testmodell. Ett täckningsobjekt är något som vi vill testa i våra tester.
Idealt bör vår testmodell identifiera täckningsobjekt på ett objektivt sätt. När vi har planerat eller genomfört tester som täcker objekt som identifierats av vår modell, kan vi kvantifiera den uppnådda täckningen och, som en andel av alla objekt i modellen, uttrycka denna täckning i procent.
Alla modeller som gör det möjligt att identifiera täckningsobjekt kan användas.
Modeller är ofta grafiska, med exempel som flödesscheman, användningsfall, sekvensdiagram och så vidare. Dessa och många andra modeller har element (eller blobbar) som är sammankopplade med linjer eller pilar. Dessa kallas vanligtvis riktade grafer.
Föreställ dig en grafisk modell som består av blobbar och pilar. Minst två täckningsmål kan definieras:
- Täckning av alla blobbar
- Täckning av alla pilar
- Och så vidare
Alltså kan alla modeller som är riktade grafer behandlas på samma sätt.
En formell modell gör det möjligt att identifiera täckningsobjekt på ett tillförlitligt sätt. Ett kvantitativt täckningsmått kan därför definieras och användas som ett mätbart mål.
Informella modeller tenderar att vara checklistor eller kriterier som används för att brainstorma fram en lista över täckningsobjekt, ge uppslag till testning eller för testning under en explorativ testsession. Dessa listor eller kriterier kan vara fördefinierade eller utarbetas som en del av en testplan eller antas under en explorativ testsession.
Informella modeller skiljer sig från formella modeller genom att härledningen av täckningsobjekt beror på yrkesutövarens erfarenhet, intuition och fantasi, vilket innebär att täckning med hjälp av dessa modeller aldrig kan kvantifieras. Vi kan aldrig veta vad fullständig täckning innebär i förhållande till dessa modeller.
Tester som härleds från en informell modell är lika giltiga som tester som härleds från en formell modell, om de ökar vår kunskap om systemets beteende eller kapacitet.
Modeller förenklar, så använd fler än en
En bra modell ger ett sätt att förstå komplexitet och uppnår detta delvis genom att utesluta detaljer som inte är relevanta. Din modell kan använda begreppet tillstånd, fellägen eller flöden, indatakombinationer, domänvärden och så vidare.
En modell räcker aldrig för att testa ett system fullständigt. Alla modeller innebär kompromisser, så vi behöver flera modeller. Detta koncept kallas vanligtvis ”varierade halvlösningar”. Det innebär att vi behöver en mångfald av partiella modeller för att testa ett system ordentligt.
Även om det vanligtvis inte beskrivs med dessa termer använder testfaserna i ett vattenfallsprojekt modeller ur olika perspektiv. Enhets-, delsystemsintegrations-, systemnivå- och användartester har olika mål; vart och ett använder en annan modell och ett annat perspektiv – det är här variationen kommer ifrån.
Använda modeller för styrning
Modeller står i centrum för testning och även för testhantering. Det finns fyra centrala aspekter av detta:
- Intressentengagemang
- Omfattning
- Täckning
- Uppskattning och övervakning av framsteg
Intressentengagemang
När vi planerar och definierar testernas omfattning samt förklarar framsteg och innebörden av täckning för intressenter, måste vi använda modeller som är begripliga och meningsfulla utifrån intressenternas mål.
Om vi planerar ett användartest kommer vi förmodligen att använda affärsprocessflödet som vår modell och som en mall för att följa de vägar där vi kan testa systemfunktioner som är viktiga för användaren. Om vi testar integreringen av tjänstekomponenter på uppdrag av en teknisk arkitekt använder vi den arkitektoniska modellen, samarbetsdiagram, gränssnittsspecifikationer och så vidare som grund för testningen. Om vi testar funktioner som definierats av användare använder vi de användarberättelser som blev resultatet av tidigare gemensamt kravarbete.
Om intressenterna inte förstår era modeller kommer de inte att förstå, lita på eller investera i er testning. De kanske inte ens litar på er.
Hantera omfattning
Den första aktiviteten inom ett systemtänkande är att definiera en systemgräns. Inom testning hjälper den första modellen du definierar dig att fastställa testningens omfattning. Diagrammet nedan är ett schematiskt diagram över systemarkitekturen – ett ”system av system” – i en organisation.
Varje system (de koncentriska cirklarna) ingår i ett applikationsområde, till exempel CRM, redovisning eller webbplatsen. Alla system och applikationsområden ingår i ”systemet av system”. Det finns naturligtvis inga detaljer i modellen, men det är lätt att se hur varje system passar in i den övergripande arkitekturen.
Vi skulle enkelt kunna definiera omfattningen av vår testning som ERP-systemen, till exempel.
I det andra diagrammet nedan har vi lagt till mer detaljer i systemarkitekturen och föreslagit tre sätt att definiera omfattningen mer specifikt.
- Systemen som är skuggade i gult är de så kallade registreringssystemen. Dessa system kan till exempel dela databas, och ändringar i databasschemat kan påverka något av dessa system negativt – och därför ingå i testomfattningen.
- Systemen som omges av den lila linjen kan dela viss gemensam funktionalitet eller infrastruktur – kanske använder de alla en gemensam uppsättning webbtjänster, samma meddelandesystem eller körs på samma server.
- Den streckade blå linjen visar en användarresa som använder de system som är anslutna till linjen. Kanske har användarresan förändrats och vårt fokus ligger på konsekvensen och noggrannheten i dataflödet mellan dessa system.
En modell kan visa vad som ingår i testomfattningen, men lika viktigt är att den visar vad som inte ingår.
En modell hjälper till att definiera omfattningen av ett test och även att förklara omfattningen för intressenter på ett sätt som de förstår, uppskattar och (förhoppningsvis) godkänner.
När vi använder en modell för att definiera omfattningen avgränsar modellen området, och de delar som ingår identifierar de platser vi avser att utforska och testa.
Hantera täckning
Täckningsmätning kan bidra till att göra testningen mer hanterbar. Om vi inte har en uppfattning om täckningen kanske vi inte kan svara på frågor som ”vad har testats?”, ”vad har inte testats?”, ”är vi klara än?”, ”hur många tester återstår?”. Detta är särskilt besvärligt för en testledare.
Den täckning vi planerar att uppnå är det naturliga nästa steget när omfattningen väl har definierats.
Vi använder omfattningsmodellen för att definiera de platser där vi ska testa. Vår täckningsmodell berättar för intressenter hur grundligt vi planerar att testa på dessa platser.
Testmodeller och täckningsmått kan användas för att definiera kvantitativa eller kvalitativa mål för testutformning och testgenomförande. I varierande grad kan vi använda sådana mål för att planera och uppskatta. Vi kan också mäta framsteg och bedöma hur grundlig eller komplett den testning vi har planerat eller genomfört är. Vi måste dock vara mycket försiktiga med alla kvantitativa täckningsmått eller procentsatser som vi använder.
Ett täckningsmått (baserat på en formell testmodell) kan beräknas objektivt, men det finns ingen formel eller lag som säger att X täckning innebär Y kvalitet eller Z tillförlitlighet. Alla täckningsmått ger endast indirekta, kvalitativa och subjektiva insikter i hur grundlig eller komplett vår testning är. Det finns inget meningsfullt samband mellan täckning och systemens kvalitet eller acceptans.
Kvantitativa täckningsmål används ofta för att definiera avslutningskriterier för när testningen är klar, men dessa kriterier är godtyckliga. Ett striktare täckningsmål kan innebära att dubbelt så många delar behöver täckas. Men dubbelt så många tester som kostar dubbelt så mycket gör inte ett system dubbelt så vältestat eller dubbelt så tillförlitligt. En sådan tolkning är meningslös och oklok.
Ibland kan de formella modeller som används för att definiera och bygga ett system åläggas testarna, så att de kan använda dem för att definiera täckningsmål. Vid andra tillfällen kan testarna ha mycket lite dokumentation att arbeta med och måste skapa egna modeller. Valet av testmodell och täckningsmål är i viss mån godtyckligt och subjektivt. Följaktligen kan informella testmodeller och täckningsmått vara lika användbara som etablerade, formella modeller.
Snabb övning i modellskapande
En snabb avslutande övning. Skissa i följande exempel på hur du tror att modellen kan se ut – endast dess form – antingen som en bild/ett diagram, en tabell eller en lista:
- Användarna är intresserade av resorna genom hela systemet, från början till slut.
- En meddelandetjänst kan befinna sig i fyra tillstånd: avstängd, körs, startar och stängs av.
- En kalkylator för försäkringspremier har 40 indatavärden som tillsammans påverkar beräkningen; det finns beroenden mellan vissa indata.
- En extraherings-, transformerings- och inläsningsprocess har sju steg. Efter extraheringen avvisar varje steg antingen poster, skickar dem till en väntfil eller transformerar och skickar posterna vidare till nästa steg. Det sista steget är en inläsningsprocess som hanterar avvisningar. Testa att alla extraherade poster är redovisade.
Anmäl dig till The CTO Clubs nyhetsbrev för fler insikter om testning!
