Testmetode for software: Sådan vurderer du krav og kvalitet

Fra krav til kvalitetsmål: Sæt retning for testen

Ifølge ISO/IEC 25010 er et systems kvalitet graden, hvori det opfylder interessenternes udtalte og underforståede behov og dermed skaber værdi. Testen flytter fokus fra “virker funktionen?” til “løser vi det, brugerne og organisationen faktisk har brug for?”

Udtalte behov er nedskrevne krav: funktioner, regler og grænseflader. Underforståede behov er forventninger, ingen har formuleret – fx at systemet svarer hurtigt nok, kan drives videre efter et jobskifte, og at data ikke havner i de forkerte hænder. Gør hvert behov testbart ved at beskrive en observerbar situation, et forventet resultat og en måde at kontrollere det på.

Man skelner mellem funktionel og strukturel softwarekvalitet. Funktionel kvalitet viser, hvor godt koden overholder et givet design baseret på funktionelle krav eller specifikationer; den vurderes typisk dynamisk, men kan også vurderes med statiske tests som software reviews. Strukturel kvalitet afspejler, om softwaren fungerer efter behov, og hvor robust og vedligeholdbar den er; mange aspekter vurderes statisk gennem analyse af kildekoden.

Kravarbejdet stopper ikke ved en funktionsliste. For hvert væsentligt krav skal teamet kunne svare på tre spørgsmål: Hvilket observerbart resultat skal vi se? Hvordan måler vi det? Hvornår er resultatet godt nok? Svarene er kvalitetsmålene, som testen efterprøver.

Et kvalitetsmål skrives på én linje: Systemet skal [egenskab] under [betingelse], målt som [enhed], og godkendes ved [grænse]. Pladsholderne tvinger kravet ud af formuleringer som “hurtigt” og “stabilt” og frem til et resultat, nogen kan måle.

Den praktiske ramme er ISO/IEC 25010:2023, udgivet af ISO og IEC. Standarden definerer en produktkvalitetsmodel, der gælder for ICT-produkter og softwareprodukter. Modellen kan bruges til at identificere testmål, acceptkriterier og målinger af produktkvalitet (ISO/IEC 25010:2023).

Interessentbehov som funktionalitet, ydeevne, sikkerhed og vedligeholdelsesvenlighed skal omsættes til krav, der kan efterprøves. Beskriv behovet som en observerbar egenskab, og angiv betingelse, måleenhed og acceptniveau. Så kan teamet vælge en test, der viser, om resultatet er godt nok.

For effektivitet kan et kvalitetsmål beskrive, hvor hurtigt systemet skal udføre en funktion, og hvilket gennemløb der forventes under bestemte betingelser. Fastlæg kravene til tid og gennemløb før testen, mål systemet under de samme betingelser, og vurder resultatet mod acceptniveauet (ISO/IEC 25010:2023).

Hvis testen bruger personoplysninger fra produktionen, skal testmiljøet som udgangspunkt have de samme sikkerhedsforanstaltninger, som er vurderet passende i produktionsmiljøet. Dokumentér en konkret risikobaseret vurdering, og fastlæg testens sikkerhedsforanstaltninger ud fra den (Datatilsynet).

Kravmapping er den praktiske kobling: Hvert krav mappes til mindst én konkret test. Testen skal være konkret, gentagelig og koblet til et krav eller en funktion.

Arbejdsgangen tager udgangspunkt i ISO/IEC 25010:2023 og går fra krav til kvalitetsmål og videre til valg af testform og acceptniveau. Fastlæg en måleenhed og en grænse for hvert mål, og sørg for, at hvert krav kan føres tilbage til en egenskab og en testmetode.

ISO/IEC 25010 som fælles sprog for produktkvalitet

ISO/IEC 25010:2023 er en international standard udgivet af ISO og IEC. Den definerer en model for produktkvalitet, der gælder for ICT-produkter og softwareprodukter. Brug modellen til at identificere testmål, fastlægge acceptkriterier og vælge målinger for produktkvalitet (ISO/IEC 25010:2023).

Brug modellens egne betegnelser, når et krav kobles til et kvalitetsmål. Beskriv derefter det observerbare resultat, betingelserne for testen, måleenheden og acceptniveauet. Så kan teamet sammenholde resultatet med kravet uden at blande interessenternes hverdagssprog sammen med standardens termer.

Interessentbehov som funktionalitet, ydeevne, sikkerhed og vedligeholdelsesvenlighed skal beskrives som testbare krav. Angiv, hvad systemet skal gøre, under hvilke betingelser og hvordan resultatet måles.

