Waarom testen met open broncode de sleutel is tot beter bugs opsporen

Bij white-box testen moeten testers daarentegen volledig inzicht hebben in de interne codestructuur, zodat ze kunnen beoordelen hoe de software van binnenuit functioneert.

Black-box testen (functioneel testen)

Black-box testen is een methode voor softwaretesten waarbij de tester de functionaliteit van een toepassing beoordeelt zonder de interne code of structuur 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-box testen:

• Gebruikersgericht: Het simuleert realistische scenario’s vanuit het perspectief van de eindgebruiker. Testers valideren of het systeem aan de gebruikersvereisten voldoet 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-box testen kan op alle testniveaus worden gebruikt (unit-, integratie-, systeem- en acceptatietests), waardoor het veelzijdig is.
• Vroegtijdige detectie van problemen met vereisten: Omdat de focus op functionaliteit ligt, brengt black-box testen vaak misverstanden of inconsistenties in de oorspronkelijke vereisten aan het licht.

Toptools voor black-box testen!

1. 

   QA Wolf

   This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   4.9

   Visit Website
2. 

   Reflect

   This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   4.8

   Visit Website
3. 

   Squish

   This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   4.3

   Visit Website

Beperkingen van black-box testen:

• Beperkte dekking: Omdat de tester geen rekening houdt met de interne codestructuur, is er geen manier om te controleren of alle codepaden zijn getest, wat tot hiaten in de dekking leidt.
• Moeilijk om de hoofdoorzaak vast te stellen: Wanneer een defect wordt gevonden, kan black-box testen 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 testsituaties herhalen.
• Moeite met het testen van complexe logica: Zonder toegang tot de interne werking wordt het testen van complexe logica of uitzonderingsgevallen een uitdaging.

White-box testen (structureel testen)

Deze vorm van testen wordt ook 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 testgevallen controleren daarom de codepaden, beslispunten, lussen en interne werking van de toepassing.

Sterke punten van white-box testen:

• Volledige dekking: Testers kunnen ervoor zorgen dat alle codepaden, vertakkingen, lussen en voorwaardelijke instructies zijn gedekt. Hierdoor neemt de kans toe dat verborgen fouten worden geïdentificeerd.
• Vroegtijdige detectie van bugs in code: Het helpt bugs en beveiligingsproblemen vroegtijdig in de code te vinden, wat bij black-box testen niet mogelijk is. Prestatietesten: white-box testen kan prestatieknelpunten vinden en de code optimaliseren op basis van het gedetailleerde inzicht in de werking ervan.
• Prestatietesten: White-box testen kan helpen bij het identificeren van prestatieknelpunten en het optimaliseren van code op basis van gedetailleerd inzicht in de werking ervan.
• Inzicht in de hoofdoorzaak: Omdat de tester de code bekijkt, kan bij het aantreffen van een bug precies worden vastgesteld welk deel van de code gebrekkig is.

Beperkingen van white-box testen:

• Vereist programmeerkennis: Voor het testen is het nodig de interne code te begrijpen, meestal door ontwikkelaars of technische testers.
• Niet op de gebruiker gericht: Het zorgt ervoor dat de correctheid van de code wordt gewaarborgd, maar test niet of het systeem zich gedraagt zoals een gebruiker verwacht. De focus ligt intern op logica in plaats van extern op functionaliteit.
• Tijdrovend: Over het algemeen kost het veel middelen en tijd om voor elk codepad en elke voorwaarde gedetailleerde testgevallen te schrijven.
• Kan problemen met vereisten missen: White-box-testen kan er niet in slagen te detecteren of het systeem voldoet aan de vereisten van bedrijven of gebruikers, omdat het uitsluitend kijkt naar de werking van de interne code.

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

Belangrijkste voordelen van white-box-testen 

 1. Betere lokalisatie van defecten

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

 2. Verbeterde communicatie met ontwikkelaars

• Gedeeld begrip: Als QA-professionals de code begrijpen, beschikken ze over een taal die ze met ontwikkelaars kunnen delen en kunnen gebruiken om productiever over defecten te 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-professional met kennis van code is een betere beoordelaar, omdat die diepgaandere beoordelingen kan uitvoeren dan andere QA's en tijdens het beoordelingsproces zelfs met ontwikkelaars kan samenwerken om mogelijke defecten 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

