Hvilke typer test kan bruges ved evaluering af forretningssoftware?

Test eller evalueringsmetode – og hvorfor forskellen betyder noget for valget

Et bredt udvalg af redskaber og evalueringsmetoder i folkeskolen skal bidrage til en stærk evalueringskultur. Overført til indkøb af forretningssoftware betyder det, at hver test kun besvarer ét spørgsmål. Beslutningsgrundlaget kommer fra summen af flere metoder.

Ved evaluering af forretningssoftware findes der etablerede testtyper: funktionel test, ikke-funktionel test, brugeraccepttest (UAT), regressionstest, belastningstest/load- og stresstest, integrationstest, sikkerhedstest/penetrationstest og anvendelighedstest (usability). Hver testtype besvarer sit spørgsmål, og flere kan kombineres i samme evalueringsforløb.

Til den praktiske gennemførelse findes konkrete værktøjer som Selenium, JMeter, TestRail og Postman.

Skriv derfor beslutningen ned, før testtypen vælges: Skal vi kunne sige nej tak til leverandøren? Kan løsningen håndtere vores sagsvolumen? Spares der tid i den daglige opgave? Hvert spørgsmål kræver sin metode.

Evalueringsbanken på emu.dk samler tests og andre evalueringsmetoder side om side. Den nævner blandt andet trivselsmålinger, Folkeskolens Nationale Færdighedstest og risikotest. Metoderne erstatter ikke hinanden; de står ved siden af hinanden, fordi de måler forskellige ting.

Lav samme liste over jeres kandidater: kort spørgeskema til brugerne, måling af svartider, faglig vurdering af systemets output, observation af arbejdsgange og opfølgende målinger efter ibrugtagning. Vælg metode efter det spørgsmål, der står øverst.

Et spørgeskema kan ikke svare på, hvor hurtigt systemet er. En hastighedsmåling kan ikke svare på, om brugeren finder de rigtige data. Vælges testtypen ud fra, hvad der er nemmest at sætte i gang, risikerer man et grundigt svar på et spørgsmål, ingen beslutning afhænger af.

Sammenligning af testtyper ved evaluering af forretningssoftware

Spørgeskemabaserede tests: få spørgsmål, hurtig indikation

Risikotesten på diabetes.dk består af syv simple spørgsmål, hvorefter brugeren får klarlagt sin risiko for at have eller udvikle type 2-diabetes. Testen nævner symptomer som træthed, tørst, kløe, uforklarligt vægttab og synsforstyrrelser, og over 1,2 mio. har taget den. Det er modellen for en spørgeskemabaseret test: få spørgsmål, kort svartid og et resultat, der peger videre, frem for et endeligt facit.

Brugeraccepttest (UAT) og anvendelighedstest (usability) er de etablerede navne for at afprøve, om brugerne kan løse opgaverne i systemet. Et kort spørgeskema kan indgå som forberedelse eller opfølgning på en UAT.

Brug den som prototype på den lette screening, der lægges før de tunge testformer. Stil 5-10 spørgsmål til et repræsentativt udsnit af brugerne – ikke alle. Spørg om hvilke opgaver der tager længst tid, og hvor ofte de forlader systemet for at hente data et andet sted.

Spørg også hvilke data de mangler fra andre systemer, og hvor ofte opgaven må gøres om. Resultatet er en prioriteret liste over områder, der skal undersøges nærmere. Listen bestemmer, hvilke dyrere testtyper der overhovedet skal sættes i gang.

To forbehold styrer kvaliteten. Svaret er en indikation, ikke et bevis for, at løsningen kan løse opgaven – det skal de efterfølgende testformer vise. Spørgsmålene skal samtidig formuleres, så svarene kan efterprøves: konkrete opgavetyper, angivelse af hvor ofte og hvor lang tid, i stedet for tilfredshedsskalaer.

Med et lille, rolleopdelt udvalg af besvarere kan et kort spørgeskema gentages flere gange i et forløb uden at blive en belastning.

Evalueringsforløb for forretningssoftware – trin for trin

Ydelses- og hastighedstests: måling af tekniske egenskaber