Kvalitetsmål for disse behov skal derfor placeres under et karakteristikum og et underkarakteristikum, så modellens niveauer ikke blandes sammen. Et krav om ydeevne, sikkerhed eller vedligeholdelsesvenlighed hører under det karakteristikum, der dækker behovet – ikke under funktionel egnethed.

Modellen opdeler produktkvaliteten i karakteristika og underkarakteristika. De vurderes gennem statisk analyse, test, kodegennemgang, verifikation af softwaren og løbende kvalitetsforbedring. Opdelingen er den fælles ramme for, hvilke egenskaber der skal måles i projektet.

Skriv hvert krav med ord, der kan omsættes til en test. Beskriv den ønskede funktion eller egenskab, de relevante betingelser og det resultat, der skal måles. Det gør det tydeligt, hvad testen skal kontrollere, og hvad der skal dokumenteres.

Et krav om funktionalitet kan eksempelvis efterprøves ved at kontrollere, om funktionen findes, giver det forventede resultat og hjælper brugeren med at nå sit mål. Skriv tilsvarende målbare krav for de øvrige behov, projektet skal teste.

Modellens værdi er sproglig og praktisk: Den tvinger deltagerne til at præcisere, hvad “god kvalitet” betyder, før de måler. For et dansk udviklings- eller indkøbsteam undgår det, at kvalitetsvurderingen ender som en diskussion om smag og behag.

ISO/IEC 25010:2023 beskriver en produktkvalitetsmodel, der kan bruges til at formulere krav, testmål, acceptkriterier og målinger.

Funktionel egnethed: Test komplethed, korrekthed og hensigtsmæssighed

Funktionel egnethed måler, hvor godt softwaren leverer funktioner, der opfylder udtalte og underforståede brugerbehov. Det centrale spørgsmål er: Udfører softwaren de rigtige funktioner korrekt? Karakteristikummet opdeles i tre underkarakteristika, som hver kræver sin type test.

Funktionel komplethed handler om at dække al nødvendig funktionalitet. Testen gennemgår kravene og efterprøver, at hver påkrævet funktion findes og kan bruges – og opdager huller, hvor et krav er formuleret, men aldrig implementeret. Et kravdækningsskema, hvor hvert krav kobles til mindst én test, er den enkleste måde at gøre kompletheden synlig.

Funktionel korrekthed handler om, at resultaterne er nøjagtige og som forventet. Testen bruger konkrete input og kendte facit: beregninger, opslag, registreringer, grænseværdier og fejlsituationer. Den bør dække både typisk brug og de tilfælde, hvor et svar let bliver næsten rigtigt.

Funktionel hensigtsmæssighed handler om, at brugeren kan nå sine mål effektivt. Det er ikke nok, at funktionen findes og regner rigtigt – den skal kunne bruges i den sammenhæng, den er tænkt til. Opgavestyret testning med rigtige brugere eller repræsentanter er velegnet: Stil en konkret arbejdsopgave, mål om målet nås uden omveje, og noter, hvor brugeren må lede, gætte eller gentage.

Hvert af de tre underkarakteristika får sit eget kvalitetsmål og sit eget acceptkriterium med måleenhed: komplethed måles ved kravdækning, korrekthed ved kendte facit, hensigtsmæssighed ved målet uden omveje. De fejler på hver sin måde: en manglende funktion, et forkert resultat eller en funktion, der er svær at bruge.

Testmetoden er forskellig for hvert underkarakteristikum. Komplethed efterprøves med kravgennemgang og kravdækning; korrekthed med dynamisk test mod kendte facit; hensigtsmæssighed med opgavestyret test, hvor brugeren forsøger at nå et konkret mål.

Testdrevet udvikling passer til funktionel egnethed: Forventet adfærd beskrives tidligt, og tests bruges til at styre udviklingen. En god test skal være konkret, gentagelig og koblet til et krav eller en funktion. Når ny funktionalitet bygges, skal eksisterende funktioner fortsat virke, så regressionstest og automatiserede tests er vigtige.

I udviklingsprojekter ændrer krav sig ofte. Når kravene ændrer sig, skal teststrukturen følge med; ellers risikerer produktet at blive testet mod en gammel virkelighed.

Brug samme arbejdsgang for andre kvalitetsbehov: formulér et krav, vælg en testform, fastlæg et målbart kvalitetsmål, og skriv acceptniveauet ned. På den måde bliver vurderingen knyttet til observerbare resultater.