• Gericht testen: Het helpt QA-professionals de code te kennen en het testen volledig te richten op de belangrijkste of meest complexe onderdelen van deze toepassing. In plaats van te gokken, kan QA bepalen welke onderdelen waarschijnlijker defect raken, waar nieuwe wijzigingen zijn aangebracht of waar complexe logica aanwezig is, en testgevallen schrijven die defecten eerder opsporen. Zo wordt testen veel waardevoller.

 4. Grotere testdekking en meer diepgang

• Verborgen defecten opsporen: Whiteboxtesten blinkt uit in 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 onderliggende oorzaak

• De oorsprong van defecten vaststellen: Inzicht in de code helpt de exacte onderliggende oorzaak vast te stellen. Een van de belangrijkste voordelen is bovendien dat QA, in plaats van ontwikkelaars alleen de symptomen van een defect te vertellen, het probleem kan onderzoeken tot aan de onderliggende oorzaak en zo betekenisvolle gegevens kan leveren 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 nog stabielere software opleveren.

6. Loopbaanontwikkeling en verbetering van vaardigheden

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

• Concurrentiepositie behouden: De software-industrie verandert voortdurend 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 — bijvoorbeeld door over te stappen naar technische testrollen of zelfs ontwikkelaarsfuncties.

Veelvoorkomende uitdagingen bij whiteboxtesten

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

1. Hoge complexiteit

• Uitdaging: Whiteboxtesten vereist grondige 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 extreem tijdrovend en moeilijk te onderhouden testproces.

2. Vereist diepgaande programmeerkennis

• Uitdaging: Omdat whiteboxtesten over de code zelf gaat, vereist het echt de expertise van een goede programmeur en 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 is mogelijk niet in staat om kritieke delen van de code te identificeren, effectieve tests te schrijven of bepaalde delen van de code zelfs maar te begrijpen.

3. Tijdrovend en arbeidsintensief

• Uitdaging: Het schrijven van uitgebreide testgevallen houdt in feite in dat codepaden, vertakkingen en voorwaarden moeten worden beschreven, wat doorgaans veel tijd kost en soms onuitvoerbaar omslachtig wordt, vooral bij complexe of grote systemen. Het schrijven en onderhouden van tests en het uitvoeren ervan wordt daardoor een arbeidsintensieve activiteit.
• 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 aanzienlijk tijdsbeslag voor ontwikkeling en testen.

4. Testgevallen onderhouden tijdens codewijzigingen

• Uitdaging: Tijdens de evolutie van code door het oplossen van bugs, het toevoegen van functies of het refactoren, kunnen bestaande testgevallen verouderd raken of moet u ze bijwerken. Witte-doostests zijn te nauw gekoppeld aan de implementatie en de kans dat ze moeten worden aangepast wanneer er wijzigingen in de codebasis plaatsvinden, is aanzienlijk.
• Voorbeeld: Telkens wanneer iets is gerefactord, zoals een functie of een wijziging in de logica, 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 elementen die geen code zijn

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

Praktische stappen voor de overgang van zwarte-doostests naar witte-doostests

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

1. Analyseer het huidige testproces

• Beoordeel bestaande zwarte-doostests:
  • Beoordeel de effectiviteit van de bestaande zwarte-doostestgevallen en wijs tegelijkertijd op tekortkomingen in de interne codedekking.
  • Identificeer belangrijke functies die verder op codeniveau moeten worden gevalideerd.

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

Resultaat: Duidelijk inzicht in de reikwijdte en beperkingen van bestaande zwarte-doostests, waarmee de toegevoegde waarde van witte-doostests wordt aangetoond.

2. Bouw de benodigde vaardigheden op

• Leid het QA-team op:
  • Als het QA-team zich momenteel richt op zwarte-doostests, geef het dan bijscholing in programmeren, foutopsporing en het begrijpen van de codebasis.
  • Verzorg trainingen in veelgebruikte testframeworks en talen die bij witte-doostests worden gebruikt, zoals unit-testframeworks als JUnit (Java), NUnit (.NET) of PyTest (Python).

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

Resultaat: Duidelijk inzicht in de reikwijdte en beperkingen van bestaande zwarte-doostests, waarmee de toegevoegde waarde van witte-doostests wordt aangetoond.

3. Zet een framework voor witte-doostests op

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

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

4. Focus op doelstellingen voor codedekking

