Waarom testen met de witte doos de sleutel is tot het beter opsporen van bugs

Stel je voor dat je een puzzel probeert op te lossen zonder ooit de stukjes in de doos te zien—dat is black-boxtesten in een notendop. Het is een geweldige aanpak om problemen aan de oppervlakte op te sporen, maar wat als je dieper wilt gaan, de hoofdoorzaak van defecten wilt achterhalen en wilt begrijpen wat er onder de motorkap gebeurt? Je oplossing is white-boxtesten – een methode die inzicht geeft in de code, waardoor defecten nauwkeuriger kunnen worden geanalyseerd en voorkomen. 

In dit artikel leg ik uit hoe de overstap van black-box- naar white-boxtesten diepere inzichten kan opleveren, zodat je problemen bij de bron kunt opsporen en de algehele codekwaliteit kunt verbeteren.

Verschillen tussen black-box- en white-boxtesten

Beide methoden zijn gericht op het identificeren en oplossen van defecten in software, maar ze verschillen aanzienlijk in aanpak en focus. Bij black-boxtesten wordt het systeem behandeld als een "black box", waarbij testers geen kennis hebben van de interne werking en zich uitsluitend richten op de uitvoer van de software op basis van verschillende invoerwaarden.

White-boxtesten vereisen daarentegen dat testers volledig inzicht hebben in de interne codestructuur, zodat ze kunnen beoordelen hoe de software van binnenuit functioneert.

Black-boxtesten (functioneel testen)

Black-boxtesten is een methode voor softwaretesten waarbij de tester de functionaliteit van een applicatie beoordeelt zonder de interne code of structuur ervan te kennen. Je werkt in feite met het “wat” van het systeem: je controleert de uitvoer zonder de interne werking te begrijpen. Testers richten zich op de invoer en verwachte uitvoer en zorgen ervoor dat het systeem zich gedraagt zoals vereist.

Sterke punten van black-boxtesten:

• Gebruikersgericht: Het simuleert praktijkscenario's vanuit het perspectief van de eindgebruiker. Testers controleren of het systeem voldoet aan de gebruikersvereisten en invoer correct verwerkt.
• Geen programmeerkennis vereist: Testers hoeven geen kennis te hebben van de interne code, waardoor niet-ontwikkelaars of mensen zonder diepgaande programmeervaardigheden tests kunnen uitvoeren.
• Toepasbaar op elk niveau: Black-boxtesten kan worden gebruikt op alle testniveaus (unit-, integratie-, systeem- en acceptatietests), waardoor het veelzijdig inzetbaar is.
• Vroegtijdige detectie van problemen met vereisten: Omdat de focus op functionaliteit ligt, brengt black-boxtesten vaak misverstanden of inconsistenties in de oorspronkelijke vereisten aan het licht.

Beperkingen van black-boxtesten:

• Beperkte dekking: Omdat de tester geen rekening houdt met de interne codestructuur, is er geen manier om te controleren of alle codepaden worden getest, wat tot hiaten in de dekking leidt.
• Moeilijk om de hoofdoorzaak vast te stellen: Wanneer een defect wordt gevonden, kan black-boxtesten alleen aantonen dat er een probleem bestaat, maar geen inzicht geven in waar in de code het probleem zich bevindt.
• Overbodigheid: Het kan voorkomen dat bepaalde interne structuren of voorwaarden niet worden getest, en testers kunnen onbewust testscenario's herhalen.
• Moeilijkheden bij het testen van complexe logica: Zonder toegang tot de interne werking wordt het testen van complexe logica of uitzonderingssituaties een uitdaging.

White-boxtesten (structureel testen)

Deze vorm van testen wordt ook wel structureel testen genoemd en omvat het testen van interne structuren, logica en zelfs de code van de software. De testcase moet worden ontworpen door een tester met programmeerkennis; dergelijke testcases controleren daarom de codepaden, beslispunten, lussen en interne werking van de applicatie.

