Lederskap i testing: Modellering og dekning

I programvaretestingens verden vet effektiv ledelse hvordan man setter en tydelig retning for hvordan teststrategier samsvarer med utviklingsmålene. Etter hvert som programvaresystemer blir stadig mer komplekse, får tradisjonelle testmetoder problemer med å holde tritt.

Det er her innovative tilnærminger som testmodellering og dekningsanalyse blir avgjørende. Disse praksisene sikrer at teamene dekker kritiske stier og spesialtilfeller, og legger til rette for bedre samarbeid, redusert risiko og raskere levering.

I denne teksten skal vi utforske hva det innebærer å lede med modellering og dekning i tankene. Vi skal se på hvordan testledere kan utnytte disse strategiene til å optimalisere prosessene sine, forbedre produktkvaliteten og sikre omfattende testdekning – samtidig som de fremmer en kultur preget av fremragende arbeid og ansvarlighet. Enten du er QA-leder, teamleder eller bare ønsker å utdype forståelsen din av testledelse, vil denne veiledningen gi deg praktisk innsikt og teknikker som kan løfte testarbeidet ditt.

La oss sette i gang.

Hva er en testmodell?

Testing er en prosess der vi lager mentale modeller av miljøet, programmet, menneskets natur og selve testene. Hver modell brukes enten til vi aksepterer at atferden er korrekt, eller til modellen ikke lenger er tilstrekkelig for formålet.

Boris Beizer, Software Test Techniques, 1990

Testdesign er prosessen der vi velger ut testene som vi mener vil være mest verdifulle for oss og interessentene våre, fra det enorme utvalget av tilgjengelige alternativer. Testmodeller hjelper oss med å velge tester på en systematisk måte og er grunnleggende for testing.

Slik bruker testere modeller:

1. Vi identifiserer og utforsker kunnskapskilder for å bygge testmodeller.
2. Vi bruker disse modellene til å utfordre og validere kildene våre, slik at både kildene og modellene forbedres.
3. Vi bruker disse modellene som grunnlag for både testing og utvikling.

Med et testoppdrag som utgangspunkt er vår første oppgave å identifisere kunnskapskilder. Disse kan være:

• Dokumentasjon: spesifikasjoner, design, krav, standarder, retningslinjer og så videre.
• Mennesker: interessenter, brukere, analytikere, designere, utviklere og andre.
• Erfaring: din egen kunnskap og erfaring med lignende (eller ulike) systemer, dine preferanser, fordommer, gjetninger, anelser, oppfatninger og forutinntatthet.
• Nytt system: systemet som testes, dersom det finnes, er tilgjengelig og kan nås.
• Gammelt system: systemet som skal erstattes, er åpenbart en kilde – det kan på enkelte funksjonsområder fungere som en fasit for forventet atferd.

Det er viktig å merke seg at alle kunnskapskildene våre er feilbarlige og ufullstendige, og det samme gjelder modellene våre. Testere bruker erfaring, ferdigheter og dømmekraft til å sile gjennom disse kildene, sammenligne dem, se forskjeller og likheter, utfordre dem og komme frem til en konsensus. 

Alle modeller er feil, men noen er nyttige

George Box, økonom.

En testmodell kan være en sjekkliste eller et sett med kriterier. Den kan også være et diagram utledet fra et designdokument eller en analyse av narrativ tekst. Mange testmodeller blir aldri skrevet ned – de kan være mentale modeller som er konstruert spesifikt for å veilede testeren mens vedkommende utforsker systemet som testes.

Formålet med modeller er å forenkle komplekse situasjoner ved å utelate detaljer som ikke er relevante på dette tidspunktet. Vi bruker modeller til å forenkle et problem – for eksempel ved å velge hva som skal testes. Modellen danner grunnlag for hvordan vi tenker, og vi velger tester ved å identifisere forekomster av et eller annet sentralt aspekt ved modellen.

Vi kan velge grener i et flytskjema eller et kontrollflytdiagram, tilstandsoverganger i en tilstandsmodell, grenser i en modell av et inndata- (eller utdata-) domene og scenarier utledet fra brukerhistorier skrevet i det domenespesifikke språket Gherkin.

Men vær oppmerksom: Noen ganger gjør modeller utelatelser som ikke er trygge – modellen kan forenkle en situasjon for mye – og dette må vi ta hensyn til. For å gjøre testmodellene dine mer effektive er det avgjørende å bruke spesialisert teststyringsprogramvare.

Hvis vi ikke har modeller direkte fra kildene våre, må vi finne på dem selv. Når krav for eksempel presenteres som narrativ tekst, må vi bruke kravspråket til å utlede funksjoner og logikken i atferden deres. Dette kan være vanskelig for utviklere og testere, og det er ofte et samarbeidsprosjekt, men vi må holde ut.

Bruke modeller til testing

Vi bruker testmodeller til å:

