Antwoord.

White-box testing is gebaseerd op de kennis van de interne structuur en code van de applicatie. Historisch gezien was deze methode een voorrecht van ontwikkelaars, maar met de toenemende complexiteit van software zijn testers ook deze benaderingen gaan gebruiken. In tegenstelling tot black-box testing, waar alleen invoer- en uitvoergegevens worden getest, is er hier een begrip nodig van hoe het systeem intern werkt.

Belangrijke kenmerken:

Controleren van de logica, voorwaarden en vertakkingen in de code
Helpt bij het vinden van bugs die niet worden opgespoord bij black-box testing
Vereist code-analyse, communicatie met ontwikkelaars en basiskennis van programmeren

Probleem

Handmatige testers beperken zich vaak tot alleen gebruikersscenario's, waardoor mogelijke defecten op het niveau van de logica van de implementatie over het hoofd worden gezien. Dit leidt tot het missen van kritische fouten in complexe systemen.

Oplossing

Studeren van ten minste de basisprincipes van code-structurering, in staat zijn om eenvoudige functies en stroomschema's te lezen, leren vragen te stellen aan ontwikkelaars. Een handmatige tester die de principes van white-box testing begrijpt, valt op de markt meer op.

Vragen met een valkuil.

Wat is de fout om te denken dat handmatige testers geen white-box testing gebruiken?

Het is een misverstand om te denken dat deze benadering uitsluitend voor automatiseerders is. In veel bedrijven controleert de tester handmatig interne berekeningen, datatypes - vooral bij complexe projecten.

Is unit testing een synoniem voor white-box testing voor handmatige testers?

Nee. Unit tests zijn een automatiseringstool. Een handmatige tester gebruikt vergelijkbare analysemethoden, maar schrijft geen code voor deze controles.

Kun je je beperken tot gebruikersscenario's als de white-box benadering tijdens de ontwikkeling is toegepast?

Nee. Gebruikersondersteuningscenario's kunnen bugs vaststellen die over het hoofd zijn gezien op code-niveau. Alleen de combinatie van methoden vanuit het gebruikersperspectief en de code biedt maximale dekking.

Typische fouten en anti-patronen

Onvoldoende begrip van het vakgebied
Gebrek aan interne communicatie met het ontwikkelingsteam
Oppervlakkige analyse van wijzigingen in de code

Voorbeeld uit het leven

Negatieve case

De tester controleert de nieuwe module op basis van gebruikersscenario's, maar kijkt niet naar hoe de complexe logica van kortingen wordt berekend. Een bug in de berekening is gemist.

Voordelen:

Snelle dekking van de interface
Eenvoudige documentatie

Nadelen:

Kritiek defect gemist op het niveau van de bedrijfslogica
Verlies voor het bedrijf door onjuiste berekeningen

Positieve case

De tester analyseerde het stroomschema intern en vroeg de ontwikkelaars om toelichting over de berekening van kortingen, controleerde extra cases handmatig naast de gebruikers.