Sterke punten van white-boxtesten:

• Volledige dekking: Testers kunnen ervoor zorgen dat alle codepaden, vertakkingen, lussen en voorwaardelijke instructies zijn afgedekt. Dit vergroot de kans dat verborgen fouten worden geïdentificeerd.
• Vroege foutdetectie in de code: Het helpt om fouten en beveiligingskwetsbaarheden vroegtijdig in de code te vinden, wat niet mogelijk is bij black-boxtesten. Prestatietesten: White-boxtesten kunnen prestatieknelpunten vinden en de code optimaliseren op basis van het gedetailleerde inzicht in de werking ervan.
• Prestatietesten: White-boxtesten kunnen helpen prestatieknelpunten te identificeren en code te optimaliseren op basis van gedetailleerd inzicht in de werking ervan.
• Inzicht in de hoofdoorzaak: Omdat de tester de code bekijkt, kan deze precies vaststellen welk deel van de code gebrekkig is wanneer er een fout optreedt.

Beperkingen van white-boxtesten:

• Programmeerkennis vereist: Voor het testen is inzicht in de interne code nodig, meestal bij ontwikkelaars of technische testers.
• Niet gebruikersgericht: Het zorgt ervoor dat de code correct is, maar test niet of het systeem zich gedraagt zoals een gebruiker verwacht. De focus ligt intern op logica in plaats van op externe functionaliteit.
• Tijdrovend: Over het algemeen kost het schrijven van gedetailleerde testgevallen voor elk codepad en elke voorwaarde veel middelen en tijd.
• Mogelijk worden problemen met vereisten gemist: White-boxtesten kunnen mogelijk niet vaststellen of het systeem voldoet aan de vereisten van bedrijven of gebruikers, omdat uitsluitend naar de werking van de interne code wordt gekeken.

Scenario's voor black-box- of white-boxtesten

Belangrijkste voordelen van white-boxtesten 

 1. Betere lokalisatie van fouten

• De coderegel opsporen: QA-technici kunnen snel bepalen waar de fout in een verzameling bronbestanden is ontstaan. Ze melden niet alleen een fout op basis van wat ze in de gebruikersinterface zien, maar kunnen precies aangeven welk deel (regel en blok) in de broncode mogelijk problematisch is. Deze functie vermindert de tijd die ontwikkelaars nodig hebben om fouten te onderzoeken en op te lossen aanzienlijk.
• Snellere oplossingstijden: Door ontwikkelaars precies te laten weten waar zich een probleem in hun toepassing bevindt, kunnen QA's aanvullende details (zoals uitleg en taalspecifieke informatie) over de fout geven. Zo kunnen ontwikkelaars problemen sneller oplossen en besparen ze tijd bij het achterhalen van wat er überhaupt mis is. Dit is essentieel voor snelle ontwikkelomgevingen en belangrijk om de totale tijd tot marktintroductie te verkorten.

 2. Verbeterde communicatie met ontwikkelaars

• Gedeeld begrip: Als QA-professionals de code begrijpen, beschikken ze over een gemeenschappelijke taal die ze met ontwikkelaars kunnen delen en waarmee ze productiever over fouten kunnen praten. Dit gedeelde begrip leidt tot betere communicatie, vermindert het risico op fouten en zorgt ervoor dat problemen sneller worden opgelost.
• Proactieve samenwerking: Een QA-medewerker met codekennis is een betere beoordelaar, omdat deze grondigere beoordelingen kan uitvoeren dan andere QA-medewerkers en tijdens het beoordelingsproces met ontwikkelaars kan samenwerken om potentiële fouten zo vroeg mogelijk op te sporen. Deze proactieve aanpak creëert een meer uniforme ontwikkelmethode waarin kwaliteit rechtstreeks in de software wordt ingebouwd.

 3. Verfijnde teststrategieën

