Wat is software testen (QA)?

Definitie: Software testen is het systematisch controleren of software doet wat ervan wordt verwacht, zodat fouten worden gevonden voordat gebruikers ze tegenkomen. Het omvat handmatige en geautomatiseerde tests op verschillende niveaus, van losse functies tot de complete applicatie, en valt onder kwaliteitsborging, in het Engels quality assurance (QA).

In het kort

• Software testen bestaat uit vier gangbare niveaus: unittests, integratietests, systeemtests en acceptatietests.
• Functionele tests controleren of iets werkt zoals bedoeld; niet-functionele tests kijken naar snelheid, beveiliging, bruikbaarheid en compatibiliteit.
• Geautomatiseerde tests zijn sneller en betrouwbaarder bij herhaling, handmatig testen blijft nodig voor gebruiksgemak en onverwachte situaties.
• Hoe eerder een fout wordt gevonden, hoe minder het kost om hem op te lossen.

Wat is software testen?

Elke wijziging in software kan iets kapotmaken, ook op een plek waar niemand aan heeft gewerkt. Software testen is de verzameling activiteiten waarmee je controleert of een applicatie correct werkt: rekent de berekening goed, ziet een klant alleen zijn eigen gegevens, werkt het formulier op een telefoon, en blijft alles snel als er veel gebruikers tegelijk zijn?

Testen is meer dan aan het eind even doorklikken. Het begint bij de eisen: als niet duidelijk is wat de software moet doen, kun je ook niet controleren of dat lukt. Daarom horen testen en afspraken over gewenst gedrag bij elkaar, vanaf de eerste versie.

Guru99 noemt een paar bekende voorbeelden van wat er misgaat zonder goede tests. In april 2015 viel de Bloomberg Terminal uit, waardoor meer dan 300.000 handelaren werden getroffen en een verkoop van staatsschuld ter waarde van 3 miljard pond werd uitgesteld. In april 1999 kostte een mislukte militaire satellietlancering 1,2 miljard dollar. De meeste fouten in bedrijfssoftware zijn kleiner, maar leiden wel tot verkeerde facturen, verloren gegevens of gefrustreerde gebruikers.

Wat betekent QA?

QA staat voor quality assurance, kwaliteitsborging. Het is breder dan testen alleen. QA gaat over het hele proces dat zorgt voor goede software: heldere eisen, code reviews, afspraken over hoe er wordt gewerkt, tests en controle na livegang. Testen is het onderdeel waarin je daadwerkelijk controleert of de software werkt. In de praktijk worden de termen vaak door elkaar gebruikt, en een QA-tester of QA-engineer is iemand die zich specialiseert in testen.

Welke testniveaus zijn er?

TheCTOClub noemt bij acceptatietesten ook alfa- en bètatesten: eerst intern, daarna met een beperkte groep echte gebruikers. Atlassian merkt op dat unittests goedkoop te automatiseren en snel uit te voeren zijn, en dat integratietests duurder zijn omdat meerdere onderdelen tegelijk moeten draaien.

Welke soorten tests zijn er?

Guru99 spreekt van meer dan 150 soorten tests, maar niet elk type past bij elk project. De belangrijkste:

Functionele tests

• Functionele test. Volgens Atlassian controleert die of de uitkomst van een actie voldoet aan de zakelijke eisen.
• End-to-end-test. Bootst gebruikersgedrag na in een complete omgeving, zoals inloggen, bestellen en betalen.
• Regressietest. Controleert of bestaande functies nog werken na een wijziging.
• Smoketest. Een snelle controle of de belangrijkste functies werken na een nieuwe versie.

Niet-functionele tests

• Prestatietest. Hoe snel reageert de applicatie bij normaal gebruik?
• Belasting- en stresstest. Wat gebeurt er bij veel gelijktijdige gebruikers, of meer dan verwacht?
• Beveiligingstest. Kunnen gebruikers bij gegevens die niet voor hen bedoeld zijn? Een pentest simuleert een echte aanval.
• Bruikbaarheidstest. Begrijpen gebruikers hoe het werkt, zonder uitleg?
• Toegankelijkheidstest. Is de applicatie bruikbaar voor mensen met een beperking?
• Compatibiliteitstest. Werkt het in verschillende browsers en op verschillende apparaten?

Handmatig of geautomatiseerd testen?

Volgens Atlassian zijn handmatige tests kostbaar en foutgevoelig, en zijn geautomatiseerde tests robuuster en betrouwbaarder. AppMaster wijst erop dat automatisering een hogere investering vooraf vraagt. ClickUp noemt als voordeel dat testers door automatisering tijd overhouden voor verkennend testen en bruikbaarheid. In de praktijk combineer je beide.

