Skip to main content

Softwaretesten is een vak. Een softwaretester moet, net als een vakman, een grondig inzicht hebben in de softwaretesttools die tot zijn beschikking staan. We hebben een lijst samengesteld van 9 verschillende typen softwaretests en de tools die voor elk type worden gebruikt, om QA-analisten en iedereen die werkzaam is in het beroep van softwaretesten te helpen hun vak beter te begrijpen.

Waarom hebben we softwaretesten nodig?

Soms is het belangrijk om eraan herinnerd te worden waarom wat je doet ertoe doet. Het simpele feit is dat elk softwareonderdeel dat ooit is ontwikkeld en succesvol is geworden, dat heeft gedaan met de hulp van softwaretesters die onvermoeibaar werkten om ervoor te zorgen dat het product aan een zo hoog mogelijke standaard voldeed. Hier zijn drie redenen waarom softwaretesten belangrijk is. 

  1. Klanttevredenheid: Tijdens het ontwikkelen van een project kun je gemakkelijk verdwalen in het woud van code en vergeten dat de gebruiker ook tevreden moet zijn over de manier waarop de software werkt. QA-analisten en andere QA-medewerkers vervullen die rol. 
  2. Productkwaliteit: Elk beroep waarin een team of individu iets vanaf nul creëert, heeft een ander team nodig om hun fouten op te sporen. Schrijvers hebben redacteuren nodig. Filmregisseurs hebben ook redacteuren nodig. Softwareontwikkelaars hebben geen redacteuren nodig, maar wel een QA-team dat een objectief standpunt biedt en eventuele fouten opspoort. 
  3. Beveiliging: Met elke dag die voorbijgaat, lijkt dit punt steeds belangrijker te worden. Klanten willen de geruststelling dat de informatie die ze in de software invoeren en het werk dat ze erin doen privé blijft. Een onderdeel van QA is ervoor zorgen dat klanten dat vertrouwen hebben. 

Methodologieën voor softwaretesten

Elk type softwaretesttechniek dat in dit artikel wordt genoemd, behoort tot een van twee hoofdcategorieën: statisch testen en dynamisch testen. Voordat we de specifieke details van de negen verschillende softwaretesttechnieken bespreken, leg ik het verschil tussen deze twee methodologieën uit en op welk punt in de softwareontwikkelingscyclus ze een rol spelen. 

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

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 functionele software. Dat klopt, de software kan al worden gedebugd voordat deze ook maar in de buurt van voltooiing is. Zie je hoe dat van pas kan komen? 

Statische tests worden op twee manieren uitgevoerd:

  • Handmatige controles: De 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 voldoet aan de verificatiespecificaties.
  • Een manier om de grondoorzaak van bugs vast te stellen.

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

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

In de meeste gevallen zijn statische testbeoordelingen nuttig, omdat het hele QA-team het product zal analyseren en wijzigingen zal voorstellen op basis van problemen die ze zien en problemen die ze verwachten. Naast het voordeel dat er een grote verscheidenheid aan stemmen 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:

  • Zich aan het begin van het ontwikkelingsproces bevindt.
  • 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 regular tech leadership wisdom for delivering better software and systems.

Dynamisch testen

In tegenstelling tot statisch testen is dynamisch testen een vorm van softwaretesten waarbij code moet worden uitgevoerd. 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 uitvoeren in een praktijksituatie. Het is een uitstekende 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.

Doorgaans zijn er vier stappen betrokken bij het dynamisch testen van systeemsoftware die QA-analisten moeten kennen:

  • Unittesten: Wanneer software wordt onderworpen aan unittesten, wordt deze opgesplitst in de kleinst mogelijke componenten en afzonderlijk getest. Door op deze manier te testen, kunnen QA-analisten erop vertrouwen dat elk afzonderlijk onderdeel van de software werkt zoals bedoeld. En als er een bug wordt gevonden, is deze in deze ontwikkelingsfase 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 is opgesplitst in componenten en via unittesten is getest, wordt de software samengevoegd tot groepen en opnieuw getest. Als unittesten ervoor zorgen dat elk afzonderlijk onderdeel goed werkt, zorgt 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, het stuur) afzonderlijk getest. Vervolgens wordt de auto als geheel geassembleerd en getest, om er zeker van te zijn dat het gaspedaal goed met de motor communiceert (en dat de remmen dat ook doen!). Wil je zorgen voor een naadloze integratie tussen modules? Onze aanbevolen tools voor softwaretesten 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 wordt gedaan om ervoor te zorgen 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: verificatietesten versus validatietesten 

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.