• Gerichte tests: Dit helpt QA-professionals de code te kennen en het testen volledig te richten op de belangrijkste of meest complexe onderdelen van deze applicatie. In plaats van te gokken, kan QA vaststellen welke onderdelen waarschijnlijker defect raken, waar nieuwe wijzigingen zijn aangebracht of waar complexe logica aanwezig is, en testgevallen schrijven die defecten eerder opsporen, waardoor testen veel nuttiger wordt.

 4. Hogere testdekking en meer diepgang

• Verborgen defecten opsporen: Whiteboxtesten zijn uitstekend geschikt voor het opsporen van verborgen defecten, zoals logische fouten, dode code en beveiligingskwetsbaarheden, die mogelijk niet alleen met functioneel testen worden gevonden. Dit inzichtsniveau brengt zelfs de meest subtiele en ingewikkelde problemen aan het licht die nodig zijn om de algehele softwarekwaliteit te verbeteren.
• Uitgebreide dekking: Op deze manier kan de QA-professional die de code begrijpt garanderen dat kritieke paden en randgevallen van elk pad in de software zijn afgedekt. Deze volledige dekking is moeilijk uitsluitend met blackboxtesten te bereiken, omdat testers sommige scenario's kunnen missen doordat ze de code niet kunnen zien.

 5. Verbeterde analyse van de hoofdoorzaak

• De oorzaak van defecten opsporen: Inzicht in de code helpt de exacte hoofdoorzaak vast te stellen. Een van de belangrijkste voordelen is bovendien dat QA, in plaats van ontwikkelaars  alleen symptomen van een defect te vertellen, het probleem tot aan de hoofdoorzaak kan onderzoeken en zo betekenisvolle gegevens kan aanleveren die tot betere oplossingen leiden
• Defecten bij de bron elimineren: QA kan soortgelijke problemen in de toekomst helpen voorkomen door te begrijpen waarom defecten optreden. Dit levert de best mogelijke code en betere programmeergewoonten op, die op hun beurt voor nog stabielere software zorgen.

6. Loopbaanontwikkeling en verbetering van vaardigheden

• De rol van QA uitbreiden: Het verwerven van het vermogen om code te analyseren leidt tot extra verantwoordelijkheid voor QA-professionals, waardoor hun waarde als teamleden toeneemt. Ze groeien van basistesters uit tot volwaardige belanghebbenden in de ontwikkelingscyclus, waarbij ze actief de systeemkwaliteit en algehele stabiliteit verbeteren.

• Concurrentiepositie behouden: De software-industrie ontwikkelt zich en de vraag naar QA-professionals die code kunnen lezen – en schrijven – groeit. Met deze vaardigheden zijn QA-professionals aantrekkelijker op de arbeidsmarkt en kunnen ze een nieuwe richting inslaan binnen hun loopbaan — misschien door over te stappen naar technische test-rollen of zelfs ontwikkelaarsfuncties.

Veelvoorkomende uitdagingen bij whiteboxtesten

Whiteboxtesten zijn weliswaar een krachtige aanpak om een hoge codedekking en interne kwaliteit te waarborgen, maar brengen ook hun eigen uitdagingen met zich mee. Hieronder staan enkele veelvoorkomende uitdagingen bij het gebruik van whiteboxtesten:

1. Hoge complexiteit

• Uitdaging: Whiteboxtesten vereisen diepgaande kennis van de interne werking van een applicatie, waaronder de codestructuur, paden en logica. De extra complexiteit van de codebasis in grotere applicaties, met veel modules of complexe algoritmen, overstijgt al snel het menselijke vermogen om de code volledig te begrijpen en te onderhouden.
• Voorbeeld: Het testen van alle paden in een systeem met diep geneste voorwaarden en lussen kan worden beschouwd als een uiterst tijdrovend en moeilijk te onderhouden testproces.

2. Vereist diepgaande programmeerkennis

