Sådan gennemfører du en struktureret behovsafdækning før softwaretest

Hvorfor behovsafdækning er afgørende, før du tester

Softwaretest undersøger, hvordan applikationen fungerer, om den har fejl, og om den gør det, den skal. Løsningen prøvekøres og justeres undervejs, inden den sendes til brugerne. Teknologisk Institut kalder det en uundgåelig del af udvikling og kvalitetssikring at teste og sammenligne resultater med forventninger. Resultaterne kommer fra koden; forventningerne kommer fra behovsafdækningen. Uden afdækkede forventninger tester man kun, om systemet gør det, nogen har skrevet, det skal – ikke om det er det rigtige.

Teknologisk Institut angiver seks grunde til at teste: højere produktkvalitet, sparet tid og penge, forbedret sikkerhed, bedre kundetilfredshed, undgået risiko og en styrket udviklingsproces. To af dem hænger direkte sammen med afdækningen før test. Løbende test i udviklingen gør det lettere at afgøre, hvor og hvornår fejlen ligger, og kan spare betydelige mængder tid og penge, fordi små fejl ikke vokser sig store. Når man tester med brugerens og kundens øjne, opdages fejl og problemer, før de når organisationen – forudsat at nogen har formuleret, hvad brugeren faktisk har brug for.

Rækkefølgen er afgørende for, hvad det koster at rette op. Behovsafdækningen sætter forventningerne og er derfor også stedet, hvor man kan opdage, at et ønske er et vurderet behov frem for et reelt behov – altså før ønsket er blevet til kode, krav og testcases, der ellers alle skal laves om.

6 grunde til at teste software – ifølge Teknologisk Institut

Afgræns formål, brugere og risiko i behovsafdækningen

Sygehus Sønderjyllands innovationsservice stiller tre essentielle spørgsmål i behovsafdækningen: Hvad er modtagerens behov? Hvordan vil du dække behovet? Vil modtageren acceptere og anvende løsningen? De tre spørgsmål giver samtidig en grov ramme for testen: det første peger på funktionelle krav, det andet på løsningens afgrænsning, det tredje på accepttesten, der skal bekræfte, at løsningen tages i brug.

Skeln først mellem et reelt og et vurderet behov. Samme kilde peger på en stor forskel i værdiskabelse, alt efter om man afdækker grundigt ind til det eksakte behov, eller om man formulerer et vurderet behov ud fra et problem. Konsekvensen for test er direkte: er behovet en antagelse, tester man en antagelse – og en grøn testrække beviser da kun, at antagelsen er implementeret konsistent.

Risikovurdér hvert behov, mens det formuleres. TestHuset beskriver, at tilstrækkelig testdækning afhænger af risikoen ved implementeringen af det enkelte krav og af, hvor forretningskritisk kravet er. Hvert behov bør derfor tidligt besvare: Hvem rammes? Hvor kritisk er det for driften? Hvad er konsekvensen, hvis det fejler? Det fastlægger senere, hvor grundigt området skal testes, og hvor mange ressourcer det er forsvarligt at bruge.

Reelt behov vs. vurderet behov – konsekvenser for test

Åbn samtalen bredt og indsnævr behovet med metoder og spørgsmål

Brug behovsafdækningen som en tragt: start bredt, og indsnævr dialogen trin for trin. Kjellerup Kommunikation beskriver, at indledende spørgsmål skal være åbne – altså ikke kunne besvares med ja eller nej – fordi de får modparten til at fortælle mere. I kaffebutikseksemplet begynder man med "Hvad kan jeg hjælpe dig med?", fortsætter med "Hvilken kaffe er du til?" og er dermed kommet længere ned i tragten, tættere på det konkrete behov. Opfølgende spørgsmål snævrer altså ind, mens spørgsmålet stadig holdes åbent.

Sygehus Sønderjyllands innovationsservice peger på, at behovsafdækning kan antage flere former: et eller flere interviews, en tegnet fremstilling, en lyd- eller videooptagelse, en fortælling og meget mere. Vælg form efter, hvad der får brugeren til at beskrive sin faktiske situation frem for sin foretrukne løsning. En tegning eller en optagelse af arbejdsgangen viser ofte detaljer, som et interview alene ikke får frem.

Brug indledende hv-spørgsmål til at præcisere behovet, så tragten ender med, at beskrivelsen af det helt konkrete behov kan besvares med ja eller nej. Den formulering kan senere blive et acceptkriterium. Vær samtidig opmærksom på, at brugeren ofte beskriver en ønsket løsning frem for det underliggende behov; det er den vurderede formulering, den grundige afdækning skal forbi.

Omsæt behov til krav og testbare acceptkriterier

ISTQB definerer testteknikker som en procedure til at udlede og/eller udvælge testcases. TestHuset beskriver dem som værktøjer til struktureret at nedbryde krav til testcases og dermed sikre tilstrækkelig dækning af kravene. Det forudsætter, at kravene allerede er nedbrudt, så hvert krav kan dækkes af konkrete testcases, og at det fremgår, hvilke krav der hører til hvilket behov.

