Hvorfor hvidboks-test er nøglen til bedre fejlfinding

Forestil dig at forsøge at løse et puslespil uden nogensinde at se brikkerne inde i æsken – det er black box-testning i en nøddeskal. Det er en god tilgang til at opdage problemer på overfladeniveau, men hvad nu hvis du vil gå mere i dybden, finde frem til den grundlæggende årsag til fejl og forstå, hvad der sker under overfladen? Din løsning er white box-testning – en metode, der giver indsigt i koden og muliggør mere præcis fejlanalyse og -forebyggelse. 

I denne artikel forklarer jeg, hvordan skiftet fra black box-testning til white box-testning kan give dybere indsigt, hjælpe dig med at opdage problemer ved deres kilde og forbedre den overordnede kodekvalitet.

Forskelle mellem black box- og white box-testning

Begge metoder har til formål at identificere og løse fejl i software, men de adskiller sig markant i deres tilgang og fokus. Black box-testning behandler systemet som en "sort boks", hvor testerne ikke kender de interne funktioner og udelukkende fokuserer på softwarens output baseret på forskellige input.

I modsætning hertil kræver white box-testning, at testerne har fuld indsigt i den interne kodestruktur, så de kan evaluere, hvordan softwaren fungerer indefra.

Black box-testning (funktionel testning)

Black box-testning er en metode til softwaretest, hvor testeren evaluerer funktionaliteten af en applikation uden at kende dens interne kode eller struktur. Du arbejder grundlæggende med systemets "hvad" – du verificerer output uden at forstå de interne funktioner. Testerne fokuserer på input og forventet output for at sikre, at systemet opfører sig som krævet.

Fordele ved black box-testning:

• Brugerfokuseret: Den simulerer scenarier fra den virkelige verden set fra slutbrugerens perspektiv. Testerne validerer, om systemet opfylder brugerkravene og håndterer input korrekt.
• Intet behov for programmeringskendskab: Testerne behøver ikke at kende den interne kode, hvilket gør det muligt for ikke-udviklere eller personer uden dyb programmeringserfaring at udføre tests.
• Kan anvendes på alle niveauer: Black box-testning kan bruges på alle testniveauer (enhedstest, integrationstest, systemtest og accepttest), hvilket gør den alsidig.
• Tidlig identificering af kravproblemer: Fordi den fokuserer på funktionalitet, afslører black box-testning ofte misforståelser eller uoverensstemmelser i de oprindelige krav.

Begrænsninger ved black box-testning:

• Begrænset dækning: Da testeren ikke tager højde for den interne kodestruktur, er der ingen måde at verificere, om alle kodestier er blevet testet, hvilket kan føre til huller i dækningen.
• Svært at finde den grundlæggende årsag: Når der findes en fejl, kan black box-testning kun vise, at der findes et problem, men den kan ikke give indsigt i, hvor i koden problemet befinder sig.
• Redundans: Den kan overse test af bestemte interne strukturer eller betingelser, og testerne kan ubevidst gentage testscenarier.
• Vanskeligheder ved test af kompleks logik: Uden adgang til de interne funktioner bliver det udfordrende at teste kompleks logik eller kanttilfælde.

White box-testning (strukturel testning)

Denne form for testning kaldes også strukturel testning og indebærer test af softwarens interne strukturer, logik og endda kode. Testcasen bør udformes af en tester med programmeringskendskab; derfor vil sådanne cases kontrollere kodestier, beslutningspunkter, løkker og applikationens interne funktion.

Fordele ved white box-testning:

• Fuld dækning: Testere kan sikre, at alle kodeveje, grene, løkker og betingede sætninger er blevet dækket. Dette øger derfor sandsynligheden for at identificere skjulte fejl.
• Tidlig registrering af fejl i koden: Det hjælper med at finde fejl og sikkerhedssårbarheder tidligt i koden, hvilket ikke er muligt ved black-box-test. Ydelsestest: White-box-test kan finde flaskehalse i ydeevnen og optimere koden baseret på den detaljerede indsigt i dens funktion, som testen giver.
• Ydelsestest: White-box-test kan hjælpe med at identificere flaskehalse i ydeevnen og optimere koden baseret på detaljeret indsigt i, hvordan den fungerer.
• Indsigt i den grundlæggende årsag: Da testeren ser koden, er det muligt at identificere præcis, hvilken del af koden der er fejlbehæftet, når der opstår en fejl.