Speedtest by Ookla er et bredbåndshastighedstest. Målingen indledes med, at værktøjet finder en optimal server at måle imod. Det illustrerer princippet i enhver ydelsesmåling: Resultatet er bundet til det endpoint og den forbindelse, der måles over. En måling uden angivelse af målepunkt er ikke sammenlignelig med en anden.

Belastningstest, load-test og stresstest er ikke-funktionelle tests. De måler, hvordan forretningssoftware opfører sig under samtidig belastning, og supplerer funktionelle test. JMeter er et eksempel på et værktøj til belastningstest.

Samme logik gælder ved måling af en forretningsapplikations ydeevne. Fastlæg og dokumentér derfor måleopsætningen, før der måles: hvilket endpoint eller hvilken transaktion der måles på, hvor stort et datagrundlag der arbejdes med, hvilken miljøtype der måles i, hvor mange samtidige brugere der belaster, og på hvilket tidspunkt.

To målinger med forskellig opsætning kan ikke sættes op mod hinanden. En måling i et tomt testmiljø siger ikke noget om adfærden i den daglige drift.

Mål flere egenskaber ved samme opsætning: svartid fra brugerens handling til svaret vises, gennemstrømning over en periode, stabilitet gennem en hel arbejdsdag eller uge, og hvordan løsningen opfører sig, når belastningen vokser. Mål ved brugerens grænseflade frem for i databaseloggen, da det er den oplevede ventetid, der afgør, om arbejdsgangen holder. Gentages præcis samme måling efter en opdatering eller et øget datavolumen, bliver resultatet samtidig et sammenligningsgrundlag over tid.

Test af systemer der understøtter faglige vurderinger

Styrelsen for Patientsikkerhed beskriver digital faglig beslutningsstøtte som blandt andet kunstig intelligens, der understøtter en sundhedsperson i vurderingen af scanningsbilleder eller andre patientdata. Styrelsen fastslår, at digital teknologi ikke ændrer kravet om, at behandlingen skal være fagligt forsvarlig og tilrettelægges med hensyn til patientsikkerheden.

Funktionel test og regressionstest er nødvendige, når beslutningsstøtten skal ændres eller opdateres. Regressionstest gentages, så en ændring ikke ødelægger tidligere godkendte svar.

Overført til forretningssoftware betyder det, at systemets output er et forslag, som en fagperson skal kunne bedømme. Testen skal vise både, om forslaget er rigtigt, og om fagpersonen kan tilsidesætte det.

EU-Kommissionens beskrivelse af AI i sundhedssektoren peger på, hvad der kan måles i den type systemer. AI i diagnostik forbedrer nøjagtigheden og muliggør tidligere påvisning. AI-systemer på intensivafdelinger kan forudsige udbrud af sepsis flere timer før de kliniske symptomer viser sig, og AI til mammografiscreening kan identificere tidlige tegn på brystkræft med bemærkelsesværdig nøjagtighed.

Heraf følger tre testkriterier, der også gælder automatisk sagsgruppering, afvigelsesflag eller prioriteringsforslag i en forretningsapplikation: tidlighed, træfsikkerhed og efterprøvbarhed.

Metoden er at holde systemets output op mod en fagpersons egen vurdering på de samme sager. Gennemfør sammenligningen på et sagsmateriale, hvor fagpersonen vurderer først, og systemets svar først sammenlignes bagefter, så vurderingen ikke farves af systemets forslag.

Opgør både, hvor ofte svarene er sammenfaldende, og hvordan uenigheden fordeler sig – særligt om systemet overser sjældne, men alvorlige sager, og om det flagger for meget og skaber unødigt efterarbejde. Et gennemsnitligt træfprocenttal fortæller ikke, om en fagperson kan handle på svaret i den konkrete situation.

Kritiske målepunkter i evaluering af digital faglig beslutningsstøtte

Evaluering af om løsningen understøtter arbejdsgangen og dataadgangen