Skriv krav, så de kan afgøres entydigt. Et acceptkriterium, der ikke kan besvares med et klart ja eller nej – eller med en konkret observerbar tilstand – kan heller ikke bestå eller fejle i en test. Den præcision, man jagtede gennem tragten i behovsafdækningen, er den samme, testcasen skal bygges på.

Prioritér dækningen efter de behov og risici, afdækningen har identificeret – ikke efter hvor nemt noget er at teste. Dækningsgrad er derfor ikke en fast procentsats for hele systemet, men et niveau, der fastlægges pr. krav.

Vælg testteknikker, der matcher de afdækkede behov

Testteknikker inddeles overordnet i tre kategorier. Blackbox-teknikker omfatter eksempelvis ækvivalenspartitionering og grænseværdianalyse; whitebox-teknikker omfatter eksempelvis beslutningstest; erfaringsbaserede teknikker omfatter eksempelvis tjeklistebaseret test. Kategorierne finder forskellige fejl, og jo flere teknikker man bruger på et givent område af softwaren, desto større er sandsynligheden ifølge TestHuset for at finde flest mulige afvigelser.

Bevidste teknikvalg har konkrete fordele: de synliggør systemets kvalitet og giver dermed bedre beslutningsgrundlag. De tydeliggør, hvor meget det giver mening at teste et givent område. De sikrer, at systemet testes på flere måder end kun happy path, og at de samme funktioner ikke testes dobbelt. Resultatet er større sandsynlighed for at finde de vigtigste og mest kritiske afvigelser og langt mere målrettede tests.

Vælg teknik efter kravets karakter. I TestHusets eksempel med feber (ja/nej), aldersgruppe (barn/ung/voksen) og vejrtrækningsproblemer (ja/nej) giver alle mulige kombinationer 48. Ækvivalenspartitionering skærer sådanne inputrum ned til et antal testcases, der dækker hver klasse, i stedet for at teste enhver tænkelig kombination. Grænseværdianalyse bruges tilsvarende omkring værdier, hvor et input skifter adfærd, mens beslutningstest og tjeklistebaseret test dækker henholdsvis regelstruktur og erfaringstunge risikoområder.

Afdæk sikkerhedsbehov og uønsket funktionalitet tidligt

Behovsafdækning handler ikke kun om den funktionalitet, kunden ønsker. I kataloget over behandlingssikkerhed peger Datatilsynet på, at et produkt også kan indeholde uønsket eller utilsigtet funktionalitet, som både kunde og leverandør har mindre fokus på under udviklingen. Den uønskede funktionalitet er samtidig unødig og bruges derfor generelt ikke. Netop fordi den typiske bruger ikke anvender den, kan skjulte sikkerhedsproblemer eksistere i årevis, mens personer med onde hensigter målrettet kan søge efter unødig eller uønsket funktionalitet for at misbruge den.

To forhold øger sandsynligheden for fejl og sårbarheder: stadig mere komplekse it-systemer og integrationer mellem systemer, og at meget software bygges af færdige komponenter fra et developer tool eller fra tredjeparter, hvis fokus på sikkerhedsmæssige krav man ikke kender. Begge dele bør derfor indgå i afdækningen som risikoområder med egne krav og egne tests – ikke undersøges først efter ibrugtagning.

Test er både en forebyggende foranstaltning, der mindsker sandsynligheden for fejl, fordi fejl og sårbarheder undgås eller findes inden ibrugtagning, og en opdagende foranstaltning rettet mod systemer, der allerede er i drift – egne applikationer såvel som styresystemer, tredjepartssoftware og systemkonfigurationer – forudsat at fejl opdages og rettes hurtigt og dermed inden ondsindet udnyttelse. Formulér derfor sikkerhedsbehovene, før testen starter: hvad softwaren ikke må kunne bringes til at gøre, og hvilke uventede måder at anvende den på der skal forsøges. Vær opmærksom på, at brugertest, user acceptance test og integrationstest har fokus på softwares forventede funktionalitet, mens sikkerhedstestning har fokus på den uønskede. En accepttest alene dækker altså ikke sikkerhedsbehovene.

Validér behovene med brugerne, og dokumentér beslutningerne

Luk afdækningen ved at vende tilbage til det tredje centrale spørgsmål: Vil modtageren acceptere og anvende løsningen? Det er ikke det samme som at få bekræftet, at kravene er implementeret. Acceptere og anvende er to observationer, man kan teste: Får brugeren opgaven løst med løsningen i sin egen arbejdsgang, og tages den i brug efter overgangen?

Sørg for et spor fra behov til test. Det bør fremgå, hvilke behov der er afdækket og hvordan, hvilke krav de er omsat til, hvilke risici og hvilken forretningskritikalitet der er vurderet pr. krav, og hvilke testteknikker der er valgt. Uden sporet kan man hverken opgøre dækningen eller forklare, hvorfor et område er testet på et givent niveau.

Brug sporet aktivt. Knyt hvert testcase til det krav og det behov, det dækker, så det løbende kan opgøres, hvad der er testet, hvor meget, og hvor risikoen gør det relevant at teste mere. Den registrering gør, at testen kan målrettes de behov, afdækningen har peget på som de vigtigste, og at usikkerhed om den resterende dækning bliver et bevidst valg frem for et ukendt hul.