• Uitdaging: Omdat whiteboxtesten om de code zelf draaien, is hiervoor echt de expertise van een goede programmeur nodig, evenals iemand die vertrouwd is met de architectuur van de applicatie. Testers met een niet-technische achtergrond kunnen moeite hebben met het schrijven of begrijpen van testgevallen.
• Voorbeeld: Een QA-tester zonder ervaring met softwareontwikkeling kan mogelijk geen kritieke delen van de code identificeren, geen effectieve tests schrijven of bepaalde delen van de code zelfs maar begrijpen.

3. Tijdrovend en arbeidsintensief

• Uitdaging: Het schrijven van uitgebreide testgevallen is in feite het schrijven van codepaden, vertakkingen en voorwaarden, wat meestal een lange periode vergt en soms onmogelijk vervelend wordt, vooral wanneer men complexe of grote systemen moet afhandelen. Het wordt een arbeidsintensieve activiteit om tests te schrijven en te onderhouden en deze tests vervolgens uit te voeren.
• Voorbeeld: Bij grote systemen met integraties van veel verschillende partners kan het weken duren om voor elke voorwaardelijke vertakking een test te schrijven. Dit kan gemakkelijk leiden tot een groot tijdsbeslag voor ontwikkeling en testen.

4. Testgevallen onderhouden tijdens codewijzigingen

• Uitdaging: Tijdens de ontwikkeling van code door het oplossen van fouten, het toevoegen van functies of herstructurering kunnen bestaande testgevallen verouderd raken of moeten ze worden bijgewerkt. Witte-doostesten zijn te nauw gekoppeld aan de implementatie en moeten waarschijnlijk aanzienlijk worden aangepast wanneer er wijzigingen in de codebasis plaatsvinden.
• Voorbeeld: Elke keer dat iets wordt geherstructureerd, zoals een functie, of wanneer er een wijziging in de logica plaatsvindt, kan het testgeval dat dat deel van de code afdekt ook moeten worden herschreven of aangepast, waardoor het aantal onderhoudswerkzaamheden toeneemt.

5. Beperkte toepasbaarheid voor niet-code-elementen

• Uitdaging: Witte-doostesten kunnen niet worden toegepast op het testen van niet-code-elementen, zoals het testen van gebruikersinterfaces, gebruiksvriendelijkheid of de algehele systeemprestaties. In de meeste gevallen zullen deze elementen zwarte-doostesttechnieken moeten gebruiken om extern te valideren hoe het systeem functioneert, in plaats van intern.
• Voorbeeld: Met witte-doostesten kan niet worden getest of een website goed is ingedeeld of dat de site eenvoudig te navigeren is, omdat het uiterlijk en de gebruiksvriendelijkheid niet worden getest vanuit het perspectief van de eindgebruiker.

Praktische stappen voor de overgang van zwarte-doos- naar witte-doostesten

Een uitgebreidere testaanpak wordt geboden door witte-doostesten op te nemen in een op zwarte-doostesten gericht QA-proces, waarmee wordt gegarandeerd dat de externe functionaliteit en interne logica van de applicatie volledig worden geverifieerd. Hieronder staat een gedetailleerde handleiding om teams te helpen deze overgang soepel te maken:

1. Analyseer het huidige testproces

• Beoordeel bestaande zwarte-doostesten:
  • Beoordeel de effectiviteit van de bestaande zwarte-doostestgevallen en wijs tegelijkertijd op tekortkomingen in de dekking van de interne code.
  • Breng belangrijke functies in kaart die verder op codeniveau moeten worden gevalideerd.

• Identificeer hiaten:
  • Zoek naar hiaten op gebieden waar zwarte-doostesten beperkt zijn wat betreft geschiktheid, bijvoorbeeld bij complexe algoritmen, beveiligingsgerelateerde problemen of prestatieproblemen.

Resultaat: Een duidelijk inzicht in de reikwijdte en beperkingen van bestaande zwarte-doostesten, waardoor de toegevoegde waarde van witte-doostesten zichtbaar wordt.

2. Bouw de benodigde vaardigheden op

