Blackbox testing en Whitebox testing zijn termen die veel gebruikt worden in een SDLC (Software Delivery Lifecycle) Hoewel ze vaak in één adem worden genoemd, vertegenwoordigen ze twee totaal verschillende benaderingen van kwaliteitsborging. In een recente aflevering van de Quality Podcast doken Cynthia Maes, Jürgen Meheus en Günter Himschoot diep in deze materie.

Wat is het precies? Wanneer zet je welke techniek in? En waarom is de grens tussen beide soms grijzer dan we denken? In dit artikel vatten we de belangrijkste inzichten samen voor de professionele tester en de nieuwsgierige stakeholder.

Wat is Blackbox Testing? De kunst van de onwetendheid.

Bij Blackbox testing beschouw je de software als een ‘zwarte doos’. Je weet wat je erin stopt (input) en je weet wat eruit moet komen (output), maar hoe de code binnenin precies werkt, is voor jou als tester irrelevant.

Focus op specificaties

Het startpunt voor Blackbox testing is de analyse. Jurgen Meheus legt uit:

“Je gaat functioneel nagaan of een applicatie voldoet aan de specificaties. Wat de analist heeft gecapteerd van de eindgebruiker en vertaald naar user stories, is onze input. We kijken of wat de ontwikkelaar heeft gebouwd, klopt met de werkelijkheid van de klant.”

Een praktijkvoorbeeld: De login-poging

Stel dat een requirement stelt dat een gebruiker geblokkeerd moet worden na drie foutieve inlogpogingen.

• De blackbox aanpak: Je voert drie keer een foutief wachtwoord in en controleert of de melding “User geblokkeerd” verschijnt.
• De onwetendheid: Of de ontwikkelaar dit heeft opgelost met een if-statement, een while-loop of een specifieke database-trigger, maakt voor de functionele tester niet uit. Het resultaat telt.

Wat is Whitebox Testing? Onder de motorkap kijken

Tegenover de zwarte doos staat de Whitebox testing (ook wel Glass Box of Structural testing genoemd). Hierbij is de interne structuur, het design en de code van de software wél zichtbaar en vormt het de basis voor de tests.

Terwijl Blackbox testing zich richt op wat de software doet, richt Whitebox testing zich op hoe de software het doet. Hier kijken we naar zaken als:

• Code Coverage: Worden alle paden in de code doorlopen?
• Performantie: Zijn bepaalde lijnen code efficiënt geschreven of zorgen ze voor vertraging?
• Beveiliging: Zitten er zwakheden in de logica van de code zelf?

Hoewel pure QA-engineers zich vaak focussen op Blackbox, wordt Whitebox testing meestal uitgevoerd door ontwikkelaars (bijvoorbeeld via Unit Tests) of door technische testers die tools zoals SonarQube gebruiken om de codekwaliteit te monitoren.

De grijze zone: strategie en risico

In de praktijk zijn de grenzen tussen Blackbox en Whitebox soms vaag. Dit komt omdat softwarekwaliteit geen zwart-wit verhaal is. Volgens de experts van M2Q is het essentieel dat er een solide teststrategie of een testplan klaarligt.

Risico-gebaseerd testen

Je kunt nooit alles testen. De keuze voor een bepaalde techniek hangt vaak af van een risicoanalyse.

• Hoge kritiekheid: Voor cruciale systemen (bijv. medische software of financiële transacties) wil je een hoge code coverage (Whitebox) gecombineerd met uitgebreide combinatietests (Blackbox).
• Budget en Tijd: Soms dwingen beperkte middelen je om prioriteiten te stellen. In dat geval worden lage risico’s naar achteren geschoven. De tester fungeert hier als adviseur voor de stakeholders: “Als we nu live gaan, zijn dit de bekende risico’s.”

Krachtige technieken binnen Blackbox testing

Om Blackbox testing gestructureerd aan te pakken, zijn er verschillende technieken beschikbaar. Tijdens de podcast kwamen er enkele belangrijke aan bod:

1. Decision Table Testing (beslistabellen)

Wanneer een applicatie veel complexe combinaties van regels heeft, biedt een beslistabel uitkomst. Je schrijft alle mogelijke combinaties van inputs uit om te zien of de output telkens correct is.

• AI-integratie: Tegenwoordig hoef je deze tabellen niet meer handmatig om te zetten naar testcases. Door de tabel te uploaden in een AI-tool, genereer je in een handomdraai volledige testscenario’s die je kunt importeren in je testmanagementtool.

2. Equivalence Partitioning & Boundary Value Analysis

Hierbij deel je inputdata op in groepen (partities) waarvan je verwacht dat de software ze op dezelfde manier behandelt.

• Het gevaar: Als je enkel de partities test maar de grenswaarden (boundaries) vergeet, mis je vaak de meest kritieke bugs. Ontwikkelaars maken namelijk vaak fouten op de randjes (bijv. < in plaats van <=).

De rol van agile en documentatie

De verschuiving naar Agile werken heeft de dynamiek van testen veranderd. Er wordt minder gedocumenteerd (“zo weinig mogelijk, maar niet nul”), wat kansen én uitdagingen biedt.

• Shift Left: Door testers vroeger in het proces te betrekken (bijvoorbeeld bij het bespreken van mock-ups), voorkom je fouten voordat er één regel code is geschreven. Dit is enorm kostenbesparend.
• Hybride werken: Nu we vaker op afstand werken, is communicatie cruciaal. Een snelle wijziging in een ‘war room’ werd vroeger door iedereen gehoord; nu moet die wijziging goed gedocumenteerd worden zodat de tester niet de verkeerde (verouderde) specificaties controleert.

Code coverage: Een valse veiligheid?

Een veelgehoorde term bij Whitebox testing is Code Coverage. Tools kunnen precies vertellen dat je bijvoorbeeld 80% van de code hebt geraakt tijdens je tests. Maar let op:

“Code coverage zegt alles over welke regels code zijn aangeraakt, maar niets over de kwaliteit van de code of de kwaliteit van je tests,” waarschuwt Jurgen.

Je kunt 100% coverage hebben en toch een bug missen omdat de code simpelweg niet doet wat de klant gevraagd heeft. Daarom is de combinatie van functioneel (Blackbox) en structureel (Whitebox) testen zo krachtig.

Wanneer stop je met testen?

De vraag “Wanneer zijn we klaar?” is misschien wel de moeilijkste in het vak. Het antwoord is zelden “als alle bugs eruit zijn”, want 100% bugvrije software bestaat niet. Je stopt wanneer de vooraf bepaalde acceptatiecriteria zijn behaald en het restrisico acceptabel is voor de business.

Of je nu kiest voor Blackbox, Whitebox, of een hybride vorm: het doel blijft hetzelfde. Je wilt aantonen dat de applicatie klaar is voor productie en de risico’s voor de eindgebruiker minimaliseren.

Word een Expert in Testing

Wil je dieper in de wereld van Blackbox en Whitebox testing duiken? Bij M2Q bieden we gespecialiseerde opleidingen aan, zoals de ISTQB-gebaseerde trainingen, waarin hoofdstukken volledig gewijd zijn aan deze technieken. Je leert niet alleen de theorie, maar vooral ook welke techniek je in welke situatie het beste toepast.

Meer weten? Bekijk onze opleidingspagina of beluister de volledige aflevering van de Quality Podcast!

Ga met ons in overleg over de juiste aanpak voor uw onderneming tijdens een gratis online consult. Registreer uw consult met de CEO hier.