Begrænsninger ved white-box-test:

• Kræver programmeringsviden: Test kræver en forståelse af den interne kode, normalt hos udviklere eller tekniske testere.
• Ikke brugerfokuseret: Det sikrer, at koden er korrekt, men tester ikke, om systemet opfører sig, som brugeren forventer. Fokus er på den interne logik frem for den eksterne funktionalitet.
• Tidskrævende: Det er generelt ressource- og tidskrævende at skrive detaljerede testcases for hver kodevej og betingelse.
• Kan overse problemer med kravene: White-box-test kan muligvis ikke registrere, om systemet opfylder virksomheders eller brugeres krav, fordi den udelukkende fokuserer på den interne kodes funktion.

Scenarier for black-box- eller white-box-test

Vigtige fordele ved white-box-test 

 1. Bedre lokalisering af fejl

• Sporing af kodelinjen: QA-ingeniører kan hurtigt fastslå, hvor fejlen opstår, i en samling kildefiler. De rapporterer ikke blot en fejl på baggrund af det, de ser i brugergrænsefladen, men kan præcist angive, hvilken del (linje og blok) i kildekoden der kan være problematisk. Denne funktion reducerer markant den tid, udviklerne bruger på at undersøge og rette fejl.
• Hurtigere løsningstider: Når udviklerne får at vide præcis, hvor problemet er i deres app, kan QA-medarbejdere give yderligere oplysninger (dvs. forklaringer og sprogspecifikke detaljer) om fejlen. På den måde kan udviklerne løse problemer hurtigere og spare tid på først at finde ud af, hvad der er galt. Dette er afgørende i hurtigtarbejdende udviklingsmiljøer og bidrager til at reducere den samlede tid til markedsføring.

 2. Forbedret kommunikation med udviklere

• Fælles forståelse: Hvis QA-fagfolk forstår koden, har de et fælles sprog, som de kan dele med udviklerne og bruge til at tale mere produktivt om fejl. Denne fælles forståelse giver bedre kommunikation, reducerer risikoen for fejl og sikrer, at problemerne løses hurtigere.
• Proaktivt samarbejde: En QA-medarbejder med kodeindsigt er bedre til at foretage gennemgange, da vedkommende kan udføre mere dybdegående gennemgange end andre QA-medarbejdere og endda samarbejde med udviklerne under gennemgangen for at opdage potentielle fejl så tidligt som muligt. Denne proaktive tilgang skaber en mere samlet udviklingsmetode, hvor kvalitet integreres direkte i softwaren.

 3. Forfinede teststrategier

• Målrettet testning: Det hjælper QA-fagfolk med at forstå koden og fokusere testningen fuldt ud på de vigtigste eller mest komplekse dele af denne applikation. I stedet for at gætte kan QA identificere, hvilke dele der med størst sandsynlighed vil gå i stykker, hvor der er foretaget nye ændringer, eller hvor der findes kompleks logik, og skrive testcases, der finder fejlene hurtigere, hvilket gør testningen langt mere nyttig.

 4. Højere testdækning og større dybde

• Identifikation af skjulte fejl: White-box-testning er fremragende til at finde skjulte fejl såsom logiske fejl, død kode og sikkerhedssårbarheder, som muligvis ikke opdages gennem funktionel testning alene. Denne indsigt fanger selv de mest subtile og komplicerede problemer, der er nødvendige for at forbedre den overordnede softwarekvalitet.
• Omfattende dækning: På denne måde kan den kodekyndige QA-fagperson sikre, at kritiske stier og kanttilfælde på hver sti i softwaren er blevet dækket. Denne komplette dækning er vanskelig kun at opnå gennem black-box-testning, eftersom testere kan overse visse scenarier, fordi de ikke kan se koden.

 5. Forbedret analyse af grundårsager

