9 soorten softwaretests in software-engineering

Statisch testen

Statisch testen is een type softwaretest dat vroeg in de ontwikkelingscyclus wordt uitgevoerd. Het is een kosteneffectieve manier om bugs te vinden voordat ze grote problemen voor het ontwikkelingsteam worden. Statische tests worden vroeg in de ontwikkelingscyclus uitgevoerd omdat ze kunnen worden gedaan zonder volledig werkende software. Dat klopt: de software kan worden gedebugd voordat deze zelfs maar bijna voltooid is. Zie je hoe dat van pas kan komen? 

Statische tests worden op twee manieren uitgevoerd:

• Handmatige onderzoeken: Code wordt geanalyseerd door een QA-analist of tester. 
• Automatische analyse: Een testtool controleert het programmadocument automatisch en noteert eventuele fouten.

Statisch testen is:

• Uitgevoerd zonder code uit te voeren.
• Kosteneffectief.
• Nuttig om ervoor te zorgen dat de software aan de verificatiespecificaties voldoet.
• Een manier om de hoofdoorzaak van bugs vast te stellen.

De meeste statische tests worden uitgevoerd in de vorm van documentbeoordelingen. In dit scenario is een document een schriftelijke beschrijving van een product (bekend als een softwareontwerpdocument) of de broncode van het programma. Hier zijn enkele technieken voor statisch testen die elke QA-analist zou moeten kennen:

• Informele beoordeling:  Er zijn geen strikte richtlijnen voor de informele beoordeling. Het team bekijkt de testdocumenten en geeft commentaar op wat het ziet. Er wordt niets gedocumenteerd.
• Doorloop: De auteur van de code loopt het document door en het QA-team stelt vragen en brengt aandachtspunten naar voren. Doorlopen zijn doorgaans zeer informeel en een goede manier om onderwerpen te bespreken met mensen buiten het softwarevakgebied. 
• Technische beoordeling: Technische experts komen bijeen en beoordelen de technische specificaties van de code. Door dit vroeg in het ontwikkelingsproces te doen, wordt ervoor gezorgd dat het eindproduct aan de vereiste specificaties voldoet.
• Inspecties: De meest formele van alle beoordelingen. Een team van getrainde moderatoren inspecteert de documenten tijdens de vergadering grondig. Gevonden bugs worden formeel gedocumenteerd en geregistreerd voor beoordeling. Er volgt een controle om na te gaan of de gedocumenteerde bugs zijn verholpen. 

In de meeste gevallen zijn statische testrapportages nuttig, omdat het volledige QA-team het product analyseert en wijzigingen voorstelt op basis van problemen die zij zien en problemen die zij verwachten. Naast het voordeel dat er een grote verscheidenheid aan meningen bij het gesprek wordt betrokken, heeft dit als bijkomend voordeel dat alle teamleden op de hoogte worden gebracht van de voortgang en het ontwerp van het project. 

Gebruik statisch testen als je team:

• Vroeg in het ontwikkelingsproces zit.
• Op zoek is naar een kosteneffectieve manier om bugs te vinden.
• Software heeft die nog niet kan worden uitgevoerd.
• Fouten vroeg in de ontwikkeling wil opsporen.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

Name*

First name Last name

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Business email*

Create Password*

This field is hidden when viewing the form

LinkedIn profile

This field is hidden when viewing the form

Company's AI adoption maturity

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

Dynamisch testen

In tegenstelling tot statisch testen is dynamisch testen een vorm van softwaretesten waarvoor de uitvoering van code vereist is. Uiteraard betekent dit dat de ontwikkeling verder gevorderd moet zijn in de productiecyclus. Het voordeel van het testen van uitvoerbare code is dat QA-analisten kunnen bekijken hoe de software presteert tijdens het gebruik in een praktijksituatie. Het is een goede manier om het functionele gedrag van de software en andere zaken, zoals CPU-gebruik, te controleren. Bij dynamisch testen wordt gecontroleerd of de verwachte uitkomst overeenkomt met de uitkomst in de praktijk. Het belangrijkste doel van dynamisch testen is verifiëren of het product voldoet aan de ontwerp- en functionele vereisten die vóór de start van het project zijn vastgesteld.