De testpiramide

Een veelgebruikt model is de testpiramide. Onderaan staan veel snelle, goedkope unittests. In het midden staan minder integratietests. Bovenaan staan een paar end-to-end-tests, die de belangrijkste routes van de gebruiker controleren. Atlassian adviseert om end-to-end-tests te beperken tot een paar belangrijke, omdat ze duur en lastig te onderhouden zijn. Zo krijg je snelle feedback bij elke wijziging, zonder een testset die zelf een onderhoudsprobleem wordt.

Black box en white box

Testen kan met of zonder kennis van de code. Bij black box-testen kijkt de tester alleen naar invoer en uitvoer, zoals een gebruiker. Bij white box-testen kijkt de tester ook naar de interne opbouw. ClickUp noemt daarnaast grey box-testen, met gedeeltelijke kennis. TheCTOClub noemt voor black box onder meer grenswaardeanalyse: je test precies op en rond de grenzen, zoals 0, 1 en het maximum, omdat daar vaak fouten zitten.

AppMaster maakt nog een onderscheid tussen statisch en dynamisch testen. Statisch testen onderzoekt code en documentatie zonder de software uit te voeren, bijvoorbeeld met code reviews of tools als SonarQube. Dynamisch testen voert de software wel uit.

Hoe verloopt het testproces?

TheCTOClub beschrijft zes fasen:

1. Eisen analyseren. Wat moet de software doen, en wat is testbaar?
2. Testplan maken. Wat test je, hoe, met welke middelen en wanneer?
3. Testgevallen ontwerpen. Concrete situaties met invoer en verwachte uitkomst.
4. Tests uitvoeren. Handmatig of geautomatiseerd, met registratie van gevonden fouten.
5. Rapporteren. Wat is getest, wat werkt, wat niet en hoe ernstig is het?
6. Afsluiten. Evalueren en vastleggen wat je meeneemt naar de volgende versie.

Bij kleinere projecten is dat lichter, maar de vragen blijven dezelfde.

Een voorbeeld: een berekening testen

Stel dat een webapplicatie een capaciteit berekent op basis van een paar invoervelden. Goede tests kijken naar:

• De standaardsituatie. Gangbare invoer met een bekende, handmatig nagerekende uitkomst.
• Grenzen. De kleinste en grootste toegestane waarde, en net daarbuiten.
• Foutieve invoer. Een leeg veld, tekst in plaats van een getal, een negatieve waarde.
• Afronding. Wordt op de juiste manier en op het juiste moment afgerond?
• Uitvoer. Klopt de uitkomst ook in de printversie of PDF?

Zulke tests zijn ideaal om te automatiseren. Als de formule later verandert, zie je direct of de bekende uitkomsten nog kloppen.

Wat is een goede testcase?

Een testcase beschrijft één situatie die je controleert. Een goede testcase heeft vier onderdelen:

1. Uitgangssituatie. Welke gebruiker, met welke rol en welke gegevens?
2. Handeling. Wat doet de gebruiker precies, stap voor stap?
3. Verwachte uitkomst. Wat moet er gebeuren, zo concreet mogelijk?
4. Werkelijke uitkomst. Wat gebeurde er, en klopt dat met de verwachting?

Een voorbeeld: een klant met twee openstaande facturen logt in en opent het factuuroverzicht. Verwacht: precies die twee facturen, met juist bedrag en vervaldatum, en geen facturen van andere klanten. Zo’n beschrijving kan iedereen uitvoeren, ook iemand die de software niet heeft gebouwd.

Waarom testen kosten bespaart

Hoe later een fout wordt ontdekt, hoe duurder het oplossen. AppMaster en ClickUp noemen het vroeg vinden van fouten als belangrijke reden om te testen. Een fout die een ontwikkelaar binnen een minuut ziet door een falende unittest, is snel opgelost. Dezelfde fout die maanden later bij een klant opduikt, kost tijd voor uitzoeken, herstellen, gegevens corrigeren en uitleggen. TheCTOClub noemt het ISTQB-principe dat ongeveer 80 procent van de fouten in 20 procent van de onderdelen zit. Testinspanning op de belangrijkste en complexste delen loont dus het meest.

Waar wordt getest: testomgevingen

Testen gebeurt bij voorkeur niet in de live omgeving waar klanten werken. Gangbaar is een opbouw met drie omgevingen:

• Ontwikkelomgeving. Op de computer van de ontwikkelaar, voor unittests en snelle controles.
• Test- of acceptatieomgeving. Een kopie van de live omgeving, met testgegevens, waar de opdrachtgever nieuwe functies kan beoordelen.
• Productie. De live omgeving waar gebruikers mee werken.

Let bij een testomgeving op de gegevens. Een kopie van echte klantgegevens is handig om realistisch te testen, maar valt onder de AVG. Gebruik daarom bij voorkeur geanonimiseerde of zelfgemaakte testgegevens die wel alle situaties bevatten: lege velden, lange namen, bijzondere tekens en klanten met veel en weinig gegevens.

Testen en AI-gegenereerde code

Steeds meer code wordt geschreven met hulp van AI-tools. Die code ziet er vaak goed uit, maar kan fouten bevatten die bij een snelle blik niet opvallen, zoals een vergeten rechtencontrole of een randgeval dat niet is afgevangen. Geautomatiseerde tests worden daardoor belangrijker, niet minder belangrijk. Ze zijn een vangnet dat bij elke wijziging controleert of bestaande functies nog werken, ongeacht wie of wat de code heeft geschreven. AI kan ook helpen om tests te schrijven, maar ook die tests verdienen een kritische blik: test de test echt het juiste gedrag?

Veelgemaakte fouten bij testen

• Alleen het goede pad testen. De meeste fouten zitten in uitzonderingen, lege invoer en onverwachte volgordes.
• Testen uitstellen tot het eind. Dan zijn fouten duurder om op te lossen en ontbreekt vaak de tijd.
• Geen vaste testgevallen. Zonder vastgelegde scenario’s test iedereen iets anders, en worden dezelfde fouten opnieuw gemist.
• Alleen als beheerder testen. Een beheerder ziet alles, dus rechtenproblemen vallen dan niet op.
• Tests niet onderhouden. Geautomatiseerde tests die niemand bijwerkt, gaan falen en worden genegeerd.
• Alleen op één apparaat testen. Wat op een groot scherm werkt, kan op een telefoon onbruikbaar zijn.

Waar let je op als opdrachtgever?

• Vraag welke tests er zijn. Zijn er geautomatiseerde tests, en draaien die bij elke wijziging?
• Spreek een acceptatietest af. Wie test namens jouw organisatie, met welke scenario’s en wanneer?
• Test met echte situaties. Gebruik voorbeelden uit de praktijk, inclusief uitzonderingen.
• Controleer rechten. Laat testen met accounts uit elke rol, zodat niemand ziet wat niet voor hem bedoeld is.
• Leg vast wat af betekent. Acceptatiecriteria per functie voorkomen discussie achteraf.
• Blijf testen na livegang. Elke update vraagt om een regressietest.

Wat betekent dit voor jouw project?

Bij de calculators van Capaciteitberekenen.nl, voor onder meer olie- en vetafscheiders en infiltratie, zie je waarom testen ertoe doet. De route is invoer, berekening, resultaat en print of PDF. De les die ik daaruit haal: maak de invoer begrijpelijk en de uitkomst bruikbaar, en leg vast welke aannames en grenzen gelden. Gerichte controles onderbouwen daar specifieke onderdelen; dat is iets anders dan een algemene certificering, en dat onderscheid wil ik eerlijk benoemen.

Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Dat geldt ook voor testen: welke situaties moeten werken, en hoe controleren we dat samen voordat iemand er dagelijks mee werkt?

Vraag? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe ik een webapplicatie ontwikkel.

Veelgestelde vragen over software testen

Wat is software testen?

Software testen is het systematisch controleren of software doet wat ervan wordt verwacht, zodat fouten worden gevonden voordat gebruikers ze tegenkomen. Het gebeurt handmatig en geautomatiseerd, op niveaus van losse functies tot de complete applicatie.

Wat is het verschil tussen testen en QA?

QA, quality assurance, is kwaliteitsborging van het hele ontwikkelproces, inclusief eisen, code reviews en werkafspraken. Testen is het onderdeel waarin je daadwerkelijk controleert of de software werkt zoals bedoeld.

Welke soorten software testen zijn er?

De belangrijkste niveaus zijn unittests, integratietests, systeemtests en acceptatietests. Daarnaast zijn er niet-functionele tests, zoals prestatie-, beveiligings-, bruikbaarheids- en compatibiliteitstests.

Verwante termen

Unit test · Gebruikersacceptatietest · Pentest · CI/CD · Technische schuld · Functionele eisen