Lederskab inden for test: Modellering og dækning

I softwaretestens verden ved effektiv ledelse, hvordan man sætter en klar retning for, hvordan teststrategier stemmer overens med udviklingsmålene. Efterhånden som softwaresystemer bliver stadig mere komplekse, har traditionelle testmetoder svært ved at følge med.

Det er her, innovative tilgange som testmodellering og dækningsanalyse bliver afgørende. Disse praksisser sikrer, at teams dækker kritiske forløb og randtilfælde, og de muliggør bedre samarbejde, reduceret risiko og hurtigere levering.

I denne artikel undersøger vi, hvad det vil sige at lede med modellering og dækning for øje. Vi ser på, hvordan testledere kan udnytte disse strategier til at optimere deres processer, forbedre produktkvaliteten og sikre omfattende testdækning – samtidig med at de fremmer en kultur præget af høj kvalitet og ansvarlighed. Uanset om du er QA-chef, teamleder eller blot ønsker at uddybe din forståelse af testledelse, vil denne vejledning udstyre dig med praktisk anvendelig indsigt og teknikker, der kan løfte dit testarbejde.

Lad os komme i gang.

Hvad er en testmodel?

Test er en proces, hvor vi skaber mentale modeller af miljøet, programmet, menneskets natur og selve testene. Hver model anvendes, indtil vi accepterer, at adfærden er korrekt, eller indtil modellen ikke længere er tilstrækkelig til formålet.

Boris Beizer, Software Test Techniques, 1990

Testdesign er den proces, hvor vi blandt de mange tilgængelige muligheder udvælger de test, som vi mener vil være mest værdifulde for os og vores interessenter. Testmodeller hjælper os med at udvælge test på en systematisk måde og er grundlæggende for test.

Den måde, testere anvender modeller på:

1. Vi identificerer og udforsker videnskilder for at opbygge testmodeller.
2. Vi bruger disse modeller til at udfordre og validere vores kilder, så både vores kilder og modeller forbedres.
3. Vi bruger disse modeller til at informere både test og udvikling.

Med en testmission som udgangspunkt er vores første opgave at identificere videnskilder. Det kan være:

• Dokumentation: specifikationer, design, krav, standarder, retningslinjer og så videre.
• Mennesker: interessenter, brugere, analytikere, designere, udviklere og andre.
• Erfaring: din egen viden og erfaring med lignende (eller forskellige) systemer, dine præferencer, fordomme, gæt, mavefornemmelser, overbevisninger og skævheder.
• Nyt system: systemet under test, hvis det findes, er tilgængeligt og kan tilgås.
• Gammelt system: systemet, der skal erstattes, er naturligvis en kilde – det kan inden for visse funktionalitetsområder fungere som en facitliste for den forventede adfærd.

Det er vigtigt at bemærke, at alle vores videnskilder er fejlbarlige og ufuldstændige, og det samme gælder vores modeller. Testere bruger erfaring, færdigheder og dømmekraft til at gennemgå disse kilder, sammenligne dem, holde dem op mod hinanden og udfordre dem for at nå frem til en konsensus. 

Alle modeller er forkerte, men nogle er nyttige

George Box, økonom.

En testmodel kan være en tjekliste eller et sæt kriterier. Den kan også være et diagram, der er udledt af et designdokument, eller en analyse af en fortællende tekst. Mange testmodeller bliver aldrig skrevet ned – de kan være mentale modeller, der er konstrueret specifikt for at vejlede testeren, mens vedkommende udforsker systemet under test.

Formålet med modeller er at forenkle komplekse situationer ved at udelade detaljer, der ikke er relevante på det pågældende tidspunkt. Vi bruger modeller til at forenkle et problem – for eksempel til at udvælge ting, der skal testes. Modellen påvirker vores tænkning, og vi udvælger test ved at identificere forekomster af bestemte nøgleaspekter i modellen.

Vi kan udvælge grene i et flowchart eller et kontrolflowdiagram, tilstandsovergange i en tilstandsmodel, grænser i en model af et input- (eller output-)domæne samt scenarier, der er udledt af brugerhistorier skrevet i det domænespecifikke sprog Gherkin.

Men pas på: Modeller kan undertiden medføre udeladelser, der ikke er sikre – måske overforenkler modellen en situation – og det skal vi være opmærksomme på. Hvis du vil gøre dine testmodeller mere effektive, er det afgørende at benytte specialiseret teststyringssoftware.

Hvis vi ikke har modeller direkte fra vores kilder, er vi nødt til at opfinde dem. Når krav for eksempel præsenteres som fortællende tekst, skal vi bruge kravsproget til at udlede funktioner og logikken bag deres adfærd. Det kan være vanskeligt for udviklere og testere og er ofte et samarbejde, men vi må holde fast.

Brug af modeller til test

Vi bruger testmodeller til at:

• Forenkle testens kontekst. Irrelevante eller ubetydelige detaljer ignoreres i modellen.
• Fokuser opmærksomheden på ét perspektiv af systemets adfærd. Det kan være kritiske eller risikable funktioner, tekniske aspekter, brugerhandlinger af interesse eller aspekter af systemets opbygning eller arkitektur.
• Generér et sæt unikke tests (inden for modellens kontekst), som er forskelligartede (i forhold til modellen).
• Gør det muligt at estimere, planlægge, overvåge og evaluere testningen med hensyn til dens fuldstændighed (dækning).

Fra testerens synspunkt hjælper en model os med at genkende aspekter af systemet, som kan være genstand for en test.

Modeller og dækning

Dækning er det begreb, vi bruger til at beskrive grundigheden eller fuldstændigheden af vores testning i forhold til vores testmodel. Et dækningselement er noget, vi ønsker at afprøve i vores tests.

Ideelt set bør vores testmodel identificere dækningselementer på en objektiv måde. Når vi har planlagt eller udført tests, der dækker elementer identificeret af vores model, kan vi kvantificere den opnåede dækning og udtrykke denne dækning som en procentdel i forhold til alle elementer i modellen.

Enhver model, der gør det muligt at identificere dækningselementer, kan bruges.

Modeller er ofte grafiske, med eksempler som flowdiagrammer, anvendelsestilfælde, sekvensdiagrammer og så videre. Disse og mange andre modeller har elementer (eller figurer), der er forbundet med linjer eller pile. Disse kaldes normalt rettede grafer. 

Forestil dig en grafisk model, der består af figurer og pile. Mindst to dækningsmål kan defineres:

• Dækning af alle figurer
• Dækning af alle pile
• Og så videre

Så enhver model, der er en rettet graf, kan behandles på samme måde.

Uformelle modeller har en tendens til at være tjeklister eller kriterier, der bruges til at brainstorme en liste over dækningselementer, fremkalde idéer til testning eller til testning i en eksplorativ testsession. Disse lister eller kriterier kan være foruddefinerede eller udarbejdet som en del af en testplan eller taget i brug i en eksplorativ testsession.

Uformelle modeller adskiller sig fra formelle modeller ved, at udledningen af dækningselementer afhænger af den fagkyndiges erfaring, intuition og fantasi, så dækning ved hjælp af disse modeller aldrig kan kvantificeres. Vi kan aldrig vide, hvad fuldstændig dækning betyder i forhold til disse modeller.

Modeller forenkler, så brug mere end én

En god model giver mulighed for at forstå kompleksitet og opnår dette delvist ved at udelukke detaljer, der ikke er relevante. Din model kan bruge begrebet tilstand, fejltilstande eller flows, inputkombinationer, domæneværdier og så videre. 

Én model er aldrig nok til at teste et system fuldstændigt. Alle modeller indebærer kompromiser, så vi har brug for flere modeller. Dette begreb omtales normalt som »forskelligartede halvtiltag«. Det betyder, at vi har brug for en mangfoldighed af delvise modeller for at teste et system ordentligt.

Selvom det normalt ikke beskrives med disse termer, bruger testfaserne i et vandfaldsprojekt modeller fra forskellige perspektiver. Enhedstest, integrationstest på delsystemniveau, test på systemniveau og brugertest har alle forskellige mål; hver af dem bruger en forskellig model og et forskelligt perspektiv – det er her, mangfoldigheden kommer fra.

Brug af modeller til styring

Modeller er kernen i testning og også i teststyring. Der er fire centrale aspekter ved dette:

• Inddragelse af interessenter
• Omfang
• Dækning
• Estimering og overvågning af fremdrift

Inddragelse af interessenter

Når vi planlægger og afgrænser tests samt forklarer fremdrift og betydningen af dækning for interessenter, skal vi bruge modeller, der er forståelige og meningsfulde i forhold til interessenternes mål.

Hvis vi planlægger en brugertest, vil vi sandsynligvis anvende forretningsprocesflowet som vores model og som en skabelon til at spore stier, der afprøver de systemfunktioner, som er vigtige for brugeren. Hvis vi tester integrationen af service-komponenter på vegne af en teknisk arkitekt, vil vi bruge den arkitektoniske model, samarbejdsdiagrammer, grænsefladespecifikationer og så videre som grundlag for vores test. Hvis vi tester funktioner, der er defineret af brugere, vil vi bruge de brugerhistorier, der var resultatet af tidligere samarbejdsbaseret kravarbejde.

Hvis interessenterne ikke forstår dine modeller, vil de ikke forstå, have tillid til eller investere i din test. De har måske endda ikke tillid til dig.

Håndtering af omfang

Den første aktivitet inden for systemtænkning er at definere en systemgrænse. Ved test vil den første model, du definerer, hjælpe dig med at afgrænse testen. Diagrammet nedenfor er en skematisk fremstilling af systemarkitekturen – et ’system af systemer’ – i en organisation.