• Forenkle testens kontekst. Irrelevante eller ubetydelige detaljer ignoreres i modellen.
• Fokuser oppmerksomheten på ett perspektiv ved systemets atferd. Dette kan være kritiske eller risikofylte funksjoner, tekniske aspekter, brukeroperasjoner av interesse eller aspekter ved konstruksjonen eller arkitekturen til systemet.
• Generer et sett med unike tester (innenfor modellens kontekst) som er mangfoldige (med hensyn til modellen).
• Gjør det mulig å estimere, planlegge, overvåke og evaluere testingen med hensyn til hvor fullstendig den er (dekning).

Fra testerens synspunkt hjelper en modell oss med å identifisere aspekter ved systemet som kan være gjenstand for en test.

Modeller og dekning

Dekning er begrepet vi bruker for å beskrive grundigheten eller fullstendigheten av testingen vår med hensyn til testmodellen vår. Et dekningselement er noe vi ønsker å utøve i testene våre.

Ideelt sett bør testmodellen vår identifisere dekningselementer på en objektiv måte. Når vi har planlagt eller utført tester som dekker elementer identifisert av modellen vår, kan vi kvantifisere den oppnådde dekningen og uttrykke denne dekningen som en prosentandel av alle elementene i modellen.

Alle modeller som gjør det mulig å identifisere dekningselementer, kan brukes.

Modeller er ofte grafiske, med eksempler som flytskjemaer, brukstilfeller, sekvensdiagrammer og så videre. Disse og mange andre modeller har elementer (eller former) som er koblet sammen med linjer eller piler. Disse kalles vanligvis rettede grafer. 

Se for deg en grafisk modell som består av former og piler. Minst to dekningsmål kan defineres:

• Dekning av alle former
• Dekning av alle piler
• Og så videre

Dermed kan alle modeller som er rettede grafer, behandles på samme måte.

Uformelle modeller har en tendens til å være sjekklister eller kriterier som brukes til å idémyldre en liste over dekningselementer, utløse ideer til testing, eller til testing i en utforskende testøkt. Disse listene eller kriteriene kan være forhåndsdefinerte, utarbeidet som en del av en testplan eller tatt i bruk i en utforskende testøkt.

Uformelle modeller skiller seg fra formelle modeller ved at utledningen av dekningselementer avhenger av fagpersonens erfaring, intuisjon og fantasi. Dekning ved bruk av disse modellene kan derfor aldri kvantifiseres. Vi kan aldri vite hva fullstendig dekning betyr med hensyn til disse modellene.

Modeller forenkler, så bruk mer enn én

En god modell gir en måte å forstå kompleksitet på, og oppnår dette delvis ved å utelate detaljer som ikke er relevante. Modellen din kan bruke begrepet tilstand, feilmodi eller flyter, kombinasjoner av inndata, domeneverdier og så videre. 

Én modell er aldri nok til å teste et system fullt ut. Alle modeller innebærer kompromisser, så vi trenger flere modeller. Dette konseptet omtales vanligvis som «mangfoldige halve tiltak». Det betyr at vi trenger et mangfold av delvise modeller for å teste et system på riktig måte.

Selv om det vanligvis ikke beskrives med disse begrepene, bruker testfasene i et fossefallsprosjekt modeller fra ulike perspektiver. Enhetstesting, integrasjonstesting av delsystemer, testing på systemnivå og brukertesting har ulike mål; hver av dem bruker en forskjellig modell og et forskjellig perspektiv – det er her mangfoldet kommer fra.

Bruk av modeller til styring

Modeller står sentralt i testing og teststyring. Det er fire viktige aspekter ved dette:

• Interessentinvolvering
• Omfang
• Dekning
• Estimering og fremdriftsovervåking

Interessentinvolvering

Når vi planlegger og avgrenser tester og forklarer fremdrift og betydningen av dekning for interessenter, må vi bruke modeller som er forståelige og meningsfulle med hensyn til interessentenes mål.

Hvis vi planlegger en brukertest, vil vi sannsynligvis ta i bruk arbeidsflyten for forretningsprosessen som vår modell og som en mal for å spore stier som gjør det mulig å teste systemfunksjoner som er viktige for brukeren. Hvis vi tester integrasjonen av tjeneste komponenter på vegne av en teknisk arkitekt, vil vi bruke den arkitektoniske modellen, samarbeidsdiagrammer, grensesnittspesifikasjoner og så videre som grunnlag for testingen. Hvis vi tester funksjoner som er definert av brukere, vil vi bruke brukerhistoriene som var resultatet av tidligere samarbeid om krav.

Hvis interessentene ikke forstår modellene dine, vil de ikke forstå, stole på eller investere i testingen din. De vil kanskje ikke engang stole på deg.

Håndtering av omfang