Op vergelijkbare wijze hebben validatietesten alle belangrijke kenmerken van dynamisch testen. Een verificatietest is gericht op het bevestigen dat de software van hoge kwaliteit is, en dat is precies waar de systeem- en acceptatietests zich op richten.

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

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

  1. Zwarte-doostesten
  2. Witte-doostesten
  3. Grijze-doostesten 
  4. Geautomatiseerd testen 
  5. Unittesten
  6. Regressietesten
  7. Verkennend testen
  8. Functioneel testen
  9. Gebruiksvriendelijkheidstesten

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 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 die met een zwarte doos werkt, is het publiek: hij weet wat het ding (of dat nu een koffer of systeemsoftware is) hoort te doen, maar niet waaruit het is opgebouwd.

Foto van testen met een zwarte doos, typen softwaretests

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 te controleren of ze werken zoals verwacht. De reden voor testen met een zwarte doos is dat de tester de software, zonder diepgaande kennis van het ontwerp ervan, benadert met verwachtingen die vergelijkbaar zijn met die van de eindgebruiker. 

Enkele voordelen van testen met een zwarte doos zijn:

  • Testers hebben niet veel kennis van programmeertalen nodig, omdat ze de software gebruiken vanuit het perspectief van een gebruiker.
  • 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 maar heel 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 testen met een witte doos begrijpt het QA-lid de interne structuur en het ontwerp van de geteste software volledig. De tester benadert de test als een inspecteur en controleert of elk onderdeel van het programma goed werkt. Testen met een witte doos worden soms testen met een doorzichtige 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 die met een witte doos werkt zich veel minder bezig met de gebruikerservaring. 

Enkele voordelen van 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 die met een witte doos werkt het personage van Tim Roth, die rechtstreeks kijkt naar wat er in de koffer zit. 

3. Testen met een grijze doos

Bij testen met een grijze doos heeft de tester enige kennis van de interne structuur en het ontwerp van de software (witte doos), maar wordt er nog steeds getest vanuit het perspectief van een eindgebruiker (zwarte doos). Zo ontstond testen met een grijze doos. Bij 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 die met een grijze doos werkt 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 goed werkt. Geautomatiseerde tests nemen dergelijke zaken namens de testers voor hun rekening. Hier volgt een korte lijst met geautomatiseerde software- en QA-hulpmiddelen die QA-analisten moeten kennen:

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

5. Unittesten

Tools voor unit testing zorgen ervoor dat elk afzonderlijk onderdeel van de software goed werkt. Het is uiterst belangrijk om ervoor te zorgen dat unit testing goed wordt uitgevoerd, anders krijgt het ontwikkelingsteam te maken met een grote tegenslag 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 ervoor te zorgen 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 een heel ander punt, punt D, heeft stukgemaakt. 

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

7. Verkennend testen

Verkennend testen is testen voor mensen die niet van plannen houden. In de meeste andere situaties wordt de testcase grondig gepland voordat deze 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 kan aanpassen aan de bevindingen, zonder dat er een nieuwe testcase hoeft te worden geschreven. Verkennend testen maakt ook samenwerking, het uitwerken van theorieën en gezamenlijk onderzoek mogelijk, allemaal direct tijdens het testen.

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

Let op: verkennend testen kan veel creativiteit vereisen. 

8. Functioneel testen

Functioneel testen wordt uitgevoerd om ervoor te zorgen dat de systeemsoftware voldoet aan de projectvereisten die vóór de start van de ontwikkeling zijn opgesteld.

De softwaretester controleert of de invoer overeenkomt met de verwachte uitvoer. Dit gebeurt tijdens een van de laatste testfasen, hetzij tijdens systeemtests, hetzij tijdens acceptatietests, en het is uitsluitend een vorm van black-boxtesten, omdat het niet gaat om de manier waarop de software werkt, zolang deze maar werkt. 

9. Bruikbaarheidstesten

Testers van de bruikbaarheid zorgen ervoor dat ontwerpkeuzes zowel functioneel als intuïtief zijn.

Als je voorspelt dat veel gebruikers van je software hun documenten elk half uur willen back-uppen, kun je de back-upfunctie het beste op een gemakkelijk toegankelijke plek plaatsen in plaats van deze te verbergen achter vier submenu's. 

In veel gevallen is er software ontwikkeld die foutloos werkt en in een belangrijke marktbehoefte voorziet, maar vanuit het perspectief van de gebruiker volledig onmogelijk te navigeren is. Dit kan worden verklaard door een gebrek aan bruikbaarheidstesten tijdens de softwaretestfase.

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

Meer weten?

De softwaretestsector 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, toolreviews en meer overzichten van bronnen.