Een acceptatietest is een gestructureerde test waarbij de opdrachtgever of eindgebruiker verifieert of software voldoet aan de vooraf afgesproken functionele eisen. Anders dan technische tests die door ontwikkelaars worden uitgevoerd, staat bij de acceptatietest de vraag centraal: “Doet het systeem wat wij als klant nodig hebben?” Je voert een acceptatietest uit aan het einde van een ontwikkeltraject, voordat software officieel in gebruik wordt genomen. Typische toepassingen zijn de oplevering van een nieuw ERP-systeem, de lancering van een webapplicatie of de uitrol van een aangepaste module in een bestaand platform. Een geslaagde acceptatietest vormt de formele goedkeuring dat het project klaar is voor productie.
Soorten acceptatietests
Er bestaan verschillende vormen van acceptatietesten, elk met een eigen doel en uitvoerder. Het is belangrijk te weten welk type past bij jouw project en fase.
User Acceptance Testing (UAT)
User Acceptance Testing (UAT) is de meest bekende vorm. Eindgebruikers testen het systeem op basis van realistische werkscenario’s. Ze controleren of de software hun dagelijkse taken ondersteunt zoals verwacht. UAT vindt doorgaans plaats in een testomgeving die zo veel mogelijk lijkt op de productieomgeving.
Business Acceptance Testing (BAT)
Bij Business Acceptance Testing toetst de opdrachtgever of de software aansluit op de bedrijfsprocessen en zakelijke doelstellingen. Dit gaat verder dan het testen van individuele functies: het hele proces van begin tot eind wordt doorlopen. Denk aan een inkoopproces dat van aanvraag tot betaling wordt getest in het nieuwe systeem.
Operational Acceptance Testing (OAT)
Operational Acceptance Testing richt zich op de beheerbaarheid van het systeem. Systeembeheerders controleren of back-ups werken, of het systeem opstart na een stroomstoring en of monitoringtools correct functioneren. Dit type test wordt ook wel productie-acceptatietest of beheertest genoemd.
Alpha- en bètatesten
Alfa-testen vinden intern plaats, met medewerkers van de ontwikkelorganisatie als testgebruikers. Bètatesten verplaatsen de software naar een selecte groep echte gebruikers buiten de ontwikkelorganisatie. Beide vormen leveren waardevolle feedback op die nog verwerkt kan worden vóór de officiële lancering.
Het acceptatietest-proces stap voor stap
Een goede acceptatietest is geen eenmalige handeling maar een gestructureerd proces. Door de juiste stappen in de juiste volgorde te doorlopen, vergroot je de kans op een succesvolle oplevering.
Stap 1: Testplan opstellen
Bepaal vooraf wat je gaat testen, wie de tests uitvoert en welke criteria gelden voor slagen of zakken. Leg dit vast in een testplan. Het testplan beschrijft ook de testomgeving, de benodigde testdata en de planning.
Stap 2: Testscenario’s en testgevallen schrijven
Vertaal de functionele eisen naar concrete testscenario’s. Een testscenario beschrijft een gebruikssituatie: “Als inkoper voer ik een nieuwe bestelling in en controleer ik of de goedkeuringsflow correct verloopt.” Elk scenario bevat testgevallen met specifieke invoer, verwachte uitvoer en te controleren gedrag.
Stap 3: Tests uitvoeren
De testgebruikers doorlopen de testgevallen systematisch en leggen bevindingen vast. Bij afwijkingen van de verwachte uitkomst wordt een defect geregistreerd. Zorg dat bevindingen gedetailleerd worden gedocumenteerd, inclusief screenshots of stappen om het probleem te reproduceren.
Stap 4: Bevindingen beoordelen en verwerken
Niet elke bevinding is een blokkerende fout. Prioriteer defecten op ernst: een crash bij een kernfunctie is kritiek, een cosmetische fout in de lay-out is laagprioriteit. De ontwikkelaar verhelpt de kritieke defecten, waarna een hertestrondes volgt.
Stap 5: Formele goedkeuring
Als alle kritieke bevindingen zijn opgelost en de software voldoet aan de acceptatiecriteria, tekent de opdrachtgever het acceptatiedocument. Dit vormt het formele signaal dat de software klaar is voor productie. De handtekening markeert ook de overdracht van verantwoordelijkheid van de leverancier naar de opdrachtgever.
Acceptatiecriteria definiëren
Acceptatiecriteria zijn meetbare voorwaarden waaraan de software moet voldoen om te worden goedgekeurd. Ze worden idealiter opgesteld samen met alle betrokken partijen voordat de ontwikkeling begint. Vage criteria zoals “de software moet snel zijn” leiden tot discussies achteraf. Maak criteria SMART: “de zoekfunctie levert resultaten binnen twee seconden bij een dataset van 100.000 records.” Duidelijke criteria beschermen zowel de opdrachtgever als de leverancier en voorkomen scope-discussies aan het einde van een project.
Veelgemaakte fouten bij acceptatietesten
Acceptatietests mislukken niet alleen door slechte software. Organisatorische en communicatieve fouten zijn minstens zo vaak de oorzaak. Een te korte testperiode is een klassieke valkuil: testen kost tijd en haastig werk levert halve resultaten op. Betrek eindgebruikers vroeg in het project, zodat ze de verwachtingen hebben meegeholpen te vormen. Zorg ook voor realistische testdata: testen met vijf dummy-records geeft geen goed beeld van prestaties bij duizenden echte transacties. Ten slotte is het essentieel dat bevindingen centraal worden geregistreerd, zodat niets tussen wal en schip valt.
Conclusie
Een acceptatietest is de laatste en cruciale schakel in het softwareontwikkelproces die bepaalt of de opgeleverde software daadwerkelijk aansluit op de behoeften van de opdrachtgever. Door testscenario’s te baseren op realistische werkprocessen en acceptatiecriteria vooraf scherp te definiëren, voorkom je verrassingen bij de oplevering. De test beschermt zowel de opdrachtgever als de leverancier: beide partijen weten precies wat is afgesproken en wat er getest is. Een goed uitgevoerde acceptatietest vergroot het vertrouwen in de software en versnelt de ingebruikname in de organisatie. Wil je de kwaliteit van jouw software-opleveringen verhogen? Begin dan met het opstellen van concrete acceptatiecriteria bij de start van je volgende project.
Veelgestelde vragen
-
Wie voert een acceptatietest uit?
De acceptatietest wordt uitgevoerd door de opdrachtgever of de eindgebruikers, niet door de ontwikkelaars zelf. In de praktijk zijn dit medewerkers die het systeem dagelijks gaan gebruiken, aangevuld met een testcoördinator die het proces begeleidt. Het is van belang dat de testers de bedrijfsprocessen goed kennen.
-
Wat is het verschil tussen een acceptatietest en een systeemtest?
Een systeemtest wordt uitgevoerd door het testteam van de leverancier en richt zich op technisch correcte werking van het complete systeem. Een acceptatietest wordt uitgevoerd door de opdrachtgever en richt zich op de vraag of de software de bedrijfsdoelen ondersteunt. De systeemtest gaat aan de acceptatietest vooraf.
-
Wat gebeurt er als de software de acceptatietest niet doorstaat?
De leverancier verhelpt de geconstateerde kritieke defecten en biedt de software opnieuw aan voor acceptatie. Afhankelijk van de contractafspraken kan dit gevolgen hebben voor de opleverdatum of de kosten. Een duidelijke afspraak over hertest-procedures voorkomt discussie in deze situatie.
-
Hoe lang duurt een acceptatietest gemiddeld?
De duur varieert sterk afhankelijk van de complexiteit van het systeem en het aantal testscenario’s. Voor een eenvoudige webapplicatie kan een acceptatietest twee tot vijf dagen duren. Voor complexe bedrijfssystemen kan dit oplopen tot meerdere weken of zelfs maanden.
-
Kan een acceptatietest worden geautomatiseerd?
Gedeeltelijk wel. Tools zoals Cucumber of Robot Framework maken het mogelijk om acceptatiecriteria in begrijpelijke taal te schrijven en automatisch uit te voeren. Volledige automatisering is echter lastig, omdat gebruikerservaring en zakelijk oordeel niet volledig te automatiseren zijn. Een combinatie van geautomatiseerde en handmatige tests geeft het beste resultaat.