Den første aktiviteten innen systemtenkning er å definere en systemgrense. I testing vil den første modellen du definerer, hjelpe deg med å avgrense testingen. Diagrammet nedenfor er en skjematisk fremstilling av systemarkitekturen – et «system av systemer» – i en organisasjon.

Hvert system (de konsentriske sirklene) ligger innenfor et applikasjonsområde, for eksempel CRM, regnskap eller nettstedet. Alle systemene og applikasjonsområdene ligger inne i «systemet av systemer». Det er selvfølgelig ingen detaljer i modellen, men det er lett å se hvordan hvert system passer inn i den overordnede arkitekturen.

Vi kunne enkelt definert omfanget av testingen vår til å være ERP-systemene, for eksempel.

I det andre diagrammet nedenfor har vi lagt til flere detaljer i systemarkitekturen og foreslått tre måter vi kan definere omfanget mer spesifikt på.

• Systemene som er skyggelagt i gult, er de såkalte registreringssystemene. Disse systemene kan for eksempel dele en database, og endringer i databaseskjemaet kan påvirke alle disse systemene negativt – og være en del av testomfanget.
• Systemene som er omsluttet av den lilla linjen, kan dele noe felles funksjonalitet eller infrastruktur – kanskje bruker de alle et felles sett med webtjenester, det samme meldingssystemet eller kjører på den samme serveren.
• Den stiplede blå linjen viser en brukerreise som benytter systemene som er koblet sammen av linjen. Kanskje brukerreisen er endret, og fokuset vårt er på konsistensen og nøyaktigheten i dataflyten mellom disse systemene.

En modell bidrar til å definere omfanget av en test og også til å forklare omfanget for interessentene med begreper de forstår, verdsetter og (forhåpentligvis) godkjenner.

Håndtering av dekning

Måling av testdekning kan bidra til å gjøre testingen mer håndterlig. Hvis vi ikke har et begrep om dekning, kan vi kanskje ikke svare på spørsmål som «hva er testet?», «hva er ikke testet?», «er vi ferdige ennå?» og «hvor mange tester gjenstår?». Dette er særlig vanskelig for en testleder.

Dekningen vi planlegger å oppnå, er det naturlige neste steget når omfanget er definert.

Testmodeller og dekningsmålinger kan brukes til å definere kvantitative eller kvalitative mål for testutforming og -gjennomføring. I varierende grad kan vi bruke slike mål til å planlegge og anslå. Vi kan også måle fremdrift og trekke slutninger om grundigheten eller fullstendigheten i testingen vi har planlagt eller gjennomført. Vi må imidlertid være svært forsiktige med alle kvantitative dekningsmål eller prosenter vi bruker.

Et dekningsmål (basert på en formell testmodell) kan beregnes objektivt, men det finnes ingen formel eller lov som sier at X-dekning betyr Y-kvalitet eller Z-tillit. Alle dekningsmål gir bare indirekte, kvalitative og subjektive innsikter i grundigheten eller fullstendigheten i testingen vår. Det finnes ingen meningsfull sammenheng mellom dekning og systemenes kvalitet eller akseptabilitet.

Kvantitative dekningsmål brukes ofte til å definere avslutningskriterier for når testingen er fullført, men disse kriteriene er vilkårlige. Et strengere dekningsmål kan føre til at dobbelt så mange elementer må dekkes. Men dobbelt så mange tester som koster dobbelt så mye, gjør ikke et system dobbelt så godt testet eller dobbelt så pålitelig. En slik tolkning er meningsløs og tåpelig.

Noen ganger kan de formelle modellene som brukes til å definere og bygge et system, pålegges testerne slik at de kan bruke dem til å definere dekningsmål. Andre ganger kan testerne ha lite dokumentasjon å arbeide med og må finne opp sine egne modeller. Valget av testmodell og dekningsmål er til en viss grad vilkårlig og subjektivt. Derfor kan uformelle testmodeller og dekningsmål være like nyttige som etablerte, formelle modeller.

Rask modelløvelse

En rask avsluttende øvelse. I eksemplene nedenfor kan du skissere hvordan du tror modellen kan se ut – bare formen – enten som et bilde/diagram, en tabell eller en liste:

• Brukerne er opptatt av ende-til-ende-reisene i systemet.
• En meldingstjeneste kan være i fire tilstander: avslått, kjørende, starter opp og avsluttes.
• En kalkulator for forsikringspremier har 40 inndataverdier som i kombinasjon påvirker beregningen; det finnes avhengigheter mellom enkelte inndata.
• En prosess for uttak/transformasjon/lasting har sju trinn. Etter uttaket avviser hvert trinn enten poster, sender dem til en suspense-fil eller transformerer og sender poster videre til neste trinn. Det siste trinnet er en lasteprosess som håndterer avvisninger. Test at det er gjort rede for alle uttrukne poster.

Meld deg på nyhetsbrevet til The CTO Club for mer innsikt i testing!