Bij het dynamisch testen van systeemsoftware zijn er doorgaans vier stappen die QA-analisten moeten kennen:

• Unittesten: Bij het unittesten van software wordt deze opgesplitst in de kleinst mogelijke onderdelen, die afzonderlijk worden getest. Door op deze manier te testen, kunnen QA-analisten erop vertrouwen dat elk afzonderlijk onderdeel van de software werkt zoals bedoeld. Als er een bug wordt gevonden, is deze in deze fase van de ontwikkeling gemakkelijker op te lossen, omdat de problematische code snel kan worden geïsoleerd. Wanneer het QA-team begint met dynamisch testen (hoewel deze testfase soms door het ontwikkelingsteam wordt uitgevoerd), begint het doorgaans met unittests.
• Integratietesten: Nadat de software grondig in onderdelen is opgesplitst en via unittesten is getest, worden de onderdelen samengevoegd tot groepen en opnieuw getest. Als unittesten ervoor zorgen dat elk afzonderlijk onderdeel correct werkt, zorgen integratietesten ervoor dat die afzonderlijke onderdelen met elkaar communiceren zoals bedoeld. Zie het als de assemblage van een auto. In elke assemblagefase worden de auto-onderdelen (de motor, de pedalen en het stuur) afzonderlijk getest. Vervolgens wordt de auto als geheel geassembleerd en getest, om er zeker van te zijn dat het gaspedaal correct met de motor communiceert (en dat de remmen dat ook doen!). Wil je zorgen voor een naadloze integratie tussen modules? Onze aanbevolen softwaretesttools kunnen je daarbij helpen.
• Systeemtesten: Systeemtesten vormen het derde niveau van softwaretesten. In deze fase wordt complete en volledig geïntegreerde software getest. Het doel van de systeemtest is ervoor te zorgen dat de software aan de vereisten voldoet, oftewel doet waarvoor deze is ontworpen. 
• Acceptatietesten: De laatste fase van dynamisch testen. Bij de acceptatietest wordt opnieuw getoetst aan de vereisten en wordt gecontroleerd of de software tot een aanvaardbare standaard is afgewerkt. Dit gebeurt om er zeker van te zijn dat er geen fouten door de andere testfasen zijn geglipt. In wezen is het een extra controle uit veiligheidsoverwegingen. 

Fasen van dynamisch testen

1. Unittesten
2. Integratietesten
3. Systeemtesten
4. Acceptatietesten
   

Snelle tip: testen van verificatie versus validatie 

Verificatietesten hebben alle belangrijke kenmerken van statisch testen. Het doel van een verificatietest is alle documenten en code te verifiëren. Dit wordt bereikt via dezelfde methoden die bij statisch testen worden gebruikt.

Ook validatietesten hebben alle belangrijke kenmerken van dynamisch testen. Bij een verificatietest draait het erom te bevestigen dat de software van hoge kwaliteit is; precies daar richten de systeem- en acceptatietests zich op.

Nu we enkele belangrijke concepten rond softwaretesten hebben behandeld, bekijken we de 9 soorten softwaretesten die elke QA-analist zou moeten kennen.

9 soorten softwaretesten die elke QA-analist zou moeten kennen:

1. Black-box
2. White-box
3. Grey-box 
4. Geautomatiseerd 
5. Unittesten
6. Regressie
7. Verkennend
8. Functioneel testen
9. Bruikbaarheidstesten

1. Testen met een zwarte doos

Testen met een zwarte doos is een softwareteststrategie waarbij het ontwerp van het geteste softwaresysteem onbekend is bij de tester.

