Software acceptatietest: wat je zelf moet controleren

Je staat op het punt om nieuwe software te accepteren. Maar wat controleer je eigenlijk?

Je hebt weken of maanden samengewerkt met een softwarebedrijf. Er is gebouwd, bijgeschaafd en gedemonstreerd. Nu ligt de oplevering voor je. De ontwikkelaar vraagt om akkoord. En dan? Veel opdrachtgevers tekenen op gevoel — of stellen het accepteren eindeloos uit, omdat ze niet precies weten waar ze op moeten letten.

Een goede software acceptatietest lost dat op. Het is geen bureaucratisch ritueel, maar een praktische check: doet de software wat jullie hebben afgesproken, en is die klaar om echt te gebruiken? In dit artikel lees je hoe je dat concreet aanpakt.

Wat is een software acceptatietest precies?

Een software acceptatietest — ook wel UAT, User Acceptance Testing, genoemd — is de fase waarin jij als opdrachtgever controleert of de opgeleverde software voldoet aan de afgesproken eisen. Niet de ontwikkelaar, maar jij en je team gaan ermee aan de slag.

Het doel is enkelvoudig: vaststellen of de software gereed is voor productie. Dat doe je aan de hand van vooraf vastgelegde acceptatiecriteria en concrete testscenario’s. Zonder die basis test je in het wilde weg — en dan weet je achteraf nog niet of je terecht akkoord hebt gegeven.

Stel je acceptatiecriteria op vóórdat de bouw begint

Dit is het meest gemaakte fout: acceptatiecriteria opstellen ná de oplevering, in plaats van ervóór. Dan meet je met een liniaal die je zelf net hebt getekend.

Goede acceptatiecriteria beschrijven concreet gedrag. Niet: het systeem moet snel zijn. Maar: een zoekopdracht in de orderlijst levert binnen twee seconden resultaat op, ook bij meer dan 10.000 regels. Niet: de koppeling met Exact moet werken. Maar: een factuur aangemaakt in het systeem verschijnt binnen vijf minuten in Exact Online, inclusief de juiste grootboekrekening.

Hoe specifieker, hoe beter. Vaag geformuleerde criteria leiden altijd tot discussie bij de oplevering. En discussie kost tijd en geld — aan beide kanten.

Zo bouw je testscenario’s op

Een testscenario beschrijft één situatie van begin tot eind: wie doet wat, met welke invoer, en wat is het verwachte resultaat? Denk aan de dagelijkse handelingen van je team, maar ook aan uitzonderingen en foutgevallen.

Begin met de happy path

De happy path is het standaard scenario: alles klopt, de gebruiker doet wat verwacht wordt. Een medewerker logt in, maakt een order aan, koppelt een klant en slaat op. Werkt dat vlekkeloos? Dan ben je klaar voor de volgende stap.

Test daarna de uitzonderingen

Wat gebeurt er als een verplicht veld leeg blijft? Als iemand twee keer hetzelfde emailadres invoert? Als de verbinding met een externe dienst wegvalt? Juist in de randgevallen zie je hoe robuust een systeem is. Fouten in de happy path zijn gênant; fouten in uitzonderingen zijn gevaarlijk.

Betrek de eindgebruikers

De mensen die dagelijks met het systeem gaan werken, zien dingen die jij mist. Laat hen de testscenario’s uitvoeren — niet als technische testers, maar gewoon als collega’s die hun werk proberen te doen. Hun feedback is goud waard.

Wat leg je vast tijdens de test?

Documenteer wat je test, wat je verwachtte en wat je zag. Een simpele tabel of spreadsheet is genoeg: scenario, stap, verwacht resultaat, werkelijk resultaat, status (geslaagd / niet geslaagd / opmerkelijk). Je hebt dit nodig als je bevindingen wilt terugkoppelen aan de ontwikkelaar — en als bewijs mocht er later discussie ontstaan.

Maak ook screenshots of korte schermopnames van gebreken. Omschrijvingen als het werkt niet goed zijn voor niemand nuttig. Een screenshot met een pijltje erbij is dat wel.

Wanneer teken je voor akkoord?

Dit is de vraag waar het om draait. Er zijn twee uitersten die je wilt vermijden: te vroeg tekenen (en later spijt krijgen) en eindeloos uitstellen (en de livegang onnodig vertragen).

Een handige vuistregel: onderscheid tussen blokkers en wensen. Een blokker is een gebrek dat je echt niet live kunt gaan — een berekening die fout uitpakt, een koppeling die niet werkt, data die verloren gaat. Een wens is iets dat mooier of handiger had gekund, maar de werking niet in de weg staat.

Teken als alle blokkers zijn opgelost. Leg de wensen vast in een lijst en maak afspraken over wanneer en hoe die worden opgepakt. Zo staat het project niet stil op details, maar laat je ook niets wezenlijks liggen.

Wat als je er samen niet uitkomt?

Soms is er verschil van inzicht: de ontwikkelaar vindt dat iets werkt zoals afgesproken, jij niet. Dan kom je terug op de acceptatiecriteria die je aan het begin hebt vastgelegd. Zijn die er niet, of zijn ze vaag? Dan is de discussie moeilijker te beslechten.

Dit is precies waarom wij bij Roesware aan het begin van elk traject de eisen helder maken. We bouwen snel een werkend prototype zodat je vroeg kunt zien of we de goede kant op gaan — lang voordat er discussie over acceptatie kan ontstaan. In plaats van eindeloos specificeren en dan hopen dat het klopt, toetsen we al onderweg.

Kijk ook eens naar hoe dat in de praktijk uitpakt, bijvoorbeeld bij DHK Kozijnen, waar we een orderbeheer integratie bouwden met Exact — of bij Pandwachters, waar een heel proces werd gedigitaliseerd. In beide gevallen begon het bij een helder geformuleerd proces, zodat de acceptatie geen verrassing was.

Praktische checklist voor je acceptatietest

Zijn de acceptatiecriteria concreet en meetbaar vastgelegd? Als je twijfelt, zijn ze dat niet. Herschrijf ze tot je ze kunt aanvinken met ja of nee.

Heb je testscenario’s voor zowel de standaardsituatie als de uitzonderingen? Minimaal tien scenario’s voor een gemiddeld systeem; meer als je complexe processen heeft.

Hebben de eindgebruikers zelf getest, niet alleen de projectleider? Hun dagelijkse gebruik onthult wat een demo verbergt.

Zijn alle bevindingen gedocumenteerd? Mondeling terugkoppelen is onvoldoende. Schrijf het op.

Is duidelijk welke bevindingen blokkers zijn en welke wensen? Zorg dat beide partijen het eens zijn over dat onderscheid.

Zijn er afspraken over hoe en wanneer resterende punten worden opgepakt? Leg dat schriftelijk vast vóórdat je tekent.

Het resultaat van een goede acceptatietest

Je gaat live met vertrouwen in plaats van hoop. Je weet wat het systeem doet, wat het niet doet en wat er nog op de planning staat. De ontwikkelaar weet dat jij tevreden bent — en heeft een helder beeld van eventuele vervolgstappen.

Dat is de basis voor een goede samenwerking op de lange termijn. Software is nooit echt af; het groeit mee met je bedrijf. Een acceptatietest is dan ook geen eindpunt, maar een mijlpaal.

Benieuwd hoe wij dat aanpakken bij webapplicaties op maat of API-koppelingen? Bekijk het overzicht van onze oplossingen, of neem gewoon contact op. Geen verkooppraat — gewoon even meedenken over wat jij nodig hebt.