Verden er fuld af software, der fuldt ud overholder alle sine dokumenterede krav, men som stadig ikke formår at skabe værdi for sine brugere.
Da jeg læste softwareteknik – for mange år siden – betød kvalitet overensstemmelse, dvs. overensstemmelse med kravene. Jeg lærte også, at kvalitetssikring betyder alle de foranstaltninger, der træffes for at muliggøre, skabe og verificere kvalitet, og at testning er en central metode til kvalitetssikring.
I dag definerer Wikipedia testning som handlingen at undersøge artefakterne og adfærden hos den software, der testes, gennem validering og verifikation. Testning defineres som en aktivitet, hvilket lader dens formål stå åbent. De definitioner, jeg lærte på ingeniøruddannelsen, er meget kompatible med Wikipedias definition af overensstemmelsestestning: testning, der afgør, om en proces, et produkt eller en tjeneste overholder kravene i en specifikation, teknisk standard, kontrakt eller lovgivning. Mærkeligt nok bruger ingen af disse definitioner overhovedet ordet kvalitet .
Hvad er kvalitet?
I dag undgår jeg fristelsen til at definere kvalitet, bortset fra indirekte gennem fire dimensioner: fordele, funktioner, proces og oplevelse. Lad os tænke på noget, alle kender, for eksempel PayPal. Folk bruger det til at overføre penge online; dette er dets funktion. De fordele, de søger, er brugervenlighed, sikkerhed og lave omkostninger. Brug af PayPal involverer forskellige brugerprocesser, og softwaren guider brugeren gennem dem. De følelser, såsom glæde, frustration eller tilfredsstillelse, som brugeren oplever under brugen af PayPal, udgør oplevelsen. Uanset hvad kvalitet er, kan den næppe være til stede uden alle disse fire dimensioner.
Testning fokuserer normalt på funktionel overensstemmelse, dvs. på at kontrollere, at softwaren gør det, som dens krav angiver, og ikke gør noget andet. Der kan også være ikke-funktionelle krav, såsom svartider, antallet af parallelle transaktioner, der håndteres, og sikkerheden af brugerens data. Standarder og lovgivning, såsom SOC2 eller GDPR, medfører yderligere krav, ligesom PayPals aftaler med kreditkortselskaber gør. Disse kan have meget lidt at gøre med softwarens faktiske funktioner og værdi, men overholdelse af dem er en forudsætning for at deltage i forretningen.
Kvalitet rækker ud over simpel overensstemmelse. Hvis du vil opnå begge dele, kan du se vores kuraterede liste over de bedste platforme til softwaretestning
Den ideelle verden
Dygtige testere anvender både et overensstemmelsesbaseret perspektiv, der fokuserer på at opfylde kravene, og et resultatbaseret perspektiv, der fokuserer på at realisere fordelene. I en ideel verden ville opfyldelse af de dokumenterede krav indebære realisering af brugerens fordele, men verden er sjældent ideel. Selv hvis softwaren var perfekt, er brugerne det ikke. Realiseringen af fordelene afhænger i høj grad af brugerens handlinger, og brugerens handlinger afhænger af, hvordan softwaren kommunikerer med brugeren og guider hende. Disse forhold påvirker igen kvaliteten af hele oplevelsen. Disse egenskaber ved softwaren kan næppe indfanges i krav om overensstemmelse eller formelle testcases. Igen ville alle disse udfordringer i en ideel verden blive løst tidligt nok gennem brugercentreret design – men verden er langt fra ideel, og en tester må fungere som stedfortræder for den virkelige bruger.
Testning af overensstemmelse vs. resultattestning
Testning af overensstemmelse og resultattestning kræver forskellige tankegange. Testning af overensstemmelse er som at sætte fælder op: at læse kravene, forestille sig, hvad der kan gå galt, og designe testbetingelser, hvor softwaren sandsynligvis vil fejle. Resultatbaseret testning minder mere om en nysgerrig undersøgelse: at forstå, hvad brugeren har brug for at opnå, forestille sig alle de ting, hun kunne finde på at gøre, finde ud af, hvordan softwaren bør reagere, og derefter afprøve det.
Overensstemmelse er en forudsætning for kvalitet. I mange brancher er opfyldelse af formelle krav om overensstemmelse endda en forudsætning for at deltage i forretningen. Man kan også mindske risikoen for erstatningsansvar ved at fremlægge dokumentation for, at overensstemmelsen er blevet testet korrekt. Jeg har en tendens til at mene, at testning af overensstemmelse hjælper dig med at reducere risikoen for fiasko, mens resultatbaseret testning hjælper dig med at øge sandsynligheden for succes.