Herinner je je die scène aan het einde van Pulp Fiction, waarin Samuel Jackson de koffer opent en zijn gezicht oplicht? Als publiek weten we wat de koffer betekent en vertegenwoordigt in de context van de film, maar we komen nooit te weten wat erin zit. Een tester van de zwarte doos is het publiekslid dat weet wat het ding (of het nu een koffer of systeemsoftware is) hoort te doen, maar niet waaruit het bestaat.

Een tester die verantwoordelijk is voor het testen met een zwarte doos van tijdregistratiesoftware opent het programma zonder kennis van het interne ontwerp van de software en probeert de verschillende functies en menu’s uit om er zeker van te zijn dat ze naar verwachting werken. De reden voor het testen met een zwarte doos is dat de tester, zonder diepgaande kennis van het ontwerp van de software, de software benadert met vergelijkbare verwachtingen als de eindgebruiker. 

Enkele voordelen van het testen met een zwarte doos zijn:

• Testers hebben niet veel kennis van programmeertalen nodig, omdat de tester de software gebruikt vanuit het perspectief van een gebruiker.
• Het biedt een onbevooroordeelde beoordeling van de software, omdat de softwaretest wordt uitgevoerd door het QA-team in plaats van door de softwareontwikkelaars.
• De testers hoeven niet volledig op de hoogte te zijn van de ontwikkeling van de softwaresystemen, waardoor er zeer weinig voorbereidingstijd nodig is voordat de tests kunnen worden uitgevoerd.

Gerelateerd artikel: 10 beste tools voor testen met een zwarte doos

2. Testen met een witte doos

Bij het testen met een witte doos begrijpt het QA-lid de interne structuur en het ontwerp van de geteste software volledig. De test wordt benaderd als een inspectie, waarbij wordt gecontroleerd of elk onderdeel van het programma correct werkt. Testen met een witte doos wordt soms testen met een heldere doos genoemd, omdat de tester de interacties tussen eenheden observeert tijdens het testen van de software. In tegenstelling tot testen met een zwarte doos houdt een tester van de witte doos zich veel minder bezig met de gebruikerservaring. 

Enkele voordelen van het testen met een witte doos zijn:

• Tests kunnen in een vroeg stadium van de ontwikkeling worden uitgevoerd. De grafische gebruikersinterface (GUI) hoeft nog niet volledig functioneel te zijn. 
• De tests zijn grondiger en doelgerichter dan tests met een zwarte doos.

In het voorbeeld van Pulp Fiction is de tester van de witte doos het personage van Tim Roth, dat rechtstreeks kijkt naar wat er in de koffer zit. 

3. Testen met een grijze doos

Bij het testen met een grijze doos heeft de tester enige kennis van de interne structuur en het ontwerp van de software (witte doos), maar test hij nog steeds vanuit het perspectief van een eindgebruiker (zwarte doos). Zo ontstond het testen met een grijze doos. Bij het testen met een grijze doos wordt het ontwerp van de test ontwikkeld door naar de interne structuur van de software te kijken, terwijl de daadwerkelijke test wordt uitgevoerd met behulp van de gebruikersinterface.

Als dit opnieuw die beroemde scène uit Pulp Fiction zou zijn, is de tester van de grijze doos noch het publiek, noch Tim Roth. Deze keer is de tester Quentin Tarantino zelf.  

4. Geautomatiseerd testen

Geautomatiseerde tests gebruiken software om taken uit te voeren zonder handmatige instructies van een tester.

Bij handmatig testen schrijft de tester de code die hij wil uitvoeren of plant hij het softwarepad waarvan hij wil controleren of het correct werkt. Geautomatiseerde tests nemen dergelijke taken namens de tester voor hun rekening. Hier volgt een korte lijst met geautomatiseerde software- en QA-tools die QA-analisten moeten kennen:

• Selenium 
• Cucumber
• Katalon Studio

Bekijk voor een diepgaandere beoordeling van tools voor geautomatiseerd testen de lijst met beste tools voor geautomatiseerd testen die je zou moeten gebruiken.

5. Unittesten

