Een webapplicatie testen betekent controleren of je software doet wat ze moet doen, voor elke gebruiker, op elk apparaat en ook nadat er iets is aangepast. Dat gebeurt in lagen: ontwikkelaars testen de code automatisch, en jij als opdrachtgever controleert in een acceptatietest of de applicatie aansluit op je werk. Goed testen voorkomt dat fouten bij je klanten of medewerkers terechtkomen.
Testen klinkt als iets wat je aan het eind van een project doet. In de praktijk werkt dat niet. Hoe later je een fout ontdekt, hoe meer werk het kost om hem te herstellen. Daarom loopt testen bij een goed ontwikkelproces van begin tot eind mee.
Waarom een webapplicatie testen zo belangrijk is
Een webapplicatie is zelden af. Er komen nieuwe functionaliteiten bij, koppelingen met andere systemen veranderen en de onderliggende software krijgt updates. Elke wijziging kan iets kapotmaken wat eerder wel werkte, ook op een plek waar niemand aan heeft gezeten.
Zonder goed testproces merk je dat pas als een gebruiker belt. Een klant kan zijn order niet afronden, een factuur bevat een verkeerd bedrag of een medewerker ziet gegevens die niet voor hem bedoeld zijn. Dat kost niet alleen tijd om op te lossen, maar ook vertrouwen.
Grondig testen levert je drie dingen op:
- Minder fouten in productie. Eventuele fouten worden gevonden voordat gebruikers ze tegenkomen.
- Sneller kunnen veranderen. Met een goede set automatische tests durf je wijzigingen door te voeren zonder angst voor onverwachte bijwerkingen.
- Grip op kwaliteit. Je weet wat er getest is en wat niet, in plaats van hopen dat het goed gaat.
Soorten testen: van unit test tot acceptatietest
Er bestaan veel soorten testen. Voor een opdrachtgever is het genoeg om de belangrijkste te kennen en te weten wie ze uitvoert. Grofweg zijn er functionele testen (doet de software het juiste?) en niet-functionele testen (doet ze dat snel, veilig en voor iedereen bruikbaar?).
Functioneel testen: werkt het zoals bedoeld?
Unit testen. Een unit test controleert één klein stukje code, zoals de berekening van een korting of de validatie van een e-mailadres. Ontwikkelaars schrijven er honderden of duizenden van. Ze draaien in seconden en geven direct aan waar een fout zit. Bij test driven development schrijft de ontwikkelaar de test zelfs vóór de code.
Integratietesten. Hier test je of onderdelen goed samenwerken: de applicatie met de database, of je webapplicatie met een externe API, zoals een boekhoudpakket of betaalprovider. API testen valt hieronder. Je controleert of de juiste data wordt verstuurd en of de output klopt, en wat er gebeurt als de andere kant een foutmelding geeft (exception handling).
End-to-end testen. Een end-to-end test simuleert een echte gebruiker in de browser: inloggen, een formulier invullen, op opslaan klikken en controleren of het resultaat op het scherm verschijnt. Bekende testtools hiervoor zijn onder meer Playwright, Cypress en Selenium. Deze testen zijn trager, maar controleren de hele keten.
Acceptatietesten. In een acceptatietest controleren de opdrachtgever en gebruikers of de software doet wat is afgesproken en past bij de dagelijkse praktijk. Dit is de test waar jij zelf aan de slag gaat. Verderop lees je hoe je dat aanpakt.
Niet-functionele testen: snel, veilig en toegankelijk
Performance testen. Hoe gedraagt de applicatie zich als honderd gebruikers tegelijk inloggen, of als een tabel tienduizenden regels bevat? Met een loadtest simuleer je drukte, zodat je knelpunten vindt voordat je gebruikers ze voelen.
Securitytesten. Hier zoek je naar kwetsbaarheden, zoals de bekende risico’s uit de OWASP Top 10: verkeerd ingestelde toegangsrechten, onveilige invoer of verouderde onderdelen. Dat kan met automatische scanners in de ontwikkelstraat en, bij gevoelige applicaties, met een pentest door een specialist. Meer hierover lees je in ons artikel over beveiliging van een webapplicatie.
Toegankelijkheid testen. Kan iemand met een visuele beperking, of iemand die alleen een toetsenbord gebruikt, je applicatie bedienen? De internationale standaard hiervoor is WCAG; per oktober 2026 is WCAG 2.2 de meest recente versie die door W3C als aanbeveling is vastgesteld. Een deel controleer je automatisch, maar een handmatige check met toetsenbord en schermlezer blijft nodig.
Gebruikerstest. Een gebruikerstest draait niet om fouten maar om gebruikerservaring: begrijpen mensen hoe het werkt? Je laat een paar gebruikers een taak uitvoeren en kijkt mee waar ze vastlopen. Dat doe je bij voorkeur al met een klikbaar prototype, ver voor de eerste regel code.
| Testsoort | Wat het controleert | Wie | Automatisch of handmatig |
|---|---|---|---|
| Unit test | Kleine stukjes code | Ontwikkelaars | Automatisch |
| Integratietest | Samenwerking tussen onderdelen en API’s | Ontwikkelaars | Automatisch |
| End-to-end test | Complete gebruikersflows in de browser | Ontwikkelaars of tester | Automatisch |
| Acceptatietest | Past het bij het werk en de afspraken? | Opdrachtgever en gebruikers | Handmatig |
| Performance test | Snelheid onder belasting | Ontwikkelaars | Automatisch |
| Securitytest | Kwetsbaarheden | Ontwikkelaars of specialist | Beide |
| Toegankelijkheidstest | Bruikbaar voor iedereen | Ontwikkelaars of tester | Beide |
Handmatig testen of automatisch testen?
Het antwoord is: allebei, voor verschillende doelen.
Handmatig testen is sterk waar menselijk oordeel nodig is. Klopt dit scherm met hoe wij werken? Is deze melding begrijpelijk? Voelt de flow logisch? Een tester kijkt anders naar software dan een machine en vindt fouten waar niemand een test voor had bedacht.
Automatisch testen is sterk in herhaling. Een computer controleert elke keer opnieuw honderden scenario’s, zonder moe te worden en zonder iets over te slaan. Dat is precies wat je nodig hebt bij een regressietest: de controle of bestaande functies nog werken nadat er iets is aangepast. Dat handmatig doen wordt bij elke release meer werk, en dus wordt het vroeg of laat overgeslagen.
Vuistregel: automatiseer wat vaak terugkomt en bedrijfskritisch is, en test handmatig wat om oordeel en gevoel vraagt.
Geautomatiseerd testen in de ontwikkelstraat
Automatische tests hebben pas echt waarde als ze altijd draaien, niet alleen als een ontwikkelaar eraan denkt. Daarom horen ze in de ontwikkelstraat, ook wel CI genoemd (continuous integration).
Zo werkt dat in de praktijk:
- Een ontwikkelaar maakt een wijziging en zet die klaar in het versiebeheer.
- De ontwikkelstraat start automatisch en draait alle unit tests, integratietests en vaak ook end-to-end tests.
- Daarnaast draaien automatische controles op codekwaliteit en bekende kwetsbaarheden in gebruikte pakketten.
- Als een test faalt, wordt de wijziging tegengehouden. Pas als alles groen is, kan de wijziging door naar de testomgeving.
Het voordeel: fouten worden binnen minuten gevonden, door de ontwikkelaar die ze net heeft gemaakt en de code nog vers in zijn hoofd heeft. Dat is veel goedkoper dan een fout die weken later door een gebruiker wordt gemeld.
Let wel: een groene ontwikkelstraat betekent niet dat de software foutloos is. Het betekent dat alles wat je hebt bedacht te testen, werkt. Daarom blijft de acceptatietest door mensen nodig.
Testomgeving, staging en productie
Testen doe je nooit in de live applicatie. Een volwassen webapplicatie heeft daarom meerdere omgevingen:
- Ontwikkelomgeving: op de computer van de ontwikkelaar, voor het bouwen en de eerste checks.
- Testomgeving of staging: een kopie van productie, met dezelfde instellingen en techniek, waar nieuwe functies worden getest en waar jij de acceptatietest doet.
- Productieomgeving: de live applicatie met echte gebruikers en echte data.
Een goede staging-omgeving lijkt zoveel mogelijk op productie. Draait staging op een andere PHP-versie of mist er een koppeling, dan test je iets anders dan wat je live zet. Let ook op testdata: gebruik bij voorkeur geanonimiseerde of verzonnen gegevens, zeker als het om persoonsgegevens gaat. Koppelingen met externe systemen, zoals betalingen of e-mail, zet je in de testomgeving op een testaccount, zodat er geen echte facturen of mails de deur uit gaan.
Wat test je als opdrachtgever zelf? De acceptatietest
Ontwikkelaars kunnen controleren of de code doet wat in de specificatie staat. Of die specificatie past bij hoe jouw organisatie werkt, weet alleen jij. Daarom is de acceptatietest jouw verantwoordelijkheid, en een van de belangrijkste momenten in het project.
Zo bereid je een acceptatietest voor
Maak een testplan. Schrijf op welke scenario’s je wilt testen. Begin bij je belangrijkste bedrijfsprocessen: wat moet altijd werken? Een goed scenario beschrijft een complete taak, zoals “een nieuwe klant aanmaken, een offerte versturen en die omzetten naar een order”.
Test ook wat er mis kan gaan. Wat gebeurt er als iemand een verplicht veld leeg laat, een verkeerd e-mailadres invult of halverwege afhaakt? Juist daar zitten vaak de fouten.
Betrek echte gebruikers. De medewerker die het werk elke dag doet, ziet dingen die een manager mist. Laat ook gebruikers met verschillende rollen en rechten testen: ziet iedereen alleen wat hij mag zien?
Test op de apparaten die je gebruikers hebben. Werkt je buitendienst op een telefoon of tablet, test dan ook daar.
Bevindingen melden
Een goede bevinding is reproduceerbaar. Noteer:
- wat je deed, stap voor stap;
- wat je verwachtte;
- wat er gebeurde;
- een schermafbeelding, de browser en het apparaat.
Maak daarbij onderscheid tussen een fout (het werkt niet zoals afgesproken) en een wens (het werkt zoals afgesproken, maar je wilt het anders). Beide zijn waardevol, maar een wens gaat naar de lijst voor doorontwikkeling en houdt de livegang niet tegen.
Software testen bij een bestaande applicatie
Neem je een applicatie over of draait je software al jaren, dan is de kans groot dat er weinig of geen automatische tests zijn. Dat is een vorm van technische schuld: elke wijziging wordt spannender en duurder. Lees meer in ons artikel over technische schuld.
Het is zelden verstandig om in één keer voor de hele applicatie tests te schrijven. Begin bij de onderdelen met het meeste risico: de processen waar geld, klantgegevens of je belangrijkste bedrijfsprocessen aan hangen. Leg eerst met end-to-end tests vast hoe die nu werken. Zo heb je een vangnet voordat je gaat upgraden of verbouwen, en bouw je de testdekking stap voor stap op bij elke wijziging.
Hoe wij dit aanpakken
Bij Inesta loopt testen mee door het hele project. We werken in sprints van twee weken met aan het eind een demo van een werkende versie. Rond de kritieke processen schrijven we automatische tests, en voor de livegang test jouw team in een acceptatieperiode met realistische data. Pas als het werkt, gaat het live. Na de livegang blijft die testset je vangnet bij elke nieuwe functie.
Benieuwd hoe testen past in het hele traject? Lees hoe wij een webapplicatie ontwikkelen, van idee tot livegang. Heb je een project in gedachten, vertel het ons: je krijgt binnen één werkdag reactie.