Hvert system (de koncentriske cirkler) befinder sig inden for et applikationsområde såsom CRM, regnskab eller webstedet. Alle systemer og applikationsområder befinder sig inden for ’systemet af systemer’. Der er naturligvis ingen detaljer i modellen, men det er let at se, hvordan hvert system passer ind i den overordnede arkitektur.

Vi kunne for eksempel nemt definere omfanget af vores test som ERP-systemerne.

I det andet diagram nedenfor har vi tilføjet flere detaljer til systemarkitekturen og foreslået tre måder, hvorpå vi kunne definere omfanget mere specifikt.

• De systemer, der er markeret med gult, er de såkaldte registreringssystemer. Disse systemer deler for eksempel muligvis en database, og ændringer i databaseskemaet kan påvirke ethvert af disse systemer negativt – og være omfattet af testen.
• De systemer, der er omgivet af den lilla linje, deler muligvis nogle fælles funktioner eller en fælles infrastruktur – måske bruger de alle et fælles sæt webtjenester, det samme beskedsystem eller kører på den samme server.
• Den stiplede blå linje angiver en brugerrejse, der benytter de systemer, som linjen forbinder. Måske er brugerrejsen blevet ændret, og vores fokus er på konsistensen og nøjagtigheden af datastrømmen mellem disse systemer.

En model hjælper med at definere omfanget af en test og også med at forklare omfanget for interessenter på en måde, de forstår, værdsætter og (forhåbentlig) godkender.

Håndtering af dækning

Måling af testdækning kan bidrage til at gøre test mere håndterbar. Hvis vi ikke har en opfattelse af dækningen, kan vi måske ikke besvare spørgsmål som ’hvad er blevet testet?’, ’hvad er ikke blevet testet?’, ’er vi færdige endnu?’, ’hvor mange test mangler?’ Dette er særligt besværligt for en testleder.

Den dækning, vi planlægger at opnå, er det naturlige næste skridt, når omfanget er defineret.

Testmodeller og dækningsmål kan bruges til at definere kvantitative eller kvalitative mål for testdesign og -udførelse. I varierende grad kan vi bruge sådanne mål til at planlægge og estimere. Vi kan også måle fremskridt og udlede grundigheden eller fuldstændigheden af den test, vi har planlagt eller udført. Vi skal dog være meget forsigtige med alle kvantitative dækningsmål eller procenttal, vi bruger.

Et dækningsmål (baseret på en formel testmodel) kan beregnes objektivt, men der findes ingen formel eller lov, der siger, at X-dækning betyder Y-kvalitet eller Z-tillid. Alle dækningsmål giver kun indirekte, kvalitative og subjektive indsigter i grundigheden eller fuldstændigheden af vores test. Der er ingen meningsfuld sammenhæng mellem dækning og systemernes kvalitet eller acceptabilitet.

Kvantitative dækningsmål bruges ofte til at definere afslutningskriterier for færdiggørelsen af test, men disse kriterier er arbitrære. Et strengere dækningsmål kan generere dobbelt så mange elementer, der skal dækkes. Dobbelt så mange test, der koster dobbelt så meget, gør dog ikke et system dobbelt så gennemtestet eller dobbelt så pålideligt. En sådan fortolkning er meningsløs og tåbelig.

Nogle gange kan de formelle modeller, der bruges til at definere og opbygge et system, blive pålagt testerne, så de kan bruge dem til at definere dækningsmål. På andre tidspunkter har testerne måske kun sparsom dokumentation at arbejde med og er nødt til selv at opfinde modeller. Valget af testmodel og dækningsmål er i nogen grad vilkårligt og subjektivt. Derfor kan uformelle testmodeller og dækningsmål være lige så nyttige som etablerede, formelle modeller.

Hurtig øvelse i modeludarbejdelse

En hurtig afsluttende øvelse. I de følgende eksempler skal du skitsere, hvordan du mener, modellen kunne se ud – kun dens form – enten som et billede/diagram, en tabel eller en liste:

• Brugerne er optagede af de sammenhængende forløb gennem systemet.
• En beskedtjeneste kan være i fire tilstande: lukket ned, kørende, starter op og lukker ned.
• En beregner til forsikringspræmier har 40 inputværdier, som tilsammen påvirker beregningen; der er afhængigheder mellem nogle af inputtene.
• En proces til udtræk/transformering/indlæsning har syv trin. Efter udtrækningen afviser hvert trin enten poster, sender dem til en suspensefil eller transformerer og sender posterne videre til det næste trin. Det sidste trin er en indlæsningsproces, som håndterer afvisninger. Test, at der er redegjort for alle udtrukne poster.

Tilmeld dig The CTO Clubs nyhedsbrev for at få flere indsigter om test!