• Train het QA-team:
  • Als het QA-team zich momenteel richt op zwarte-doostesten, geef het dan aanvullende vaardigheden op het gebied van programmeren, foutopsporing en het begrijpen van de codebasis.
  • Bied training aan in algemene testraamwerken en programmeertalen die bij witte-doostesten worden gebruikt, zoals raamwerken voor unittests zoals JUnit (Java), NUnit (.NET) of PyTest (Python).

• Identificeer hiaten:
  • Zoek naar hiaten op gebieden waar zwarte-doostesten beperkt zijn wat betreft geschiktheid, bijvoorbeeld bij complexe algoritmen, beveiligingsgerelateerde problemen of prestatieproblemen.

Resultaat: Een duidelijk inzicht in de reikwijdte en beperkingen van bestaande zwarte-doostesten, waardoor de toegevoegde waarde van witte-doostesten zichtbaar wordt.

3. Zet een raamwerk voor witte-doostesten op

• Kies de juiste hulpmiddelen:
  • Selecteer frameworks en hulpmiddelen voor unit-tests voor je programmeertaal:
    • Java: JUnit, TestNG
    • C#: NUnit, MSTest
    • JavaScript: Jest, Mocha
    • Python: PyTest, Unittest
  • Gebruik hulpmiddelen voor codedekking om bij te houden welk deel van je code wordt getest:
    • Voorbeelden: JaCoCo (Java), Istanbul (JavaScript), Coverage.py (Python), OpenCover (C#).
• Continue integratie (CI):
  • Zorg ervoor dat je CI-pijplijn geautomatiseerd white-box-testen ondersteunt, zodat tests automatisch worden uitgevoerd bij elke codecommit of pullrequest.

Resultaat: Een goed geïntegreerd testframework dat zowel white-box- als black-box-tests binnen je CI/CD-pijplijn ondersteunt.

4. Richt je op doelen voor codedekking

• Definieer dekkingsdoelen:
  • Stel realistische doelen voor codedekking vast (bijvoorbeeld 80% voor kritieke modules) om ervoor te zorgen dat white-box-testen voldoende dekking van de interne code bieden.
  • Gebruik dekkingsrapporten om niet-geteste onderdelen te identificeren, zoals voorwaardelijke vertakkingen of lussen.
• Breng codedekking in balans:
  • Streef niet naar 100% codedekking, omdat dit kan leiden tot afnemende meeropbrengsten. Richt je op het testen van kritieke logische paden, randgevallen en foutafhandeling.

Resultaat: Een evenwichtige aanpak van codedekking die zich richt op gebieden met een hoog risico of een kritieke functie, terwijl onnodige uitdijing van de tests wordt voorkomen.

5. Ontwikkel white-box-testgevallen

• Geef prioriteit aan kritieke code:
  • Begin met het schrijven van white-box-tests voor gebieden met een hoog risico, zoals beveiliging, complexe logica of knelpunten in de prestaties.
  • Schrijf tests voor randvoorwaarden, beslispaden, lussen en mechanismen voor foutafhandeling.
• Laat testers samenwerken met ontwikkelaars:
  • Stimuleer samenwerking tussen ontwikkelaars en testers om ervoor te zorgen dat testgevallen zowel technische als functionele vereisten afdekken.
  • Gebruik technieken zoals statementdekking, vertakkingsdekking en paddekking om uitgebreide tests van de interne logica te garanderen.

Resultaat: Testgevallen die de kwaliteit van de interne code, foutafhandeling en prestaties valideren en black-box-tests voor functionaliteit aanvullen.

6. Automatiseer en integreer tests

• Automatiseer white-box-tests:
  • Automatiseer unit-tests en andere white-box-tests in de CI-pijplijn, zodat ze bij elke codewijziging worden uitgevoerd en snel feedback opleveren.
• Integreer beide testbenaderingen:
  • Zorg ervoor dat white-box-tests naast black-box-tests in de CI/CD-pijplijn worden uitgevoerd, zodat in dezelfde fase zowel interne als externe validatie plaatsvindt.
  • Automatiseer regressietests om zowel interne als externe code na wijzigingen te valideren.

Resultaat: Naadloze integratie van white-box- en black-box-tests, met continue feedback over zowel de codekwaliteit als de functionaliteit.

7. Onderhoud en ontwikkel testsuites

• Tests bijwerken met codewijzigingen:
  • Tests met inzicht in de broncode moeten worden bijgewerkt wanneer de onderliggende code verandert. Dit vereist voortdurende samenwerking tussen ontwikkelaars en testers.
• Testgevallen refactoren:
  • Naarmate de applicatie groeit, moeten testgevallen worden gerefactord om redundantie te verminderen en de onderhoudbaarheid te verbeteren.
• Uitbreiden naar integratietests:
  • Zodra tests op unit- en moduleniveau zijn geïmplementeerd, moet het testen met inzicht in de broncode worden uitgebreid naar integratietests, waarbij wordt gecontroleerd hoe verschillende onderdelen van de codebasis met elkaar samenwerken.

Resultaat: Een duurzame en zich ontwikkelende testsuite die zich aanpast aan veranderingen in de codebasis en na verloop van tijd een hoge dekking en nauwkeurigheid behoudt.

8. Testen met en zonder inzicht in de broncode in balans brengen

• Aanvullende strategieën:
  • Bewaar een balans tussen beide benaderingen. Testen met inzicht in de broncode richt zich op de interne logica, terwijl testen zonder inzicht in de broncode het algemene systeemgedrag vanuit het perspectief van de gebruiker valideert.
• Op risico gebaseerde prioritering gebruiken:
  • Gebruik testen met inzicht in de broncode voor complexe, kritieke of beveiligingsgevoelige onderdelen, en testen zonder inzicht in de broncode voor gebruikersprocessen en bredere functionaliteit.
• Het proces herhalen:
  • Bekijk regelmatig de effectiviteit van de teststrategie. Pas de balans tussen testen met en zonder inzicht in de broncode aan op basis van testresultaten en hiaten in de codedekking.

Resultaat: Een uitgebreide teststrategie die ervoor zorgt dat zowel de interne als de externe kwaliteit van de applicatie voortdurend wordt gevalideerd.

Essentiële hulpmiddelen voor de integratie van testen met inzicht in de broncode

Beste werkwijzen voor een succesvolle overgang

1. Samenwerking tussen teams: Zorg ervoor dat zowel testen met als zonder inzicht in de broncode cruciale functionaliteit en interne kwaliteit afdekken en bevorder samenwerking tussen ontwikkelaars, testers en productmanagers.
2. Continu leren: Wanneer QA-teamleden overstappen op testen met inzicht in de broncode, moet je hun doorlopende training, ondersteuning en hulpmiddelen bieden, zoals nieuwsbrieven over softwaretesten, zodat ze op de hoogte blijven van nieuwe tools en testtechnieken.
3. Regelmatige testbeoordelingen: Evalueer en verbeter testgevallen voortdurend, verwijder duplicatie en pas ze aan om rekening te houden met veranderingen in de codebasis.

Word lid voor meer inzichten

Het grootste voordeel van de overstap van testen zonder inzicht in de broncode naar de meer codebewuste aanpak voor QA-professionals is dat zij effectiever kunnen testen en met ontwikkelaars kunnen samenwerken, wat resulteert in softwareproductie van hogere kwaliteit. Hoewel deze overgang niet betekent dat je QA-engineers volwaardige ontwikkelaars worden, is kennis van de manier waarop de code is geschreven een belangrijke stap vooruit in hun rol – ze kunnen defecten sneller oplossen en praktische testgevallen ontwikkelen. 

Het aanleren van deze vaardigheden is de sleutel voor QA-professionals om hun plaats aan tafel te bevestigen en deze zelfs te versterken!

Abonneer je op de nieuwsbrief van The CTO Club voor meer tips en inzichten over QA-testen.