Definitie: Een gebruikersacceptatietest (UAT, user acceptance test) is de laatste testfase voordat software live gaat, waarin eindgebruikers of de opdrachtgever controleren of de software hun werk in de praktijk ondersteunt. De vraag is niet of de code technisch klopt, maar of de software doet wat het bedrijf nodig heeft.
In het kort
- UAT staat voor user acceptance testing; in het Nederlands spreek je van gebruikersacceptatietest of acceptatietest.
- De test wordt uitgevoerd door de mensen die de software gaan gebruiken, niet door de ontwikkelaars zelf.
- Je test aan de hand van scenario’s uit het echte werk, in een omgeving die zo veel mogelijk op de productieomgeving lijkt.
- De uitkomst is een formeel besluit: de software wordt geaccepteerd, of er moet eerst nog iets worden opgelost.
Wat is een gebruikersacceptatietest?
Een gebruikersacceptatietest is het moment waarop de opdrachtgever en de gebruikers zelf met de software aan de slag gaan, voordat die in gebruik wordt genomen. Ze doorlopen hun dagelijkse taken: een aanvraag invoeren, een offerte maken, een rapportage opvragen. Daarbij controleren ze of alles werkt zoals afgesproken en of het in de praktijk bruikbaar is.
Guru99 omschrijft UAT als een test die wordt uitgevoerd door de eindgebruiker of de klant om te bevestigen dat de software aan de bedrijfsbehoeften voldoet. Splunk noemt het de laatste fase van het testproces, waarin echte gebruikers nagaan of het systeem werkt in praktijksituaties.
UAT is een zogeheten blackboxtest. De tester kijkt niet naar de code, maar alleen naar wat de software doet: wat erin gaat en wat eruit komt.
Wat betekent UAT?
UAT is de afkorting van user acceptance testing, of user acceptance test. Acceptance verwijst naar de acceptatie van de software door de opdrachtgever: na een geslaagde test neemt de klant de software formeel af. In contracten en projectplannen heet dat moment vaak acceptatie, oplevering of sign-off.
Waar past UAT in het testproces?
Software wordt in verschillende lagen getest. UAT is de laatste laag.
| Testsoort | Wie test | Vraag |
|---|---|---|
| Unittest | Ontwikkelaar, vaak geautomatiseerd | Werkt dit kleine stukje code goed? |
| Integratietest | Ontwikkelaar of tester | Werken onderdelen en koppelingen samen? |
| Systeemtest | Tester of QA-team | Werkt het hele systeem volgens de specificaties? |
| Gebruikersacceptatietest | Eindgebruikers en opdrachtgever | Ondersteunt dit ons werk zoals bedoeld? |
Marker.io maakt het onderscheid met kwaliteitscontrole duidelijk: QA controleert of de software functioneel correct werkt, UAT controleert of de software de zakelijke behoeften ondersteunt. Software kan dus technisch foutloos zijn en toch niet door de UAT komen, bijvoorbeeld omdat een stap in het proces ontbreekt of omdat een scherm niet past bij hoe medewerkers werken.
Soorten acceptatietests
Splunk en Marker.io onderscheiden verschillende vormen:
| Soort | Wat het is |
|---|---|
| Alfatest | Intern, door het team en een kleine groep gebruikers, om grote fouten vroeg te vinden |
| Bètatest | Extern, met een beperkte groep echte gebruikers in een live omgeving |
| Contractuele acceptatietest | Controle of de afgesproken specificaties uit het contract zijn gehaald |
| Regelgevingstest | Controle op naleving van wet- en regelgeving, bijvoorbeeld in zorg of financiën |
| Operationele acceptatietest | Controle of het systeem klaar is voor dagelijks gebruik, beheer en onderhoud |
| Bedrijfsacceptatietest | Controle of de software de bedrijfsprocessen goed ondersteunt |
Bij een maatwerk applicatie voor een mkb-bedrijf valt het meestal samen in één test: de opdrachtgever en een paar gebruikers lopen de afgesproken scenario’s door en geven akkoord.
Wie voert de UAT uit?
De test wordt uitgevoerd door de mensen die het werk kennen. Splunk en BrowserStack noemen onder meer eindgebruikers, productowners, business analisten, vakinhoudelijke experts en klantvertegenwoordigers. Het ontwikkelteam is betrokken om vragen te beantwoorden en fouten op te lossen, maar test niet zelf namens de gebruiker.
Kies testers die het proces van dag tot dag kennen. Een directeur die de software heeft besteld, ziet andere dingen dan een medewerker die er straks acht uur per dag mee werkt. Een goede testgroep heeft beide.
Het UAT-proces in stappen
De stappen bij Guru99, Splunk en Marker.io komen grotendeels overeen:
- Scope en acceptatiecriteria vastleggen. Wat moet werken om de software te accepteren?
- Een testplan maken. Wie test wat, wanneer en hoe wordt feedback vastgelegd?
- Scenario’s en testgevallen opstellen op basis van echte bedrijfsprocessen.
- Testomgeving en testdata voorbereiden. Marker.io raadt een omgeving aan die de productie zo goed mogelijk spiegelt, met geanonimiseerde gegevens.
- Testers briefen. Leg uit wat het doel is en hoe ze bevindingen melden.
- Testen uitvoeren en bevindingen vastleggen, met schermafbeelding en beschrijving.
- Bevindingen prioriteren, oplossen en hertesten.
- Akkoord geven. Een formele sign-off sluit de test af.
Een voorbeeld van een testscenario
Een goed testscenario beschrijft een taak uit het echte werk, niet een losse knop. Bijvoorbeeld voor een applicatie waarin aanvragen worden behandeld:
| Onderdeel | Inhoud |
|---|---|
| Scenario | Een nieuwe aanvraag komt binnen en wordt goedgekeurd |
| Rol | Binnendienstmedewerker, daarna teamleider |
| Stappen | Aanvraag invoeren via het formulier, toewijzen aan teamleider, teamleider keurt goed |
| Verwacht resultaat | Aanvrager ontvangt een bevestiging, status staat op goedgekeurd, aanvraag verschijnt in het overzicht van de uitvoering |
| Uitkomst | Geslaagd, of beschrijving van wat afwijkt |
Zulke scenario’s zijn makkelijker te testen dan een lijst functies, omdat ze laten zien of de keten werkt.
Wanneer is de UAT geslaagd?
Vooraf leg je vast wanneer de test kan beginnen en wanneer hij klaar is. Guru99 noemt als startvoorwaarde dat er geen ernstige of kritieke fouten meer openstaan; alleen cosmetische fouten zijn dan nog acceptabel. Als eindvoorwaarde geldt dat er geen kritieke fouten meer zijn, dat het bedrijfsproces correct werkt en dat alle betrokken partijen akkoord geven.
Deel bevindingen daarom in naar ernst. Een fout die het proces blokkeert, moet worden opgelost. Een tekst die beter kan, kan op een lijst voor later. Marker.io adviseert om vooraf te bepalen welke bevindingen overleg vragen en welke direct kunnen worden aangepast.
Tools voor een acceptatietest
Een acceptatietest vraagt geen ingewikkelde software, maar wel een vaste plek voor bevindingen. Marker.io noemt feedbackwidgets die je op een testomgeving plaatst, zodat testers direct vanaf het scherm een melding maken met een schermafbeelding en technische gegevens. Voor het beheren van testgevallen en bevindingen worden tools als Jira en Trello gebruikt. Codecademy noemt daarnaast tools als Zephyr, Concordion, FitNesse en Watir. Voor een klein project volstaat vaak een gedeelde lijst met per bevinding een omschrijving, een schermafbeelding, de ernst en wie het oppakt.
Kun je een acceptatietest automatiseren?
Deels. Volgens Splunk kan automatisering herhaalbare stappen versnellen en de test consistenter maken, bijvoorbeeld door vaste scenario’s na elke wijziging opnieuw te laten draaien. Codecademy merkt op dat UAT meestal handmatig gebeurt. De kern van de test, het oordeel of de software bruikbaar is en past bij het werk, blijft mensenwerk. Een goede verdeling is dat geautomatiseerde tests de techniek bewaken, en dat gebruikers hun tijd besteden aan de vraag of het proces klopt.
UAT bij updates en nieuwe versies
Een acceptatietest is niet alleen iets voor de eerste oplevering. Codecademy noemt aanvullende acceptatietests bij gefaseerde releases, updates, upgrades en spoedreparaties. Bij een grote wijziging in een bestaand systeem is het verstandig om de belangrijkste scenario’s opnieuw door te lopen, ook de onderdelen die niet zijn aangepast. Een wijziging op de ene plek kan onverwacht effect hebben op een andere.
Tips voor testers
- Werk zoals op een normale werkdag. Gebruik echte situaties, ook de lastige.
- Beschrijf wat je verwachtte en wat er gebeurde. Dat maakt een bevinding begrijpelijk voor de ontwikkelaar.
- Voeg een schermafbeelding toe en vermeld met welk account en welke gegevens je werkte.
- Meld één ding per bevinding. Dan is het makkelijker te volgen en af te vinken.
- Scheid fouten van wensen. Beide zijn waardevol, maar ze horen op een andere lijst.
- Test ook met verschillende rollen. Log in als medewerker, als teamleider en als beheerder, en controleer dat iedereen precies ziet en kan wat bij zijn rol hoort.
- Neem de tijd. Plan vaste blokken in de agenda, zodat testen niet tussen ander werk door gebeurt.
Veelgemaakte fouten bij UAT
BrowserStack noemt een aantal terugkerende uitdagingen. Samen met andere valkuilen:
- Onduidelijke eisen. Zonder afgesproken criteria wordt de test een discussie over smaak.
- Te laat testen. Als gebruikers pas aan het eind voor het eerst iets zien, zijn wijzigingen duur.
- Een testomgeving die afwijkt van productie. Dan werkt het in de test wel en straks niet.
- Geen tijd voor testers. Gebruikers testen naast hun gewone werk; plan die tijd in.
- Nieuwe wensen als fout melden. Een wens is waardevol, maar hoort op de lijst voor een volgende versie, niet in de acceptatie.
- Alleen het ideale pad testen. Test ook wat er gebeurt bij een fout, een uitzondering of een ontbrekend gegeven.
Wat betekent dit voor jouw project?
Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Een acceptatietest is daar het logische vervolg op: je controleert of de afgesproken versie ook werkt zoals afgesproken. In mijn aanpak is dat het beslismoment na de eerste versie. De vraag is dan of de afgesproken route met gebruikers, rollen en koppelingen werkt in de afgesproken gebruikssituaties.
Daarom leg ik in een voorstel niet alleen functies vast, maar ook acceptatievoorbeelden: welke gebruiker welke taak moet kunnen afronden, met welke gegevens en welke uitkomst. Dat geeft een duidelijker toets dan een lange lijst losse functies. En het voorkomt dat de acceptatie verandert in een gesprek over wat er nog meer bij zou kunnen.
Vraag? Wil je software laten bouwen waarvan vooraf helder is wanneer die af is? 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 meer over een webapplicatie ontwikkelen.
Veelgestelde vragen over de gebruikersacceptatietest
Wat is de betekenis van UAT?
UAT staat voor user acceptance testing, in het Nederlands gebruikersacceptatietest. Het is de laatste testfase voordat software live gaat, waarin eindgebruikers of de opdrachtgever controleren of de software hun werk in de praktijk ondersteunt.
Wie voert een gebruikersacceptatietest uit?
Een gebruikersacceptatietest wordt uitgevoerd door de mensen die de software gaan gebruiken, zoals eindgebruikers, productowners en vakinhoudelijke experts. Het ontwikkelteam ondersteunt en lost fouten op, maar test niet namens de gebruiker.
Wat is het verschil tussen UAT en een systeemtest?
Een systeemtest controleert of de software technisch werkt volgens de specificaties en wordt meestal door testers of het ontwikkelteam gedaan. Een UAT controleert of de software het werk van de gebruikers in de praktijk ondersteunt en wordt door de gebruikers zelf uitgevoerd.
Verwante termen
Software testen · Unit test · Functionele eisen · Go-live · Programma van eisen · Prototype · Usability
← Terug naar de kennisbank