Vælg testmetode efter kvalitetskarakteristik

De enkelte karakteristika og underkarakteristika kan vurderes med forskellige verifikationsformer: statisk analyse, test, kodegennemgang, verifikation af softwaren og løbende kvalitetsforbedring. Metoden skal følge egenskaben – ikke omvendt.

Statisk analyse og kodegennemgang er velegnede, når egenskaben sidder i koden eller strukturen: vedligeholdelsesvenlighed, kodestandarder, kompleksitet, teknisk gæld og sikkerhedsmæssige faldgruber. Statisk analyse undersøger kildekoden uden at afvikle programmet og kan finde blandt andet sårbarheder, logiske fejl og afvigelser fra kodestandarder (IN-COM). Kodegennemgang tilfører den menneskelige vurdering: Er løsningen forståelig for den næste udvikler?

Dynamisk test er velegnet, når egenskaben viser sig i opførsel: funktionel korrekthed, samspil mellem komponenter og hvordan systemet klarer sig over tid og under de belastninger, det skal bruges under. Pålidelighed og effektivitet kræver, at man afvikler systemet og observerer opførslen.

Skriv metodevalget ind i en tabel med to kolonner: egenskab og verifikationsform. Vælg statisk analyse, kodegennemgang eller dynamisk test efter, hvad kravet kan vise i praksis. Ved måling af tid og gennemløb skal systemet afvikles under de betingelser, kravet beskriver.

For funktionel egnethed vælges kravgennemgang, kravdækning, dynamisk test mod kendte facit og opgavestyret test. For pålidelighed vælges afvikling under driftsbetingelser, belastnings- og regressionstest samt måling af fejlfrekvens pr. bruger eller enhed.

For effektivitet vælges belastnings- og stresstest samt Application performance monitoring (APM). For sikkerhed vælges statisk analyse, kodegennemgang og scanning for kendte sårbarheder, suppleret med måling af tid fra fund til patch og andel brugere med installeret patch.

For vedligeholdelsesvenlighed vælges kodestandarder, kompleksitet, teknisk gæld og kodegennemgang. For sikkerhed måles også antal brud, hvor alvorlige de er, og hvor længe angrebet varede.

Værktøjskassen i metoden omfatter kravdækningsskema, statisk analyse, kodegennemgang, dynamisk test, belastnings- og stresstest, regressionstest, testdrevet udvikling og Application performance monitoring (APM). Sentia nævner Splunk, Dynatrace, Nexthink og Ymonitor Platform blandt de softwareværktøjer, de arbejder med, samt SCOM som et eksisterende værktøj (Sentia).

Sikkerhed og vedligeholdelsesvenlighed fremhæves som kritiske områder – blandt andet fordi store mængder genereret kode hurtigt kan gøre dem svære at holde styr på. Begge egenskaber vurderes bedst med en kombination: analyse og gennemgang af koden suppleret med målrettet test af adgangsstyring, fejlhåndtering og ændringer i kodebasen.

Datatilsynet vejleder om brug af personoplysninger som testdata ved udvikling og test af it-systemer. Oplysningerne er fortsat personoplysninger, selv om de bruges til test, og behandlingen kræver passende tekniske og organisatoriske sikkerhedsforanstaltninger, der afspejler risikoen for de registrerede (Datatilsynet).

Sikkerhedstest har fokus på uønsket eller utilsigtet funktionalitet, mens brugertest, user acceptance test og integrationstest har fokus på forventet funktionalitet. Test er både en forebyggende og en opdagende foranstaltning: den kan finde fejl/sårbarheder, før løsningen tages i brug, og i systemer, der allerede er i drift, herunder styresystemer, tredjepartssoftware og systemkonfigurationer.

IT-Branchens etiske kodeks for sikkerhedstest har seks principper: Vær enige om mål og midler; test organisationen, ikke medarbejderen; indhold og brug af case-materiale; giv dig til kende i tilfælde af konflikter; videregiv viden om kriminelle handlinger; sørg for ansvarlig datahåndtering.

Løbende kvalitetsforbedring binder det hele sammen: Resultater fra statisk analyse, kodegennemgang og dynamisk test føres tilbage til kravene og til næste iteration. Målinger skal bruges til at ændre måden, man arbejder på.

Måling, dokumentation og opfølgning: Gør kvalitet verificerbar