• Identifikation af fejlens oprindelse: En forståelse af koden hjælper med at lokalisere den præcise grundårsag. En af de mest fremtrædende fordele nu er også, at QA i stedet for  blot at fortælle udviklerne om en fejls symptomer kan fejlfinde problemet helt ned til grundårsagen og dermed levere meningsfulde data, der danner grundlag for bedre rettelser
• Eliminering af fejl ved kilden: QA kan hjælpe med at forhindre lignende problemer i fremtiden ved at forstå, hvorfor fejl opstår. Det giver dig den bedst mulige kode samt bedre kodningsvaner, som igen resulterer i endnu mere stabil software.

6. Karriereudvikling og forbedring af færdigheder

• Udvidelse af QA's rolle: Evnen til at analysere kode giver QA-fagfolk et større ansvar og øger dermed deres værdi som teammedlemmer. De går fra at være grundlæggende testere til fuldgyldige interessenter i udviklingslivscyklussen, hvor de aktivt forbedrer systemets kvalitet og overordnede stabilitet.

• At forblive konkurrencedygtig: Softwarebranchen udvikler sig, og efterspørgslen efter QA-fagfolk, der kan læse kode – og skrive den – vokser. Med disse færdigheder kan QA-fagfolk blive mere attraktive på arbejdsmarkedet og begynde på en ny vej inden for deres karriere — måske ved at skifte til roller inden for teknisk testning eller endda stillinger som udviklere.

Almindelige udfordringer ved white-box-testning

White-box-testning er ganske vist en effektiv tilgang til at sikre høj kodedækning og intern kvalitet, men den har også sine egne udfordringer. Her er nogle af de almindelige udfordringer ved brug af white-box-testning:

1. Høj kompleksitet

• Udfordring: White-box-testning kræver et dybtgående kendskab til en applikations interne processer, herunder kodens struktur, stier og logik. Den ekstra kompleksitet i kodebasen i større applikationer, hvis de indeholder mange moduler eller komplekse algoritmer, overstiger let menneskers evne til fuldt ud at forstå og vedligeholde koden.
• Eksempel: Man kan betragte testning af alle stier i et system, der indeholder dybt indlejrede betingelser og løkker, som en ekstremt tidskrævende og vanskelig testproces at vedligeholde.

2. Kræver dybdegående programmeringsviden

• Udfordring: White-box-testning handler om selve koden og kræver derfor i høj grad ekspertise som programmør samt kendskab til applikationens arkitektur. Testere med en ikke-teknisk baggrund kan have svært ved enten at skrive eller forstå testcases.
• Eksempel: En QA-tester uden erfaring med udvikling vil måske ikke være i stand til at identificere kritiske områder i koden, skrive effektive tests eller endda forstå bestemte dele af koden.

3. Tidskrævende og ressourceintensiv

• Udfordring: At skrive omfattende testcases er faktisk en opgave med kodeveje, forgreninger og betingelser, som normalt kræver lang tid og nogle gange bliver umuligt besværlig, især når man skal håndtere komplekse eller store systemer. Det bliver en ressourcekrævende aktivitet at skrive og vedligeholde test og derefter køre disse test.
• Eksempel: På store systemer med integrationer fra mange forskellige partnere kan det tage uger at skrive en test for hver betinget forgrening. Det kan nemt føre til et stort tidsforbrug på udvikling og test.

4. Vedligeholdelse af testcases under kodeændringer

• Udfordring: Når koden udvikler sig gennem fejlrettelser, tilføjelse af funktioner eller refaktorering, kan eksisterende testcases blive forældede, eller det kan blive nødvendigt at opdatere dem. Hvidboks-test er for tæt koblet til implementeringen, og der er en betydelig sandsynlighed for, at de skal ændres, hver gang der sker ændringer i kodebasen.
• Eksempel: Hver gang noget er blevet refaktoreret, f.eks. en funktion, eller der er sket en ændring i logikken, kan det også være nødvendigt at omskrive eller justere den testcase, der dækker den pågældende del af koden, hvilket øger antallet af vedligeholdelsesopgaver.

5. Begrænset anvendelighed for ikke-kodebaserede elementer

• Udfordring: Hvidboks-test kan ikke anvendes til test af ikke-kodebaserede elementer, f.eks. test af brugergrænseflader, brugervenlighed eller den overordnede systemydeevne. I de fleste tilfælde skal disse elementer anvende sortboks-testteknikker til eksternt at validere, hvordan systemet fungerer, og ikke dets interne funktion.
• Eksempel: Hvidboks-test kan ikke teste, om et websted er opbygget hensigtsmæssigt, eller om webstedet er let at navigere på, da den ikke tester udseende, funktionalitet eller brugervenlighed fra slutbrugerens perspektiv.

