Een goedgekeurd ontwerp is nog geen geteste applicatie.

Een overtuigend scherm geeft nog geen antwoord

Een leverancier wil met AI snel een applicatie ontwikkelen. Supergebruikers mogen ondertussen de ontwerpen in Figma beoordelen. Hun feedback moet vertrouwen geven in het resultaat. Een gespecialiseerd testteam wordt niet betrokken.

Dat klinkt efficiënt: snel bouwen en de gebruikers direct laten meekijken. Toch ontbreekt een essentieel onderdeel wanneer deze ontwerpbeoordeling de plaats inneemt van het testen van de werkende applicatie. Hoe weet de opdrachtgever straks dat processen, gegevens en koppelingen daadwerkelijk goed functioneren?

Wat je met een prototype wél onderzoekt

Een prototype helpt om vroeg te ontdekken of mensen het ontwerp begrijpen. Vinden ze de juiste functie? Is de volgorde logisch? Ontbreekt een stap in hun werkproces?

Dat is waardevol onderzoek. Het voorkomt dat een team een onduidelijk of onbruikbaar ontwerp bouwt. Maar een prototype hoeft nog niet aan dezelfde eisen te voldoen als productiesoftware. Ook de Britse overheidsrichtlijn voor prototyping maakt dat onderscheid expliciet, bijvoorbeeld voor beveiliging en prestaties. [1]

Stel dat iemand op “Opslaan” klikt en een bevestiging ziet. In een klikbaar ontwerp kan dat simpelweg het volgende scherm zijn. Daarmee is nog niet vastgesteld dat gegevens correct worden opgeslagen, een koppeling slaagt of een fout netjes wordt afgehandeld.

Noem deze activiteit daarom ontwerpvalidatie of een prototypetest. Presenteer de uitkomst niet als een afgeronde gebruikersacceptatietest (GAT) van de applicatie.

Supergebruikers en testers brengen verschillende expertise mee

Supergebruikers kennen het dagelijkse werk. Zij herkennen onlogische stappen, ontbrekende informatie en uitzonderingen die ontwikkelaars mogelijk niet kennen. Hun bijdrage is onmisbaar.

Professionele testers voegen daar een systematische onderzoeksaanpak aan toe. Ze maken risico’s expliciet, onderzoeken grensgevallen, combineren gebruikersrollen en gegevenssituaties en leggen vast wat wel en niet is onderzocht.

Kunnen supergebruikers gestructureerd testen? Zeker, met passende voorbereiding en begeleiding. Maar domeinkennis alleen vervangt geen testexpertise. Andersom kan een tester de praktijkkennis van gebruikers niet vervangen. ISTQB beschrijft acceptatietesten juist als samenwerking tussen onder meer business, productverantwoordelijken en testers. [2]

Wat blijft buiten beeld als je alleen schermen beoordeelt?

De belangrijkste openstaande vragen zitten vaak achter het scherm. Niet ieder project vraagt even uitgebreide tests. De benodigde diepgang volgt uit de risico’s. Maar deze vragen verdwijnen niet doordat een ontwerp is goedgekeurd.

1. Gegevens: blijven wijzigingen behouden en kloppen berekeningen en validaties?
2. Autorisatie: kan iemand gegevens bekijken of aanpassen waarvoor diegene geen rechten heeft?
3. Koppelingen: wat gebeurt er wanneer een ander systeem traag is, uitvalt of onverwachte informatie terugstuurt?
4. Gelijktijdig gebruik: wat gebeurt er als twee medewerkers hetzelfde dossier wijzigen?
5. Toegankelijkheid en prestaties: werkt de gebouwde applicatie met toetsenbord en hulptechnologie, en blijft zij bruikbaar onder belasting?
6. Beheer en herstel: zijn fouten terug te vinden, is herstel mogelijk en blijven bestaande functies na wijzigingen werken?

Betrek testexpertise voordat de code er is

Dit is waar shift left helpt: eerder beginnen met kwaliteitsonderzoek. Een tester kan tijdens de eerste gesprekken al onduidelijke eisen, ontbrekende uitzonderingen en moeilijk testbare keuzes zichtbaar maken. Testanalyse hoeft niet te wachten tot de applicatie klaarstaat. [3]

“Een medewerker kan een aanvraag goedkeuren” roept bijvoorbeeld meteen vragen op. Welke medewerker? Mag diegene een eigen aanvraag goedkeuren? Wat gebeurt er wanneer de aanvraag ondertussen verandert?

Die antwoorden helpen zowel het ontwerp als de implementatie. Vroeg testen vervangt vervolgens niet het testen van de gebouwde software.

Zo wordt de aanpak sterker

Laat leverancier, opdrachtgever, supergebruikers en testexpertise vanaf het begin samenwerken:

1. Maak risico’s en acceptatiecriteria concreet. Spreek af welk gedrag nodig is en welk bewijs de opdrachtgever verwacht.
2. Gebruik prototypes voor vroege feedback. Verwerk bevindingen voordat ze in code terechtkomen.
3. Controleer iedere werkende uitbreiding. Combineer codebeoordeling, geautomatiseerde controles en gericht onderzoek.
4. Voer de GAT uit op werkende software. Gebruik representatieve rollen, gegevens, koppelingen en bedrijfsprocessen. Leg beperkingen van de testomgeving vast.
5. Neem een onderbouwd acceptatiebesluit. Maak bevindingen, resterende risico’s en verantwoordelijkheden zichtbaar.

Snel ontwikkelen vraagt duidelijke verantwoordelijkheid

Met “vibe coding” wordt vaak bedoeld dat software via AI-instructies en snelle iteraties ontstaat. Hoeveel menselijke controle daarbij plaatsvindt, verschilt. Vraag daarom concreet wie de code begrijpt, beoordeelt, test en onderhoudt.

Voor SBIT hoort kwaliteit vanaf de eerste vraag bij het ontwikkelwerk. Gebruikersfeedback, testexpertise en technische controles leveren samen de onderbouwing waarmee een opdrachtgever verantwoord verder kan.