ISO/IEC 25010 kan bruges gennem hele livscyklussen: planlægning, udvikling, test, idriftsættelse og vedligeholdelse. Kvalitetsvurdering er ikke en afsluttende kontrol; den starter ved kravformulering og fortsætter, så længe systemet er i drift.

Datatilsynet understreger, at brug af personoplysninger til test stadig er behandling af personoplysninger. Testdata har ikke et lavere beskyttelseshensyn, blot fordi oplysningerne bruges i et testmiljø (Datatilsynet).

Når personoplysninger bruges til test og udvikling, skal der være passende tekniske og organisatoriske sikkerhedsforanstaltninger, som afspejler risikoen for de registrerede. Hvis der bruges produktionsdata, skal testmiljøet som udgangspunkt have de samme sikkerhedsforanstaltninger, som er vurderet passende i produktionsmiljøet, efter en dokumenteret risikovurdering (Datatilsynet).

Dokumentationen skal lade en udenforstående se, hvordan et kvalitetsmål er nået – eller ikke nået. For hvert krav bør det fremgå, hvilket karakteristikum og underkarakteristikum der er tale om, hvilken verifikationsform der er brugt, hvad resultatet var, og hvad der blev besluttet.

Sporbarheden kan sættes op som én linje pr. krav med fem felter: krav, karakteristikum, underkarakteristikum, verifikationsform og resultat. Felterne er de samme, uanset om verifikationsformen er statisk analyse, kodegennemgang eller dynamisk test. Et spor fra krav til test til resultat er mere værdifuldt end en lang rapport uden kobling til kravene.

Skriv acceptkriterier med måleenhed og grænse. For effektivitet skal kravet angive de betingelser, hvor tid, gennemløb og ressourceforbrug måles; mål derefter systemet under de fastlagte betingelser og sammenhold resultatet med acceptniveauet (ISO/IEC 25010:2023).

For sikkerhed er måleenheder antal kendte sårbarheder, tid fra fund til patch, andel brugere med installeret patch samt antal brud, alvor og varighed. For vedligeholdelsesvenlighed er måleenheder kodestandarder, kompleksitet og teknisk gæld.

ISO/IEC 25010:2023 definerer en produktkvalitetsmodel for ICT-produkter og softwareprodukter. Datatilsynets vejledning hedder »Testdata - anvendelse af personoplysninger ved udvikling og test af it-systemer« og beskriver sikkerhedsforanstaltninger ved brug af personoplysninger til test (ISO/IEC 25010:2023; Datatilsynet).

IT-Branchen har sammen med en lang række organisationer og myndigheder udarbejdet et fælles etisk kodeks for sikkerhedstest. Kodekset er ikke en certificerings- eller mærkningsordning, men kan bruges af leverandører og kunder i dialogen om god praksis.

Linjerne viser med det samme, om et karakteristikum helt står uden test, eller om et krav kun er dækket af en fornemmelse af, at koden ser fin ud.

Opfølgningen har to retninger. Den ene er tilbage til kravene: Er kvalitetsmålene stadig dækkende, eller har driften vist behov, som ingen havde formuleret? Den anden er fremad mod næste version: Hvilke svagheder skal udbedres, og hvilke mål skal skærpes?

Når krav ændrer sig, skal testplaner, acceptkriterier og dokumentation vedligeholdes som en levende del af projektet. Ellers risikerer kvalitetsvurderingen at måle mod en gammel virkelighed, og nye behov ligger uden for testen i stedet for at blive vurderet mod ISO/IEC 25010.

Kvalitetsarbejdet bør have en fast kadence frem for at køre i bølger omkring et projekts afslutning. Når kravene er konkrete, kan store mængder ny eller genereret kode vurderes mod aftalte egenskaber i stedet for mod en fornemmelse af, at koden “ser fin ud”.

Brug ISO/IEC 25010:2023 som reference, når projektet formulerer mål og målinger for produktkvalitet. Brug Datatilsynets vejledning om testdata, når personoplysninger indgår i udvikling eller test, og dokumentér de sikkerhedsforanstaltninger, som den konkrete risikovurdering fører til.

Tjekliste: Sådan vurderer du krav og kvalitet i praksis

Brug tjeklisten som praktisk støtte til arbejdet med ISO/IEC 25010:2023.

Aftal, at ISO/IEC 25010:2023 er referencen for produktkvalitet, og skriv standarden ind i projektmaterialet. Brug Datatilsynets vejledning om testdata, hvis personoplysninger indgår i udvikling eller test.