• Dekkingsdoelen definiëren:
  • Stel realistische doelen voor codedekking vast (bijvoorbeeld 80% voor kritieke modules) om ervoor te zorgen dat white-boxtesten voldoende dekking van de interne code bieden.
  • Gebruik dekkingsrapporten om ongeteste gebieden te identificeren, zoals voorwaardelijke vertakkingen of lussen.
• Codedekking in balans brengen:
  • Streef niet naar 100% codedekking, omdat dit tot afnemende meeropbrengsten kan leiden. 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, en tegelijkertijd onnodige uitbreiding van de tests voorkomt.

5. White-boxtestgevallen ontwikkelen

• Kritieke code prioriteren:
  • Begin met het schrijven van white-boxtests voor gebieden met een hoog risico, zoals beveiliging, complexe logica of prestatieknelpunten.
  • Schrijf tests voor randvoorwaarden, beslispaden, lussen en mechanismen voor foutafhandeling.
• Testers aan ontwikkelaars koppelen:
  • 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-boxtests voor functionaliteit aanvullen.

6. Tests automatiseren en integreren

• White-boxtests automatiseren:
  • Automatiseer unittests en andere white-boxtests in de CI-pijplijn, zodat ze bij elke codewijziging worden uitgevoerd en snel feedback opleveren.
• Beide testbenaderingen integreren:
  • Zorg ervoor dat white-boxtests naast black-boxtests 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-boxtests en black-boxtests, met continue feedback over zowel codekwaliteit als functionaliteit.

7. Testsuites onderhouden en uitbreiden

• Tests bijwerken bij codewijzigingen:
  • White-boxtests moeten telkens worden bijgewerkt wanneer de onderliggende code verandert. Dit vereist voortdurende samenwerking tussen ontwikkelaars en testers.
• Testgevallen refactoren:
  • Naarmate de applicatie groeit, moet je ervoor zorgen dat testgevallen worden gerefactord om redundantie te verminderen en de onderhoudbaarheid te verbeteren.
• Uitbreiden naar integratietests:
  • Breid white-boxtests, zodra tests op unit- en moduleniveau aanwezig zijn, uit naar integratietests om te controleren hoe verschillende onderdelen van de codebase met elkaar samenwerken.

Resultaat: Een duurzame en zich ontwikkelende testsuite die zich aanpast aan veranderingen in de codebase en in de loop der tijd een hoge dekking en nauwkeurigheid behoudt.

8. White-boxtests en black-boxtests in balans brengen

• Aanvullende strategieën:
  • Bewaar een balans tussen beide benaderingen. White-box-testen richten zich op de interne logica, terwijl black-box-testen het algehele systeemgedrag vanuit het perspectief van de gebruiker valideren.
• Gebruik risicogebaseerde prioritering:
  • Gebruik white-box-testen voor complexe, kritieke of beveiligingsgevoelige onderdelen en black-box-testen voor gebruikersprocessen en bredere functionaliteit.
• Herhaal het proces:
  • Bekijk regelmatig de effectiviteit van de teststrategie. Pas de balans tussen white-box- en black-box-testen 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 consequent wordt gevalideerd.

Essentiële hulpmiddelen voor de integratie van white-box-testen

Beste praktijken voor een succesvolle overstap

1. Samenwerking tussen teams: Zorg ervoor dat zowel white-box- als black-box-testen cruciale functionaliteit en interne kwaliteit behandelen en bevorder samenwerking tussen ontwikkelaars, testers en productmanagers.
2. Continu leren: Geef QA-teamleden die overstappen op white-box-testen doorlopende training en ondersteuning, zodat ze op de hoogte blijven van nieuwe hulpmiddelen en testtechnieken.
3. Regelmatige testbeoordelingen: Evalueer en verbeter testgevallen voortdurend, verwijder duplicaten en pas ze aan veranderingen in de codebasis aan.

Word lid voor meer inzichten

Het grootste voordeel van de overstap van black-box-testen naar de meer codebewuste aanpak voor QA-professionals is dat ze hierdoor effectiever kunnen testen en samenwerken met ontwikkelaars, wat resulteert in software van betere kwaliteit. Hoewel deze overstap niet betekent dat je QA-engineers volwaardige ontwikkelaars worden, is inzicht in de manier waarop de code is geschreven een belangrijke vooruitgang in hun rol – ze kunnen defecten sneller oplossen en praktische testgevallen ontwikkelen. 

Het ontwikkelen 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.