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

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

Kvalitet er ikke en mavefornemmelse. Beskrivelsen af ISO/IEC 25010 definerer kvaliteten af et system som graden, hvori systemet opfylder interessenternes udtalte og underforståede behov og dermed skaber værdi. Det flytter fokus fra "virker funktionen?" til "løser vi det, brugerne og organisationen faktisk har brug for?"

Udtalte behov er de nedskrevne krav: funktioner, regler og grænseflader. Underforståede behov er forventninger, ingen har formuleret – at systemet svarer hurtigt nok, kan drives videre efter et jobskifte, og at data ikke havner i de forkerte hænder. Begge typer skal med, hvis testen skal sige noget reelt om kvaliteten.

I praksis betyder det, at kravarbejdet ikke stopper ved en funktionsliste. For hvert væsentligt krav bør 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 – og dem, testen skal efterprøve.

Her kan ISO/IEC 25010 bruges aktivt: Standarden giver et fælles sprog til at opstille målbare kvalitetsmål, styre verifikationen af softwaren og koble teknisk arbejde til forretningsmæssige mål. Kvalitetsmodellen fastlægger, hvilke egenskaber der overhovedet indgår i vurderingen af et softwareprodukt – og dermed også, hvad der ikke bliver testet, hvis man udelader dem.

Kvalitetsmodellen som fælles sprog: Ni karakteristika fra ISO/IEC 25010

ISO/IEC 25010 er en international standard udgivet af ISO og IEC. Den definerer en model for softwareproduktkvalitet med ni kvalitetskarakteristika, og hvert karakteristikum indeholder flere underkarakteristika. Modellen kaldes omdrejningspunktet i et system til evaluering af produktkvalitet, netop fordi den fastlægger, hvilke egenskaber der tages i betragtning, når et softwareprodukts egenskaber vurderes.

Kilderne nævner blandt andet funktionel egnethed og pålidelighed som karakteristika og peger desuden på ydeevne, sikkerhed og vedligeholdelsesvenlighed som eksempler på interessentbehov, som modellen repræsenterer. Den præcise liste over alle ni karakteristika og deres underkarakteristika bør læses direkte i den gældende standard.

Standarden findes i flere udgaver. Dansk Standard fører eksempelvis ISO/IEC 25010:2011, og SonarSource beskriver en 2023-udgave af modellen med ni kvalitetskarakteristika. ISO 25000-kilden nævner ni kvalitetskarakteristika uden at knytte dem til en bestemt udgave, mens kilden fra Dansk Standard for 2011-udgaven kun angiver titlen. Teamet bør derfor beslutte, hvilken udgave der er referencen i projektet – og skrive det ned, så krav, test og leverandørdialog taler om det samme.

Modellens værdi er først og fremmest sproglig og praktisk: Den tvinger deltagerne til at præcisere, hvad "god kvalitet" betyder, før man begynder at måle. For et dansk udviklings- eller indkøbsteam hjælper det med at undgå, at kvalitetsvurderingen ender som en diskussion om smag og behag.

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 enkelt: 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 går kravene igennem 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. Her testes med konkrete input og kendte facit: beregninger, opslag, registreringer, grænseværdier og fejlsituationer. Testen 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. Her er opgavestyret testning med rigtige brugere eller repræsentanter velegnet: Stil en konkret arbejdsopgave, mål om målet nås uden omveje, og noter, hvor brugeren må lede, gætte eller gentage.

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. Pointen er, at metoden skal følge egenskaben – ikke omvendt.

Statisk analyse og kodegennemgang er særligt velegnede, når egenskaben sidder i koden eller strukturen: vedligeholdelsesvenlighed, kodestandarder, kompleksitet, teknisk gæld og sikkerhedsmæssige faldgruber. Analysen ser på kilden uden at afvikle programmet og fanger mønstre, som først ville blive dyre at finde i drift. 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 ydeevne kræver, at man faktisk afvikler systemet og observerer opførslen.

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.

Løbende kvalitetsforbedring binder det hele sammen: Resultater fra analyse, gennemgang og test føres tilbage til kravene og til næste iteration. Et ældre speciale fra Aalborg Universitet undersøgte netop, om en softwareorganisations udviklingsproces kan forbedres med selvforbedrende mekanismer – samme grundtanke: 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 beskrives som anvendelig gennem hele livscyklussen – planlægning, udvikling, test, idriftsættelse og vedligeholdelse. Det er en vigtig pointe: Kvalitetsvurdering er ikke en afsluttende kontrol, men en aktivitet, der starter, når kravene formuleres, og fortsætter, så længe systemet er i drift.

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 på baggrund af det. Et spor fra krav til test til resultat er mere værdifuldt end en lang rapport uden kobling til kravene.

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? I en rapport fra Teknologisk Institut om frontløbervirksomheders IT-anvendelse peges der på, at IT ikke bare løser opgaver, men også kan skabe nye tekniske problemer eller stille krav om ny softwareudvikling og dermed give ekstra arbejdsbelastning i virksomheden. Netop derfor bør kvalitetsarbejdet have en fast kadence frem for at køre i bølger omkring et projekts afslutning.

En særlig gevinst ved at fastholde målbare kvalitetsmål er, at verifikationen ikke bliver flaskehalsen. 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".

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

• Aftal hvilken udgave af ISO/IEC 25010 der er referencen, og skriv det i projektmaterialet. • Gennemgå alle krav – både de udtalte og de underforståede behov hos brugerne, driften og forretningen. • Omsæt hvert væsentligt krav til et målbart kvalitetsmål med efterspurgt resultat og acceptniveau. • Placér hvert krav under det karakteristikum og underkarakteristikum, det primært vedrører, så ingen egenskaber falder mellem to stole. • Vælg verifikationsform ud fra egenskaben: statisk analyse og kodegennemgang til kode- og strukturmæssige egenskaber, dynamisk test til opførsel i drift. • Sikr at funktionel egnethed dækkes på alle tre niveauer: komplethed, korrekthed og hensigtsmæssighed. • Inddrag rigtige brugere eller deres repræsentanter i opgavestyret test af, om målene kan nås effektivt. • Dokumentér sporbarhed fra krav til test til resultat og beslutning. • Før resultaterne tilbage 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.