Brug modellens egne betegnelser, når krav kobles til kvalitetsmål. Beskriv også testbetingelser, måleenhed og acceptniveau, så resultatet kan vurderes mod kravet.

• Gennemgå alle krav – både udtalte og underforståede behov hos brugere, drift og forretning.

• Omsæt hvert væsentligt krav til et målbart kvalitetsmål med efterspurgt resultat og acceptniveau.

• Skriv kvalitetsmålet med fire felter: egenskab, betingelse, måleenhed og acceptniveau.

• Placér hvert krav under det karakteristikum og underkarakteristikum, det primært vedrører, så ingen egenskaber falder mellem to stole.

Beskriv behov som ydeevne, sikkerhed og vedligeholdelsesvenlighed i konkrete, testbare krav. Angiv, hvad der skal observeres, og hvordan resultatet måles.

Skriv testmål for funktionalitet som konkrete kontroller af, om funktionen findes, giver det forventede resultat og hjælper brugeren med at nå sit mål. Beskriv tilsvarende testmål for projektets øvrige kvalitetsbehov.

• Vælg verifikationsform ud fra egenskaben: statisk analyse og kodegennemgang til kode- og strukturmæssige egenskaber, dynamisk test til opførsel i drift.

• Vælg værktøj blandt de navngivne: kravdækningsskema, statisk analyse, kodegennemgang, dynamisk test, belastnings- og stresstest, regressionstest, testdrevet udvikling og Application performance monitoring (APM).

• Kobl verifikationsform til egenskab: kravgennemgang og kravdækning til komplethed; dynamisk test mod kendte facit til korrekthed; opgavestyret test til hensigtsmæssighed.

• Skriv et selvstændigt mål for hvert af de tre underkarakteristika: komplethed, korrekthed og hensigtsmæssighed, og inddrag rigtige brugere eller deres repræsentanter i den opgavestyrede test.

• Dokumentér sporbarhed fra krav til test til resultat og beslutning med felterne krav, karakteristikum, underkarakteristikum, verifikationsform og resultat.

• Før resultater fra analyse, gennemgang og test tilbage til kravene som løbende kvalitetsforbedring i hele livscyklussen: planlægning, udvikling, test, idriftsættelse og vedligeholdelse.

• Tag stilling til kvalitetsmålene igen, når driften har vist, hvordan systemet faktisk bruges.

• Afklar om testen også skal dække uønsket eller utilsigtet funktionalitet, ikke kun den tiltænkte funktionalitet. Test egne applikationer, styresystemer, tredjepartssoftware og systemkonfigurationer – også systemer, der allerede er i brug.

Hvis personoplysninger bruges til test og udvikling, skal de passende tekniske og organisatoriske sikkerhedsforanstaltninger afspejle risikoen for de registrerede. Bruges produktionsdata, skal testmiljøet som udgangspunkt have de samme foranstaltninger, som er vurderet passende i produktionsmiljøet, og vurderingen skal være risikobaseret og dokumenteret (Datatilsynet).

• Følg IT-Branchens etiske kodeks for sikkerhedstest: enighed om mål og midler; test organisationen, ikke medarbejderen; aftal indhold og brug af case-materiale; giv dig til kende ved konflikter; videregiv viden om kriminelle handlinger; sørg for ansvarlig datahåndtering.

• Map krav til konkrete tests i en testplan, og dæk deltest, integrationstest og end-to-end-test. Brug testdrevet udvikling, og kør regressionstest og automatiserede tests, når ny funktionalitet bygges.

• Vedligehold testplaner, acceptkriterier og dokumentation som levende dele, når krav ændrer sig.

• Skeln mellem test i udvikling, hvor test skal skabe læring og validere krav, og test i produktion, hvor test skal sikre gentagelighed, sporbarhed og ensartet kvalitet fra batch til batch.

• Mål pålidelighed gennem produktionshændelser, belastnings- og regressionstest samt fejlfrekvens pr. bruger eller enhed; effektivitet med belastnings- og stresstest og Application performance monitoring (APM).

• Mål sikkerhed gennem antal kendte sårbarheder, tid fra fund til patch, andel brugere med installeret patch samt antal brud, alvor og varighed.

• Mål vedligeholdelsesvenlighed gennem kodestandarder, kompleksitet og teknisk gæld.

Skriv acceptkriteriet med egenskab, betingelse, måleenhed og acceptniveau. Når personoplysninger bruges til test, skal de tekniske og organisatoriske sikkerhedsforanstaltninger afspejle risikoen for de registrerede (Datatilsynet).