Sundhedsdatastyrelsens afsluttende status for Strategi for digital sundhed 2018-2024 fremhæver, at der i strategiperioden blev implementeret systemer, der sikrer sundhedspersonale adgang til opdaterede og relevante data. Sundhedsprofessionelle på tværs af sundhedssektoren fik adgang til borgernes Aftaleoversigt og Fælles Stamkort.

Integrationstest og sikkerhedstest/penetrationstest dækker dataadgang og samspil mellem systemer. Integrationstest viser, om data udveksles korrekt mellem forretningssoftware og tilstødende systemer. Postman kan bruges til at teste integrationer mellem systemer.

Det giver de to spørgsmål, der afgør, om en arbejdsgang er understøttet: Møder brugeren de rigtige og opdaterede data i den situation, hvor opgaven skal løses? Og slipper brugeren for selv at samle oplysningerne på tværs af systemer?

Samme status nævner, at der blev etableret visning af logoplysninger fra hospitalernes kliniske it-systemer, blandt andet på sundhed.dk. Datasikkerhed og beskyttelse af personlige oplysninger blev vægtet for at øge tilliden til de digitale løsninger.

Dermed bliver sporing et selvstændigt testpunkt: Kan man bagefter se, hvem der har tilgået hvad og hvornår, og kan oplysningen vises for den, det angår? Det kan en funktionsliste ikke svare på, men det kan en test på et rigtigt sagsforløb.

Gennemfør derfor testen som en følgestudie af et mindre antal virkelige sager fra start til slut, og notér hver gang, brugeren forlader systemet, indtaster de samme oplysninger igen eller må spørge en kollega. Tjek samtidig, om den samme sag fremstår identisk, når den ses fra to systemer eller to roller – det er præcis den kontrol, Aftaleoversigt og Fælles Stamkort er udtryk for på sundhedsområdet.

Om et system understøtter en faglig beslutning, kan også testes ved, om støtten dukker op i selve arbejdsøjeblikket: Fælles MedicinBeslutningsstøtte er et eksempel på en komponent, der er implementeret ind i eksisterende medicinsystemer og lægepraksissystemer. Spørgsmålet er derfor, om støtten vises, hvor beslutningen træffes, frem for i et separat system.

Testen slutter ikke ved idriftsættelsen

Sundhedsdatastyrelsen har efter strategiperiodens afslutning udarbejdet et overblik over indsatserne og offentliggjort en afsluttende status. Det viser, at evalueringen fortsætter, efter at løsningerne er taget i brug, og at resultaterne samles op i et samlet overblik.

Efter idriftsættelse er regressionstest og belastningstest/load- og stresstest de testtyper, der typisk gentages. Regressionstest fanger utilsigtede ændringer, mens belastningstest følger med datavolumen.

Læg derfor lette evalueringer ind på faste tidspunkter efter ibrugtagning, for eksempel kort efter idriftsættelsen og igen efter et kvartals normal drift. Genbrug de samme spørgsmål og målinger, så svarene kan sammenlignes.

Strategien havde som et af sine formål at fremme samarbejde på tværs af sektorer og skabe en ramme, der tillader innovation og tilpasning til nye teknologier. Når grundlaget ændrer sig – ny integration, nyt datavolumen, ny lovgivning eller nye arbejdsgange – holder den oprindelige test ikke længere.

Vælg derfor testtyper, der kan skiftes undervejs: begynd med det korte spørgeskema og observation af arbejdsgange, og skift til målinger af svartid og stabilitet, når belastningen og datamængden tager til.

Gør opfølgningen konkret ved at bruge driften som testmateriale. Saml hændelser og fejl fra den første periode og brug dem som sagsmateriale i den næste evaluering, så testen rammer de problemer, der faktisk opstod.

Gentag derefter den samme ydelsesmåling og det samme korte spørgeskema, så ændringer i svar og svartider kan ses i forhold til den foregående måling. Tilføjes en ny integration, eller vokser datamængden, skal ydelsesmålingen køres igen, fordi det tidligere resultat beskriver en situation, der ikke længere findes.

Oversigt over nødvendige testpunkter efter idriftsættelse

Tidslinje for evaluering af forretningssoftware – fra valg til eftervirkning