Tools voor unittesten zorgen ervoor dat elk afzonderlijk onderdeel van de software correct werkt. Het is uiterst belangrijk om ervoor te zorgen dat unittesten goed wordt uitgevoerd, omdat het ontwikkelteam anders met een enorme tegenslag te maken krijgt wanneer het later ontdekt dat een belangrijk onderdeel van de software niet werkt. 

6. Regressietesten

Tools voor regressietesten voeren oude tests uit op nieuwe builds om er zeker van te zijn dat de software nog steeds werkt zoals bedoeld. Het uitvoeren van regressietests beschermt ontwikkelaars tegen latente effecten door ervoor te zorgen dat een wijziging in de software op punt A niet per ongeluk iets op punt D heeft gebroken. 

Voor een QA-analist moeten twee stappen vooruit en één stap achteruit niet als iets negatiefs worden gezien. Door af en toe één stap achteruit te doen, zorg je ervoor dat je later niet op het punt staat om vijftig stappen achteruit te doen.

7. Verkennend testen

Verkennend testen is testen voor mensen die niet van plannen houden. In de meeste andere situaties wordt het testgeval grondig gepland voordat het wordt uitgevoerd. Hier niet. Wanneer een tester een verkennende test uitvoert, onderzoekt die de software zonder vooraf opgesteld plan, met behulp van gespecialiseerde tools voor verkennend testen.

Het voordeel van verkennend testen is dat de tester zich direct aan de bevindingen kan aanpassen, zonder dat er een nieuw testgeval hoeft te worden geschreven. Verkennend testen maakt ook samenwerking, theorievorming en overleg tijdens het proces mogelijk.

Naarmate de agile-ontwikkeltheorie prominenter is geworden, is dat ook het geval met verkennend testen. Door QA-testers hun intuïtie te laten gebruiken, worden veel interessante fouten gevonden waar een traditionele testuitvoering misschien niet naar zou hebben gezocht. 

Let op: verkennend testen kan veel creativiteit vereisen. 

More Articles

• Kwetsbaarheidsscanning versus penetratietesten
• 5 belangrijkste fasen van het proces voor kwetsbaarhedenbeheer
• Een handleiding voor QA’s over databasetests in 2026

8. Functioneel testen

Functioneel testen wordt uitgevoerd om er zeker van te zijn dat de systeemsoftware voldoet aan de projectvereisten die vóór de ontwikkeling zijn vastgesteld.

De softwaretester controleert of de invoer overeenkomt met de verwachte uitvoer. Dit gebeurt tijdens een van de laatste testfasen, bij systeemtests of acceptatietests, en het is uitsluitend een vorm van testen waarbij de software als een zwarte doos wordt beschouwd, omdat er niet wordt gekeken naar hoe de software werkt zolang deze maar werkt. 

9. Bruikbaarheidstesten

Testers van de bruikbaarheid zorgen ervoor dat ontwerpkeuzes functioneel en toch intuïtief zijn.

Als je voorspelt dat veel gebruikers van je software elke dertig minuten een back-up van hun documenten willen maken, kun je de back-upfunctie het beste op een gemakkelijk toegankelijke plek zetten in plaats van deze achter vier submenu's te verbergen. 

Vaak is er software ontwikkeld die vlekkeloos werkt en in een belangrijke behoefte op de markt voorziet, maar vanuit het perspectief van de gebruiker volledig onmogelijk te navigeren is. Dit kan worden verklaard door een gebrek aan bruikbaarheidstests tijdens de softwaretestfase.

Uiteindelijk geldt dat het, hoe goed een stuk software technisch ook is, moeilijk zal zijn om een markt te vinden als gebruikers het niet prettig vinden om ermee te werken.

Meer weten?

De sector van softwaretests verandert voortdurend en QA-analisten moeten op de hoogte blijven van actuele trends. Er zijn eindeloos veel bronnen over softwaretesten, waaronder podcasts, boeken en meer.

Abonneer je op de nieuwsbrief van The CTO Club voor productupdates, toolrecensies en meer overzichten van bronnen.