HR-software testen vóór livegang: een praktisch acceptatietestplan
Controleer met dagelijkse gebruikers of de ingerichte werkwijze echt werkt. Met een ingevulde testkaart, een praktijkvoorbeeld en houvast voor het startbesluit.
Een acceptatietest van HR-software is een proef waarin dagelijkse gebruikers controleren of de ingerichte software hun afgesproken werk ondersteunt. Je legt vooraf het verwachte resultaat vast, voert de taak uit en vergelijkt de uitkomst. Op basis van die resultaten besluit de organisatie of zij kan starten, nog iets moet herstellen of de invoering moet uitstellen.
Dat klinkt eenvoudig. Toch blijft het bij een laatste controle vaak bij ‘ik kan inloggen’ of ‘de aanvraag staat erin’. Daarmee weet je nog niet of de juiste leidinggevende de aanvraag krijgt en de medewerker het besluit terugziet. Vanuit WorkVine geven we je daarom een praktische testkaart en een uitgewerkt voorbeeld. Daarmee maak je van losse indrukken een controleerbaar startbesluit.
Een demo is geen acceptatietest
Tijdens een demo onderzoek je of een pakket bij je organisatie past. Bij een acceptatietest controleer je de gekozen, ingerichte werkwijze met de betrokken gebruikers. De leverancier kan een proces in een voorbeeldomgeving goed tonen, terwijl bij jullie nog een teamindeling, vervanger of melding verkeerd staat.
De gebruikersacceptatietest wordt ook UAT genoemd, naar user acceptance testing. Het doel is niet om zelf alle technische tests van de leverancier over te doen. Je wilt weten of mensen hun werk kunnen uitvoeren. Een geslaagde gebruikersproef vervangt geen afzonderlijke beoordeling van beveiliging, privacy, gegevensoverzetting of koppelingen door de verantwoordelijke specialisten.
Spreek af wat bij de eerste start moet werken
Begin met de processen die bij ingebruikname nodig zijn. Neem de afgesproken eisen als uitgangspunt en maak per proces duidelijk wie het resultaat beoordeelt. Bijvoorbeeld: medewerkers dienen een aanvraag in, hun leidinggevende handelt die af en beiden zien het besluit. Een extra rapportage die pas later nodig is, hoeft niet stilzwijgend een voorwaarde voor deze eerste start te worden.
Laat ook vastleggen wat de proef blokkeert. Kunnen testers niet inloggen of ontbreken noodzakelijke testgegevens? Noteer dan ‘niet uitvoerbaar’ in plaats van ‘afgekeurd’ of ‘geslaagd’. Eerst moet de beginsituatie worden hersteld. Nieuwe wensen zet je apart: bespreek of ze de afgesproken start echt veranderen.
TMAP benadrukt dat duidelijk moet zijn wie de software accepteert en welke criteria daarbij gelden. Spreek die voorwaarden vooraf af, niet pas wanneer de startdatum onder druk staat. De invulling hieronder is onze praktische vertaling voor een HR-proces, geen voorgeschreven standaardtest.
Maak iedere test herhaalbaar
Een testkaart beschrijft één situatie zo precies dat een collega de proef kan herhalen. Noteer daarom niet alleen de handeling, maar ook de uitgangspositie. Welke gebruiker, welk team, welke periode en welke status zijn nodig? Zonder die gegevens kan een tweede poging iets anders testen dan de eerste.
Gebruik fictieve gegevens en afgesproken testaccounts in een daarvoor bedoelde omgeving. Laat de beheerder vooraf controleren dat proefhandelingen geen echte medewerkers berichten sturen of onbedoeld gegevens naar een productiesysteem doorzetten. Dat is een voorbereiding met de beheerder, geen aanname omdat ergens ‘test’ op het scherm staat.
Noteer de datum en herkenbare versie of inrichtingsstand. Als instellingen tussendoor veranderen, wil je kunnen terugvinden welke situatie je hebt beoordeeld. Bewaar ook wat je echt zag; een leeg resultaatveld is geen bewijs dat een test geslaagd is.
Voorbeeld van een ingevulde testkaart
Fictieve proef voor een aanvraagproces. Pas velden, stappen en uitkomsten aan de afgesproken inrichting aan.
| Onderdeel | Wat leg je vast? |
|---|---|
| Test en afspraak | T-04: een aanvraag bereikt de aangewezen vervanger als de vaste beoordelaar afwezig is. |
| Beginsituatie | Testmedewerker A hoort bij team Noord. Beoordelaar B is afwezig. C is volgens de inrichting vervanger. Er staat nog geen aanvraag voor de testdatum. |
| Handelingen | A dient de aanvraag in. C logt met het eigen testaccount in, zoekt de aanvraag en behandelt die. A controleert daarna het besluit. |
| Verwachte uitkomst | C kan de aanvraag afhandelen. A ziet het juiste besluit. De aanvraag blijft niet onbehandeld bij B liggen. |
| Werkelijke uitkomst | A kon indienen. C zag de aanvraag niet. De afhandeling en terugmelding aan A konden daardoor niet worden getest. |
| Resultaat en vervolg | Niet geslaagd; bevinding B-07. Beheerder onderzoekt de vervangingsinstelling. Na herstel wordt de hele route opnieuw uitgevoerd. |
Test de normale route, een afwijking en een correctie
Laat eerst een veelgebruikte taak van begin tot einde uitvoeren. Wissel daarbij werkelijk van gebruiker. Een beheerder die alles namens iedereen doet, laat niet zien wat een medewerker of leidinggevende zelfstandig kan. Controleer het eindresultaat ook bij de persoon die het nodig heeft.
Voeg daarna relevante varianten toe. Denk aan een afwezige beoordelaar, ontbrekende invoer of een aanvraag die na afwijzing wordt aangepast. Kies varianten op basis van jullie dagelijkse werk en de gevolgen van een fout; er bestaat geen vast aantal waarmee ieder HR-proces voldoende is getest.
Test ten slotte het herstel. Een verkeerd ingevoerde datum vinden is nuttig, maar de gebruiker moet die situatie ook volgens de afgesproken werkwijze kunnen oplossen. Controleer na die correctie of alle betrokkenen dezelfde actuele uitkomst zien. Test waar relevant ook op de telefoon of browser die de gebruikers werkelijk gaan gebruiken.
Praktijkvoorbeeld: de aanvraag blijft bij de verkeerde persoon liggen
Een fictieve organisatie start met aanvragen voor drie teams. In de normale proef werkt alles: de vaste leidinggevende ziet de aanvraag en de medewerker ontvangt het besluit. Het projectteam zou op basis daarvan kunnen concluderen dat het proces klaar is.
Bij test T-04 blijkt dat de vervanger niets ziet. De organisatie wil juist vanaf de start ook bij afwezigheid aanvragen kunnen afhandelen. Daarom is dit geen klein ongemak, maar een probleem in een afgesproken noodzakelijke route. Het team registreert de bevinding en laat de oorzaak onderzoeken, zonder direct te concluderen dat de software defect is.
De beheerder ontdekt in dit fictieve voorbeeld een onjuiste teamtoewijzing. Na aanpassing voeren medewerker A en vervanger C dezelfde test opnieuw uit. Ditmaal lukt de hele route. Omdat de instelling ook de normale beoordeling kan raken, wordt die route eveneens herhaald. Pas daarna wordt B-07 gesloten, met datum, tester en resultaat.
De les: een herstelmelding is nog geen geslaagde hertest. En een geslaagde hertest van de fout bewijst niet automatisch dat verwante taken ongewijzigd blijven werken.
Beschrijf een bevinding zonder alvast de oorzaak te raden
‘Het werkt niet’ geeft een beheerder weinig houvast. Beschrijf de test, de stap waarop het misging, het verwachte resultaat en wat er werkelijk gebeurde. Voeg zo nodig een schermafbeelding uit de fictieve test toe. Vermeld welke rollen of teams geraakt worden en of de fout opnieuw optreedt.
Maak onderscheid tussen een afwijking van de afspraak, onduidelijke uitleg en een nieuwe wens. Een instelling kan verkeerd staan, een gebruiker kan een instructie missen of de gekozen oplossing kan de afgesproken taak niet uitvoeren. Laat de verantwoordelijke de oorzaak onderzoeken. Bewaar het werkprobleem ook als de technische oorzaak later een andere blijkt.
Wijs ieder open punt toe aan één eigenaar, met een terugkoppeldatum. Gebruik naast open en opgelost ook ‘klaar voor hertest’. Zo wordt een melding van de leverancier of beheerder niet per ongeluk als bevestiging van de gebruiker behandeld.
Welke bevinding houdt de start tegen?
Voorbeeldindeling om vooraf te bespreken. De verantwoordelijken bepalen de ernst op basis van jullie proces en risico’s.
| Gevolg voor het werk | Passend vervolg |
|---|---|
| Noodzakelijke taak lukt niet | Blokkeer ingebruikname van dit onderdeel totdat de afgesproken route aantoonbaar werkt of de scope verantwoord is aangepast. |
| Taak lukt alleen via een omweg | Beoordeel de omweg expliciet: wie voert die uit, is die uitvoerbaar en tot wanneer? Laat de bevoegde eigenaar besluiten; accepteer geen stilzwijgende noodroute. |
| Taak lukt, uitleg of opmaak kan beter | Leg verbetering, eigenaar en datum vast. Controleer of de onduidelijkheid toch tot verkeerde handelingen leidt voordat je haar als klein punt afsluit. |
| Belangrijke test is niet uitgevoerd | Noem dit ontbrekend bewijs, niet een geslaagde test. Plan de proef alsnog of leg vast waarom het startbesluit nog niet kan worden genomen. |
Leg het startbesluit vast, inclusief wat nog openstaat
Laat de verantwoordelijke voor ieder proces bevestigen welke tests zijn uitgevoerd, op welke inrichting en met welk resultaat. Bespreek open punten en ontbrekende controles. Een percentage geslaagde tests is op zichzelf onvoldoende: één mislukte noodzakelijke route kan zwaarder wegen dan twintig geslaagde eenvoudige handelingen.
Leg het besluit kort vast: welk onderdeel mag starten, voor welke gebruikers, welke punten blijven open en wie bewaakt ze? Een beperkte start kan passen, maar alleen als afhankelijkheden zijn beoordeeld. Een team afzonderlijk laten beginnen helpt bijvoorbeeld niet wanneer dezelfde fout ook een gedeelde overdracht raakt.
Regel daarnaast het aanspreekpunt voor de eerste gebruiksdagen en een afgesproken opvangroute als een cruciale taak niet lukt. De acceptatietest geeft informatie voor dit besluit; hij vervangt geen toestemming van de verantwoordelijke of de overige controles voor ingebruikname.
Gebruik deze testkaart ook bij WorkVine
We schrijven deze gids vanuit WorkVine omdat een HR-proces niet ophoudt bij het opslaan van een gegeven. Het gaat ook om de collega die daarna moet handelen. De testkaart helpt je die overdrachten zichtbaar te maken en met een concreet resultaat te beoordelen.
Gebruik haar daarom ook bij de inrichting van WorkVine. Neem jullie afgesproken proces, rollen en uitzonderingen als uitgangspunt. Laat zien wat daadwerkelijk is ingericht en uitgevoerd, en houd nog te realiseren onderdelen apart. De voorbeelden in deze gids beschrijven testvragen, geen belofte dat iedere genoemde werkwijze standaard beschikbaar is.
Begin met één proces dat bij de start onmisbaar is. Vul samen met de dagelijkse gebruikers de verwachte uitkomst in, voer de proef uit en leg de bevindingen vast. Zo wordt het gesprek over ‘klaar voor gebruik’ concreet, zonder een onnodig omvangrijk testdocument.
Wie voert de acceptatietest uit?
Laat representatieve dagelijkse gebruikers hun eigen taken uitvoeren, bijvoorbeeld een medewerker, leidinggevende en HR-collega. Een projectverantwoordelijke bundelt de resultaten. De leverancier of beheerder helpt bij inrichting en onderzoek, maar de organisatie bepaalt wie het werkresultaat accepteert. Betrek specialisten bij controles buiten de functionele gebruikersproef.
Moet alles opnieuw worden getest na een wijziging?
Herhaal in ieder geval de eerder mislukte proef op de gewijzigde inrichting. Bepaal daarnaast welke andere taken door die wijziging geraakt kunnen zijn en test die opnieuw. Vraag de beheerder of leverancier daarbij om uitleg over het bereik van de wijziging. Noteer welke eerdere resultaten nog gelden en welke zijn vervangen.
Bronnen en controledatum
Bronnen gecontroleerd op 23 september 2026. TMAP beschrijft het afspreken van acceptatiecriteria; ISTQB behandelt de samenwerking tussen gebruikersvertegenwoordigers en testers bij acceptatie. De HR-testkaart, voorbeeldindeling en fictieve praktijksituatie zijn eigen redactionele uitwerkingen van WorkVine. Dit artikel biedt geen certificering, garantie of volledige technische testaanpak.