De demo werkt. Kun je de softwareoplevering goedkeuren?

“De orderverwerking moet goed werken” klinkt duidelijk totdat iemand moet bepalen of het klaar is. Bedoel je dat een order kan worden opgeslagen, dat de juiste prijs wordt berekend of dat het magazijn er daadwerkelijk mee verder kan? Iedere uitleg leidt tot andere controles.

Beschrijf daarom vóór de bouw wat je bij oplevering wilt kunnen waarnemen. Wie voert de handeling uit, met welke uitgangssituatie en welk resultaat? De Britse GOV.UK Service Manual omschrijft acceptatiecriteria als uitkomsten waarmee je controleert of een gebruikersbehoefte wordt vervuld. Dat is ook een bruikbaar vertrekpunt voor bedrijfssoftware; het schrijft jullie contractvorm niet voor.

Neem als fictief voorbeeld een groothandel met een nieuwe orderfunctie. Een bruikbaar criterium is dat een verkoopmedewerker een order met de afgesproken klantprijs kan bevestigen, waarna het magazijn precies de bevestigde aantallen ontvangt. Dat is concreter dan “een orderknop toevoegen” en laat nog ruimte voor een goed productontwerp.

Begin met de gewone route en voeg enkele situaties toe waarin een fout gevolgen heeft. Kies ze samen met de mensen die het werk kennen. Zij weten vaak welke klantafspraak, uitzondering of ontbrekende informatie in een keurige demonstratie niet voorkomt.

Voor de fictieve groothandel kan een kleine acceptatieset er zo uitzien:

Situatie	Wat je wilt vaststellen
Bekende klant met een prijsafspraak	De bevestigde order gebruikt de juiste afspraak en aantallen.
Medewerker zonder bevestigingsbevoegdheid	Die kan de order niet alsnog definitief maken.
Klant wijzigt een aantal vóór bevestiging	Het magazijn ontvangt de uiteindelijk bevestigde versie.
Overdracht naar het magazijn mislukt	De medewerker ziet dat opvolging nodig is en wie die uitvoert.

Deze tabel is een begin, geen volledige testdekking. Een groot financieel gevolg, gevoelige gegevens of een moeilijk herstelbare handeling vraagt meer bewijs dan een kleine tekstwijziging. Laat de technische partner aangeven welke controles al geautomatiseerd zijn en welke risico's daarmee nog niet worden afgedekt.

Laat een medewerker tijdens de beoordeling een herkenbare opdracht uitvoeren. Geef bijvoorbeeld de klantvraag en de benodigde gegevens, maar schrijf niet iedere muisklik voor. Anders toets je vooral of iemand jouw instructies kan volgen. Observeer waar de medewerker twijfelt, informatie mist of een collega nodig heeft.

Maak vooraf duidelijk welke hulp tijdens de proef beschikbaar is. Een geplande werkinstructie gebruiken kan normaal zijn. Een ontwikkelaar die voortdurend uitlegt welk verborgen veld nodig is, maakt de uitkomst minder overtuigend. Noteer die hulp als onderdeel van het resultaat.

Beoordeel ook de overdracht. Kan de volgende collega zonder mondelinge aanvulling verder? Ziet die welke versie bevestigd is en welke keuze nog openstaat? Zo blijft de test verbonden met de dienstverlening, in plaats van te eindigen zodra het scherm een groene melding toont.

Het artikel over software invoeren met medewerkers gaat breder over de nieuwe werkwijze en begeleiding. Bij acceptatie maak je het oordeel over één concrete oplevering controleerbaar. Medewerkers leveren daarvoor vakkennis; zij hoeven niet de verantwoordelijkheid voor alle technische kwaliteit over te nemen.

Leg vast op welke versie, omgeving en gegevens de beoordeling betrekking heeft. Gebruik passende testgegevens en voorkom dat een proef echte bestellingen, facturen of berichten naar klanten veroorzaakt. Bespreek met de ontwikkelaar hoe zulke effecten in de testomgeving worden afgevangen.

Laat testaccounts de rollen van echte gebruikers nabootsen. Een beheeraccount dat overal bij kan, bewijst weinig over de dagelijkse bevoegdheden. Neem ook relevante apparaten mee. Een handeling die aan een groot bureauscherm lukt, kan op de werkplek een andere ervaring geven.

Bewaar per bevinding de uitgangssituatie, handeling, verwachte uitkomst en werkelijke uitkomst. Voeg zo nodig een voorbeeld toe zonder onnodige persoonsgegevens. Daarmee kan de ontwikkelaar het probleem reproduceren en kan een collega later controleren of de oplossing werkt. Een losse melding als “soms gaat het mis” is daarvoor onvoldoende.

Niet iedere bevinding hoeft ingebruikname te blokkeren. Een foutieve prijsberekening kan dat wel doen; een begrijpelijke maar onhandige veldvolgorde vraagt mogelijk een andere afweging. Spreek de grenzen vooraf af, zodat tijdsdruk bij oplevering niet stilzwijgend bepaalt wat acceptabel is.

Maak per open punt duidelijk wie wordt geraakt, welke tijdelijke werkwijze mogelijk is en wie het besluit neemt. Een tijdelijke oplossing moet uitvoerbaar zijn voor de medewerkers die ermee gaan werken. Geef haar een eigenaar, een eindmoment en een controle op herstel. “Later oplossen” zonder die afspraken is geen beheerst besluit.

Houd een niet-geteste situatie apart van een geslaagde test. Ontbrekende klantgegevens of een onbereikbare koppeling betekenen dat bewijs ontbreekt. Besluit bewust of dat ontbrekende bewijs eerst nodig is. Noteer ook wanneer het oordeel uitsluitend geldt voor een beperkte gebruikersgroep of één type opdracht.

Een geslaagde acceptatieproef is één onderdeel van kwaliteit. De GOV.UK-handleiding over regelmatig testen onderscheidt bruikbaarheid van technische controles en noemt verschillende testvormen. Een medewerker die een order goed afrondt, bewijst bijvoorbeeld nog niet dat de software onder zware belasting betrouwbaar blijft.

Spreek daarom af wie de technische vrijgave verzorgt, wat na ingebruikname wordt gecontroleerd en hoe een probleem wordt opgevangen. Als de software na de proef verandert, bepaal dan welke situaties opnieuw moeten worden uitgevoerd. Het akkoord hoort bij de beoordeelde versie en de vastgelegde voorwaarden.

Begin bij de eerstvolgende oplevering met enkele doorslaggevende werksituaties. Laat opdrachtgever, medewerker en ontwikkelaar vooraf hetzelfde resultaat beschrijven en achteraf hetzelfde bewijs beoordelen. Bij kwaliteit en beheer verbinden we zulke controles aan ontwikkeling, vrijgave en opvolging. Daarmee wordt “akkoord” een onderbouwde beslissing waar het team mee verder kan.