In het kort
Een acceptatietest controleert of software voldoet aan afgesproken behoeften en criteria voor ingebruikname. Laat toekomstige gebruikers echte werktaken uitvoeren met veilige testgegevens. Leg vooraf per test de beginsituatie, stappen en verwachte uitkomst vast. Noteer daarna het werkelijke resultaat en bespreek welke fouten ingebruikname blokkeren. Een geslaagde demonstratie of een hoog slagingspercentage is op zichzelf geen onderbouwd akkoord.
Wat is een acceptatietest en wie voert hem uit?
Bij een acceptatietest beoordeel je software vanuit de afgesproken toepassing in je bedrijf. Kan een planner een opdracht wijzigen, krijgt de juiste medewerker toegang en klopt het resultaat in het volgende systeem? ISTQB beschrijft acceptatietesten als een samenwerking tussen onder meer productverantwoordelijken, bedrijfsanalisten en testers. Gebruikersacceptatie, vaak UAT genoemd, is daar een vorm van. De mensen die het werk kennen, brengen de bedrijfsregels in; de leverancier helpt met een geschikte omgeving en onderzoek van fouten.
Een ontwikkelaar kan aantonen dat losse functies of koppelingen technisch werken. Daarmee is nog niet vastgesteld dat een medewerker de hele werktaak goed kan afronden. Gebruikerstests vullen dat technische bewijs aan. Spreek af wie test, wie bevindingen beoordeelt en wie namens de opdrachtgever over acceptatie beslist. Dat kunnen bij een klein bedrijf dezelfde mensen zijn, zolang de verantwoordelijkheden duidelijk zijn. Een acceptatietest bewijst ook niet dat software vrij is van alle fouten of beveiligingsproblemen.
1. Baken de versie, werktaken en testomgeving af
Begin met de versie die je werkelijk gaat beoordelen en de taken die daarin zijn afgesproken. Neem de scope en acceptatieafspraken uit de opdracht erbij. Wie nog leveranciersvoorstellen vergelijkt, kan eerst de gids voor het beoordelen van een maatwerk software offerte gebruiken. Tijdens de acceptatie wil je voorkomen dat een demonstratie ongemerkt over een andere versie, extra functie of kleinere gegevensset gaat dan de software die straks wordt opgeleverd.
Kies herkenbare taken, zoals een aanvraag verwerken, een order vrijgeven of een rapport exporteren. Vermeld per taak de betrokken rollen en systemen. Leg vast welke testaccounts, apparaten en browsers nodig zijn, welke koppelingen echt werken en welke worden nagebootst. Gebruik fictieve gegevens of zorgvuldig afgeschermde gegevens waarvoor gebruik is afgesproken. Zet berichten, betalingen en andere externe acties in een veilige teststand. Controleer vóór de proef of een testhandeling toch een echte klant kan bereiken.
Laat ook zien wat buiten deze test valt. Een gecontroleerde proef met enkele orders zegt weinig over gedrag bij veel gelijktijdige gebruikers. Een nagebootste boekhoudkoppeling bewijst niet dat de echte aansluiting werkt. Noteer zulke grenzen naast de uitkomsten. Plan ontbrekende controles apart in, met een verantwoordelijke, zodat een beperking niet als een geslaagd resultaat in de eindbeslissing terechtkomt.
2. Schrijf vooraf een controleerbare verwachte uitkomst
Een criterium als het systeem moet gebruiksvriendelijk zijn laat te veel interpretatie over. Beschrijf wat iemand onder welke omstandigheden moet kunnen doen en waaraan je ziet dat het gelukt is. Bijvoorbeeld: een planner wijzigt de toegewezen medewerker, waarna de nieuwe medewerker de opdracht ziet en de vorige medewerker geen wijzigingsrechten meer heeft. Controleer zowel het scherm als het opgeslagen resultaat. Alleen een groene melding is geen bewijs dat de juiste wijziging is bewaard.
Verbind elke belangrijke test aan een bedrijfsafspraak. In een CRM kan een verplichte opvolgdatum onderdeel zijn van de werkwijze; in een orderproces kan een vrijgavebevoegdheid doorslaggevend zijn. De CRM-eisen- en wensenlijst helpt zulke afspraken vooraf te ordenen. Maak daarbij onderscheid tussen noodzakelijke criteria en nuttige wensen. Zet een nieuwe wens die pas tijdens het testen ontstaat op een aparte lijst en bespreek de gevolgen voor scope en planning.
Wil je snelheid beoordelen, spreek dan een concrete taak, gegevensomvang, apparaat en meetwijze af. Meet bijvoorbeeld de tijd vanaf het aanvragen van een afgesproken rapport tot het moment waarop de inhoud bruikbaar is. Kies samen welke grens voor dat werk aanvaardbaar is. Een losse laadtijd zonder omstandigheden kun je slecht herhalen of vergelijken. Dezelfde zorg geldt voor leesbaarheid, toetsenbordbediening en gebruik op de telefoons die medewerkers werkelijk inzetten.
Een ingevuld voorbeeld: een order mag nog niet worden vrijgegeven
Neem een fictieve groothandel die een order boven € 2.500 door twee bevoegde medewerkers wil laten goedkeuren. Het bedrag en deze werkwijze zijn uitsluitend voorbeeldafspraken, geen wettelijke norm of advies voor ieder bedrijf. De acceptatietest controleert hier één grens: één goedkeuring mag nog geen vrijgegeven order opleveren. Test de situatie met twee goedkeuringen vervolgens als een afzonderlijk scenario. Zo blijft duidelijk welke uitkomst bij welke beginsituatie hoort.
Het ingevulde testgeval kan zo luiden: test-ID AT-04; criterium twee bevoegde goedkeuringen boven € 2.500; versie 1.3 in de afgesproken testomgeving; rol orderbeheerder; testorder TEST-104 met een totaal van € 3.000 en één geregistreerde goedkeuring. Stappen: open de order, controleer de eerste goedkeuring, probeer de order vrij te geven en open hem daarna opnieuw. Verwacht: de status blijft wacht op tweede goedkeuring en er wordt geen uitvoeropdracht aangemaakt.
Stel dat de status na de handeling toch vrijgegeven is, terwijl geen uitvoeropdracht verschijnt. Noteer beide waarnemingen. Het ontbreken van die uitvoeropdracht maakt de foutieve status niet goed. Bewaar de testreferentie en een passende schermafbeelding zonder gevoelige gegevens. De conclusie is dat dit criterium niet is gehaald. Laat onderzoeken waar de afwijking ontstaat en herhaal dezelfde proef na herstel. Controleer dan ook dat vrijgave mét twee bevoegde goedkeuringen nog werkt.
Gebruik voor andere taken hetzelfde lege registratieformat: test-ID; gekoppeld criterium; geteste versie; omgeving; rol; beginsituatie en testgegevens; uit te voeren stappen; verwachte uitkomst; werkelijke uitkomst; bewijs; bevinding; verantwoordelijke; hertestresultaat. Dit is een praktisch voorbeeldformat dat je kunt overnemen. Het is geen voorgeschreven certificeringsdocument. Vul de verwachte uitkomst vóór uitvoering in, zodat de waarneming de afspraak niet achteraf verschuift.
3. Test ook verkeerde invoer, rechten en onderbroken koppelingen
Een soepele route met complete gegevens vertelt maar een deel van het verhaal. Laat een verplicht veld leeg, bied ongeldige invoer aan en probeer een handeling opnieuw nadat de verbinding is onderbroken. Bekijk of iemand begrijpt wat is opgeslagen, wat nog wacht en wat opnieuw moet. Let bij opnieuw aanbieden op dubbele opdrachten of dubbele registraties. Spreek per proces af welke herstelroute je verwacht; een foutmelding zonder bruikbare vervolgstap kan het werk alsnog stilleggen.
Controleer rechten met afzonderlijke testaccounts. Een knop verbergen is onvoldoende als een gebruiker via een rechtstreeks adres alsnog gegevens kan bekijken of wijzigen. OWASP adviseert toegangsrechten bij ieder verzoek te controleren en tests voor die rechten te maken. Laat daarom samen met de leverancier ook ongeoorloofde toegang in de afgesproken testomgeving proberen, bijvoorbeeld een order buiten de eigen bevoegdheid. Een beperkte acceptatieproef vervangt geen gespecialiseerde beveiligingstest.
Bij een koppeling controleer je de uitkomst in beide systemen. Een verzonden verzoek is iets anders dan een juist verwerkt record. Gebruik de uitleg over API-koppelingen om gegevensvelden, richting en foutafhandeling te bespreken. Test ook een weigering of tijdelijke onbereikbaarheid. Als die storing is nagebootst, leg dat vast. Vraag welk bewijs nog nodig is voor de echte productieaansluiting en wie controleert dat een mislukte overdracht later correct wordt hersteld.
4. Leg bevindingen vast en hertest de herstelde versie
Noteer een bevinding zo dat een ander haar kan herhalen: versie, rol, invoer, stappen, verwacht resultaat en werkelijk resultaat. Een bericht als het werkt niet helpt weinig als niemand weet welke order of handeling bedoeld wordt. Gebruik alleen bewijs dat nodig is en scherm klantgegevens af. Koppel de bevinding aan de oorspronkelijke test en benoem de invloed op het werk. Kan iemand de kerntaak niet afronden, raken gegevens onjuist of is er een werkbare tijdelijke oplossing?
Laat opdrachtgever en leverancier samen bepalen wat blokkeert en welke volgorde herstel krijgt. Houd fouten binnen de afspraak, onduidelijke afspraken en nieuwe wensen uit elkaar. Markeer een punt niet als opgelost op basis van alleen de mededeling dat de code is aangepast. Noteer de nieuwe versie, herhaal de oorspronkelijke proef en controleer relevante omliggende taken. Een reparatie aan de vrijgave kan bijvoorbeeld invloed hebben op intrekken, opnieuw beoordelen en de zichtbaarheid voor een andere rol.
Wanneer kun je akkoord geven op de oplevering?
Beslis op basis van de afgesproken criteria en de resterende risico’s. Een percentage geslaagde tests kan misleiden: veel kleine geslaagde proeven wegen niet automatisch op tegen één fout die orders verkeerd vrijgeeft. Controleer of alle noodzakelijke taken zijn beoordeeld, blokkerende fouten zijn hersteld en hertesten zijn vastgelegd. Ontbreekt bewijs voor een essentieel onderdeel, benoem dan dat het nog onbekend is. Geef dat onderdeel niet zonder meer de status geslaagd.
Leg het besluit vast met de geaccepteerde versie, datum, betrokken verantwoordelijke, beperkingen en open punten. Voor een geaccepteerd restpunt wil je weten wat de invloed is, welke tijdelijke werkwijze geldt en wie herstel opvolgt. Of zo’n restpunt aanvaardbaar is, hangt af van het proces en de gemaakte afspraken. Betrek daarnaast de praktische voorbereiding: accounts, uitleg aan medewerkers, ondersteuning en een herstelroute bij problemen. Functionele acceptatie en gereedheid voor livegang hangen samen, maar zijn geen identieke controle.
Deze werkwijze helpt om een opleverbesluit te onderbouwen; zij bepaalt niet zelfstandig de juridische gevolgen van acceptatie. Die hangen af van de overeenkomst en de omstandigheden. Maak bij twijfel over contractuele rechten of verplichtingen gebruik van passend juridisch advies. De testregistratie moet vooral duidelijk maken wat daadwerkelijk is gecontroleerd, wat nog openstaat en wie welke beslissing heeft genomen.
Bewaar de tests voor volgende wijzigingen
Gebruik belangrijke geaccepteerde scenario’s opnieuw bij een wijziging van rollen, bedrijfsregels of koppelingen. Pas de verwachte uitkomst alleen aan wanneer de afspraak verandert en bewaar waarom dat is besloten. Voor een systeem met gesprekken zijn extra proeven nodig, zoals omgaan met onduidelijke vragen en overdracht aan een medewerker. Het aparte stappenplan voor een chatbot-acceptatietest werkt die gesprekssituaties uit. De algemene registratie van criterium, waarneming en besluit blijft daarbij bruikbaar.
Wil je bedrijfssoftware op maat laten maken, neem dan één kritieke werktaak mee, inclusief de uitzondering die nu vaak misgaat. Softora kan met je onderzoeken welke eerste versie en toetsbare afspraken daarbij passen. Bespreek acceptatie aan het begin van de opdracht, zodat de offerte, ontwikkeling en uiteindelijke oplevering dezelfde uitkomst bedoelen. Een korte, concrete test van die taak levert een beter gesprek op dan alleen een lijst met schermen en functies.
Over deze uitleg
Deze uitleg is opgesteld door Softora met hulp van AI. De begrippen en beveiligingsclaims zijn gecontroleerd aan de genoemde originele bronnen, geraadpleegd op 23 oktober 2026. De groothandel, order en testuitkomsten zijn fictief. Het registratieformat en de praktische beslisroute zijn een eigen uitwerking. De vier illustraties zijn voor deze uitleg als eigen vectorbeelden getekend; het zijn geen productfoto’s of schermafbeeldingen van een klant.