Praktiske trin til overgangen fra sortboks-test til hvidboks-test

En mere omfattende testtilgang opnås ved at integrere hvidboks-test i en sortboks-fokuseret QA-proces, hvilket sikrer, at applikationens eksterne funktionalitet og interne logik verificeres fuldt ud. Nedenfor findes en detaljeret vejledning, der kan hjælpe teams med at gennemføre en problemfri overgang:

1. Analysér den aktuelle testproces

• Gennemgå eksisterende sortboks-test:
  • Vurdér sættet af eksisterende sortboks-testcases med hensyn til deres effektivitet, og peg samtidig på mangler i den interne kodedækning.
  • Identificér nøglefunktioner, der skal valideres yderligere på kodeniveau.

• Identificér mangler:
  • Se efter mangler på områder, hvor sortboks-test er begrænset med hensyn til egnethed, f.eks. komplekse algoritmer, sikkerhedsrelaterede forhold eller ydeevneproblemer.

Resultat: En klar forståelse af omfanget og begrænsningerne ved de eksisterende sortboks-test, hvilket dermed viser værdien af at tilføje hvidboks-test.

2. Opbyg de nødvendige kompetencer

• Uddan QA-teamet:
  • Hvis QA-teamet i øjeblikket fokuserer på sortboks-test, skal det opkvalificeres inden for programmering, fejlfinding og forståelse af kodebasen.
  • Tilbyd undervisning i almindelige testrammer og programmeringssprog, der bruges til hvidboks-test, f.eks. enhedstestrammer som JUnit (Java), NUnit (.NET) eller PyTest (Python).

• Identificér mangler:
  • Se efter mangler på områder, hvor sortboks-test er begrænset med hensyn til egnethed, f.eks. komplekse algoritmer, sikkerhedsrelaterede forhold eller ydeevneproblemer.

Resultat: En klar forståelse af omfanget og begrænsningerne ved de eksisterende sortboks-test, hvilket dermed viser værdien af at tilføje hvidboks-test.

3. Opsæt en hvidboks-teststruktur

