Stel, je sluit een online testsessie af. De gebruikers hebben veel opmerkingen gemaakt, de chat staat vol screenshots en iemand zegt dat het nieuwe bestelproces prettig werkt. Klinkt goed, toch? Maar als de product owner vraagt of het proces geaccepteerd is, weet je het eigenlijk niet. De betaalstap is bekeken. Alleen heeft niemand gecontroleerd wat er gebeurt als een bestelling wordt geannuleerd.
Oef. Herkenbaar.
Bij remote UAT sessies zit de spanning precies daar. Iedereen doet zichtbaar mee, maar dat zegt nog niet dat je een volledig beeld hebt. Als test manager wil je gebruikers de ruimte geven om hun werk te doen. Tegelijk wil je achteraf kunnen terugvinden welke afspraken ze echt hebben beoordeeld. Een betere vergaderagenda lost dat niet op. Wat wel helpt: goede voorbereiding, bruikbaar bewijs en iemand die mag beslissen over de risico's die overblijven.
Begin met het besluit dat UAT moet voeden
Een demo en een gebruikersacceptatietest lijken op elkaar, maar ze hebben een ander doel. In een demo laat het team zien wat er is gebouwd. Tijdens UAT kijken gebruikers of het systeem hun werk echt ondersteunt, zoals afgesproken. De uitleg over user acceptance testing helpt om dat verschil met je team te bespreken.
Kies daarom een werkproces met een duidelijk begin en einde. Bijvoorbeeld: een medewerker maakt een bestelling aan, krijgt een bevestiging en annuleert die binnen de toegestane termijn. Spreek vooraf af welke uitkomst nodig is. Want een scherm met de melding ‘geannuleerd’ is niet genoeg als de voorraad daarna verkeerd staat. Dan kan de gebruiker het proces administratief nog steeds niet goed afronden.
Benoem ook wie namens de organisatie accepteert. Dat kan de product owner zijn, of een proceseigenaar, afhankelijk van jullie afspraken. De deelnemers leveren waarnemingen en bewijs. Jij als sessiebegeleider bewaakt het proces. Maar let op: dat betekent nog niet dat een van jullie mag beslissen of een open risico acceptabel is. Die keuze ligt echt bij iemand anders.
Geef de acceptatiecriteria een herkenbaar nummer, zoals AC-03 voor voorraadherstel na annulering. Dan zie je na afloop meteen het verschil tussen een criterium dat is beoordeeld, een criterium met een open bevinding en iets dat nog helemaal niet is getest. Zo voorkom je dat een sessie die prettig voelde ongemerkt als acceptatiebesluit wordt gelezen.
Zorg dat deelname technisch én praktisch mogelijk is
Een gezamenlijke toegangstest aan het begin lijkt efficiënt. Tot één account ontbreekt en de rest moet wachten. We raden daarom aan om vooraf per deelnemer de toegang, rol, browser en testdata te controleren. Laat iemand zelf één eenvoudige handeling uitvoeren. Want kunnen inloggen is nog iets anders dan de rechten hebben om een bestelling te annuleren.
Stuur deelnemers vooraf een korte voorbereiding: het doel, de scenario's, de criteria en waar ze hun bevindingen kwijt kunnen. De gids over UAT test cases schrijven helpt je om dagelijkse taken om te zetten in scenario's die je kunt toetsen. Het hoeft geen dik draaiboek te worden. Het belangrijkste is dat deelnemers snappen welke beslissing hun observaties straks ondersteunen.
De omgeving verdient dezelfde aandacht. Wat als één deelnemer een oudere versie test dan de rest? Dan krijg je tegenstrijdige meldingen die allebei terecht kunnen zijn. Noteer dus welke release je test en controleer de beginsituatie van de data. De uitleg over de UAT-omgeving sluit hier mooi op aan.
Verdeel tijdens de sessie in ieder geval drie taken: begeleiden, bevindingen vastleggen en technische problemen opvangen. Heb je genoeg mensen? Dan is een aparte notulist en een technisch aanspreekpunt prettig. In een kleine sessie kun je rollen combineren. Spreek dan wel af wie de begeleiding even overneemt als jij een accountprobleem oplost.
En wat als de verbinding wegvalt? Ook dat spreek je vooraf af. Zelfstandig verder testen werkt alleen als de deelnemer nog bij het scenario, de omgeving en de registratie kan.
Laat de sessievorm het werkproces volgen
Niet iedere gebruiker heeft dezelfde begeleiding nodig. Een gezamenlijke start helpt om doel en grenzen uit te leggen. Daarna past individueel testen vaak beter bij een taak die iemand normaal ook alleen uitvoert. In een groep geeft een ervaren collega soms al het antwoord, voordat de rest zelf heeft gemerkt waar het proces wringt.
Gaat het om een overdracht tussen rollen? Dan is samen testen juist nuttig. Neem een aanvraag die van een medewerker naar een goedkeurder gaat. Laat beide gebruikers hun eigen account gebruiken, zodat je ziet of de overdracht én de rechten kloppen. Voert de begeleider alles uit op één gedeeld scherm? Dan verdwijnt precies het verschil dat je wilt beoordelen.
Je kunt beginnen met testblokken van ongeveer vijftien minuten, met daarna een korte terugkoppeling. Zie dat wel als een werkafspraak die je uitprobeert, niet als een bewezen concentratiegrens. Een lang administratief proces vraagt meer aaneengesloten tijd. En een gevoelige taak, of een gebruiker die extra ondersteuning nodig heeft, past soms beter in een individuele sessie.
Werken in duo's kan ook. De ene gebruiker voert uit, de andere noteert wat er gebeurt. Wissel als het scenario daar ruimte voor geeft, niet omdat de klok een willekeurig aantal minuten aanwijst. Kijk na de eerste sessie even terug: hadden deelnemers genoeg ruimte, en waren hun observaties bruikbaar voor het acceptatiebesluit? Zo stem je de werkvorm af op wat je in je eigen sessies ziet.
Denk ook aan deelnemers die ondersteunende technologie gebruiken. W3C beschrijft hoe je gebruikers betrekt bij toegankelijkheidsevaluatie. Hun ervaring maakt barrières zichtbaar, maar vervangt geen beoordeling tegen toegankelijkheidscriteria. Voor security en performance geldt hetzelfde. UAT kan laten zien wat een risico betekent voor het werkproces. Voor technische eigenschappen die een gebruiker niet betrouwbaar kan vaststellen, blijven specialistische tests gewoon nodig.
Leg gebruikerskennis vast in bevindingen waar je iets mee kunt
‘Het scherm is onduidelijk’ is het begin van een gesprek. Het is nog geen bevinding waar iemand gericht mee verder kan. Vraag door: wat probeerde de gebruiker, wat verwachtte die en wat gebeurde er echt? Koppel de melding aan het scenario en het criterium. Zo blijft de kennis van de gebruiker bewaard, zonder dat je diens woorden meteen naar technisch jargon vertaalt.
Gebruik één centrale plek voor alle bevindingen. Geef elke bevinding een ID en leg scenario, criterium, release, stappen, verwachte uitkomst en werkelijke uitkomst vast. Voeg een eigenaar en een besluitstatus toe. Ernst en prioriteit bespreek je samen met de betrokkenen. Want een kleine schermafwijking kan voor één proces toch een blokkade zijn, als de gebruiker daardoor zijn taak niet kan afronden.
Een voorbeeld. Een gebruiker kan een retour niet afronden zonder een artikelnummer dat klanten niet kennen. Een screenshot helpt om het invoerveld terug te vinden. De toelichting maakt duidelijk waarom het werk vastloopt. Beide horen bij dezelfde bevinding, bijvoorbeeld UAT-017. Een losse afbeelding in de chat verliest later al snel die context.
Spreek vooraf af welke testdata deelnemers mogen gebruiken en welk bewijsmateriaal nodig is. Neem een scherm alleen op als het doel daarom vraagt, deelnemers ervan weten en de toestemming en interne afspraken geregeld zijn. Leg vast wie erbij kan, waar de bestanden staan en wanneer ze worden verwijderd. En deel geen klantgegevens via een algemene map.
Check die instellingen ook in de tool die je gebruikt. Microsoft legt uit hoe Teams-opnames, toegangsrechten en vervaldata werken. Een melding dat de opname loopt is nog geen complete afspraak over gebruik en bewaren. Bij een kort probleem dat je makkelijk kunt herhalen, werkt tekst met een afgeschermd screenshot vaak beter. Dat is duidelijker en je bewaart minder.
Maak zichtbaar wat bewezen is en wie beslist
Houd aan het einde tijd vrij om de criteria samen langs te lopen. Welke zijn beoordeeld? Welke hebben een open bevinding? En welke kwamen niet aan bod? Laat deelnemers de vastgelegde bevindingen controleren. Zo haal je misverstanden eruit voordat ze als opdracht bij het ontwikkelteam terechtkomen.
Een tevredenheidsscore zegt best iets over de sessie of de gebruikservaring. Maar die score bewijst niet dat het bestelproces aan AC-03 voldoet. Bij toegankelijkheid ligt dezelfde grens: W3C waarschuwt dat eenvoudige controles geen volledige beoordeling zijn. Houd een positief signaal dus apart van het bewijs dat je nodig hebt voor acceptatie.
Daarna legt de beslisser vast wat de uitkomst betekent. Staat er nog een blokkade open? Dan accepteer je dat criterium gewoon nog niet. Is een restpunt acceptabel? Noteer dan de voorwaarde, de eigenaar en de termijn. En is de beslisser er niet bij? Dan is het resultaat geen stilzwijgende goedkeuring. Het is een onderbouwd advies dat nog om een besluit vraagt.
In de terugkoppeling staat per open punt wie het oppakt en wanneer de gebruiker opnieuw kan testen. Neem de retour van net. Is die aangepast, dan controleert de hertest hetzelfde criterium op de nieuwe release, met een passende beginsituatie. Een melding sluiten omdat een developer zegt dat de wijziging klaar is, levert nog geen bewijs van de gebruiker op.
Elke volgende sessie wordt zo makkelijker om te begeleiden. Deelnemers zien welke observatie tot welke keuze leidde. En jij hoeft geen losse chats meer terug te zoeken. Begin bij je eerstvolgende remote UAT-sessie dus met één goed afgebakend proces. Lukt het je om gebruikerskennis te verbinden aan zichtbaar bewijs en een echt besluit? Dan voeg je als test manager iets toe wat schermdelen alleen nooit oplevert.
Wil je bespreken hoe jouw team gebruikersfeedback verbindt aan een helder acceptatiebesluit? We denken graag mee over voorbereiding, bewijs en opvolging.