• Vælg de rette værktøjer:
  • Vælg rammer og værktøjer til enhedstest til dit programmeringssprog:
    • Java: JUnit, TestNG
    • C#: NUnit, MSTest
    • JavaScript: Jest, Mocha
    • Python: PyTest, Unittest
  • Brug værktøjer til kodedækning til at følge, hvor meget af din kode der bliver testet:
    • Eksempler: JaCoCo (Java), Istanbul (JavaScript), Coverage.py (Python), OpenCover (C#).
• Kontinuerlig integration (CI):
  • Sørg for, at din CI-pipeline understøtter automatiseret test af intern kode, så testene kan køres automatisk ved hver kodeændring eller pull request.

Resultat: En velfungerende testramme, der understøtter både test af intern kode og test af ekstern funktionalitet i din CI/CD-pipeline.

4. Fokuser på mål for kodedækning

• Fastlæg mål for dækningen:
  • Fastlæg realistiske mål for kodedækningen (f.eks. 80 % for kritiske moduler) for at sikre, at test af intern kode giver tilstrækkelig dækning af den interne kode.
  • Brug dækningsrapporter til at identificere områder, der ikke er testet, f.eks. betingede grene eller løkker.
• Skab balance i kodedækningen:
  • Undgå at stræbe efter 100 % kodedækning, da det kan føre til aftagende udbytte. Fokuser på at teste kritiske logikstier, kanttilfælde og fejlhåndtering.

Resultat: En afbalanceret tilgang til kodedækning, der fokuserer på områder med høj risiko eller kritisk betydning og samtidig undgår unødvendigt omfattende tests.

5. Udvikl testcases til test af intern kode

• Prioritér kritisk kode:
  • Start med at skrive tests af intern kode for områder med høj risiko, f.eks. sikkerhed, kompleks logik eller flaskehalse i ydeevnen.
  • Skriv tests for grænsebetingelser, beslutningsstier, løkker og mekanismer til fejlhåndtering.
• Sæt testere sammen med udviklere:
  • Frem samarbejdet mellem udviklere og testere for at sikre, at testcases dækker både tekniske og funktionelle krav.
  • Brug teknikker som sætningsdækning, grendækning og stidækning for at sikre omfattende test af den interne logik.

Resultat: Testcases, der validerer kvaliteten af den interne kode, fejlhåndtering og ydeevne og supplerer test af ekstern funktionalitet.

6. Automatisér og integrér test

• Automatisér tests af intern kode:
  • Automatisér enhedstests og andre tests af intern kode i CI-pipelinen, så de køres ved hver kodeændring og sikrer hurtig feedback.
• Integrér begge testtilgange:
  • Sørg for, at tests af intern kode køres sammen med tests af ekstern funktionalitet i CI/CD-pipelinen, så der leveres både intern og ekstern validering på samme trin.
  • Automatisér regressionstest for at validere både intern og ekstern kode efter ændringer.

Resultat: Problemfri integration af tests af intern kode og tests af ekstern funktionalitet, der giver løbende feedback om både kodekvalitet og funktionalitet.

7. Vedligehold og videreudvikl testsamlinger

• Opdater tests med kodeændringer:
  • Hvidkassetests skal opdateres, hver gang den underliggende kode ændres. Dette indebærer et løbende samarbejde mellem udviklere og testere.
• Refaktorer testtilfælde:
  • Efterhånden som applikationen vokser, skal testtilfælde refaktoreres for at reducere redundans og forbedre vedligeholdelsen.
• Udvid til integrationstest:
  • Når tests på enheds- og modulniveau er på plads, skal hvidkassetestning udvides til integrationstests, der verificerer, hvordan forskellige dele af kodebasen interagerer.

Resultat: En bæredygtig og løbende udviklende testsuite, der tilpasser sig ændringer i kodebasen og opretholder høj dækning og nøjagtighed over tid.

8. Skab balance mellem hvidkasse- og sortkassetestning

• Supplerende strategier:
  • Oprethold en balance mellem begge tilgange. Hvidkassetestning fokuserer på intern logik, mens sortkassetestning validerer systemets overordnede adfærd fra brugerens perspektiv.
• Brug risikobaseret prioritering:
  • Brug hvidkassetestning til komplekse, kritiske eller sikkerhedsfølsomme områder, mens sortkassetestning bruges til brugerflows og bredere funktionalitet.
• Gentag processen:
  • Gennemgå regelmæssigt effektiviteten af teststrategien. Juster balancen mellem hvidkasse- og sortkassetestning baseret på testresultater og huller i kodedækningen.

Resultat: En omfattende teststrategi, der sikrer, at både applikationens interne og eksterne kvalitet løbende valideres.

Vigtige værktøjer til integration af hvidkassetestning

Bedste praksis for en vellykket overgang

1. Samarbejde på tværs af teams: For at sikre, at både hvidkasse- og sortkassetestning dækker vigtig funktionalitet og intern kvalitet, samt fremme samarbejdet mellem udviklere, testere og produktchefer.
2. Kontinuerlig læring: Når QA-teammedlemmer bevæger sig over i hvidkassetestning, skal de have løbende uddannelse, støtte og ressourcer, såsom nyhedsbreve om softwaretest, så de holder sig opdateret om nye værktøjer og testteknikker.
3. Regelmæssige testgennemgange: Evaluer og forbedr løbende testtilfælde, fjern duplikering, og tilpas dem, så de tager højde for ændringer i kodebasen.

Tilmeld dig for at få flere indsigter

Den største fordel ved at gå fra sortkassetestning til den mere kodebevidste tilgang for QA-fagfolk er, at den gør dem bedre til at teste og samarbejde med udviklere, hvilket resulterer i softwareproduktion af højere kvalitet. Selvom denne overgang ikke betyder, at dine QA-ingeniører bliver fuldt uddannede udviklere, er det et væsentligt skridt fremad i deres roller at vide, hvordan koden er skrevet – de kan løse fejl hurtigere og udvikle praktiske testtilfælde. 

At tilegne sig disse færdigheder vil være afgørende for, at QA-fagfolk kan fastholde deres plads ved bordet og endda styrke den!

Tilmeld dig The CTO Clubs nyhedsbrev for at få flere tips & indsigter om QA-testning.