Inzichten uit de praktijk door de testing experts van M2Q

In onze nieuwste podcastaflevering zetten we twee begrippen naast elkaar die in de praktijk vaak door elkaar lopen: acceptatietesten en beta testing. Want hoewel ze allebei plaatsvinden aan het einde van een testtraject, zijn het fundamenteel andere exercities, met een ander doel, een ander publiek en andere uitkomsten.

Acceptatietesten vs. beta testing: de kern van het verschil

Acceptatietesten (of UAT, User Acceptance Testing) vertrekt vanuit vooraf opgestelde acceptatiecriteria. Eindgebruikers verifiëren of de applicatie voldoet aan de business requirements die bij aanvang van het project werden gedefinieerd. Het is een formele controle: is geleverd wat werd afgesproken?

Beta testing werkt anders. De applicatie staat al, in productie of in een afgeschermde omgeving, en een groep gebruikers gaat er in de praktijk mee aan de slag. Zonder checklist, zonder script. Het doel is niet nagaan of requirements geïmplementeerd zijn, maar ontdekken hoe de software zich gedraagt in de echte wereld.

“Acceptatietesten kijkt of de eis geïmplementeerd is. Beta testing kijkt of de applicatie werkt in de praktijk. Dat verschil kan groter zijn dan je denkt.”

Een haven als testlabo

Een concreet voorbeeld uit de praktijk illustreert dat verschil treffend. Tijdens een project voor een havenbeheersysteem werden boten, registraties en verkeersstromen beheerd via een applicatie die zowel vanop de wal als vanop het water bruikbaar moest zijn.

Functionele tests: geslaagd. Acceptatietesten met eindgebruikers: positief afgerond. En toch bleek pas tijdens de beta test, vanop een RWS-boot in de havengeul, dat bepaalde uithoeken van de haven buiten het wifibereik vielen. De connectie viel weg, de applicatie haperde. Niets wat je in een gecontroleerde testomgeving zou ontdekken.

Dat is precies de toegevoegde waarde van beta testing: het blootleggen van problemen die alleen in real-life omstandigheden opduiken.

Gecontroleerd of open? Dat hangt af van uw context

Beta testing kan op twee manieren worden georganiseerd:

Enerzijds is er de open aanpak, waarbij een brede groep gebruikers vrij met de applicatie aan de slag gaat. Denk aan een beta-knop in een bestaande tool waarmee iedereen nieuwe features kan uitproberen. De feedback is breed, de impact moeilijker te sturen.

Anderzijds is er de gerichte aanpak, waarbij specifieke doelgroepen worden geselecteerd op basis van gebruik, regio of profiel. Dit geeft meer gestructureerde feedback en laat toe om gerichte scenario’s te evalueren. Voor een app gericht op zorgpersoneel dat thuisbezoeken registreert, selecteer je idealiter effectief die medewerkers, en laat je hen hun dagelijkse werk doen met de nieuwe tool.

Batterijverbruik ontdek je niet in een sprint

Tijdens een project voor Audi, toen elektrische wagens nog een echte innovatie waren, werd een app ontwikkeld om rijgedrag in kaart te brengen en potentiële kopers te overtuigen van de haalbaarheid van elektrisch rijden. UAT: geslaagd. Maar eenmaal de app live liep bij echte testrijders, bleek dat de constante satellietverbinding de gsm-batterij aanzienlijk belastte. Een platte batterij halverwege de dag was geen hypothetisch risico, maar een reëel probleem.

Zulke inzichten haal je niet uit een testomgeving. Je haalt ze uit de praktijk.

Hoe verzamelt u feedback?

Een veelgestelde vraag: hoe weet u wat er misgaat als er geen analist meekijkt? In de meeste gevallen via een ingebouwde bugrapportagefunctie, een eenvoudige knop waarmee gebruikers fouten rechtstreeks doormelden aan het ontwikkelteam. Alternatieven zijn een gestructureerde checklist of een feedbackportaal waar testers hun bevindingen loggen.

Apple voorziet hiervoor zelfs een apart platform: TestFlight, waarmee apps in bètaversie kunnen worden uitgerold naar een geselecteerde groep testers vóór de officiële lancering in de App Store.

Wie beslist over de teststrategie?

De testmanager of QA manager bepaalt, in overleg met de klant, welke testniveaus worden ingezet en of beta testing deel uitmaakt van het traject. Die beslissing hangt af van het type applicatie, het beoogde gebruik en de gewenste kwaliteitsstandaard bij livegang.

Voor sommige organisaties is beta testing een vaste stap in elk traject. Voor anderen een bewuste keuze op basis van risicoprofiel. In beide gevallen geldt: een weloverwogen teststrategie voorkomt dure verrassingen na livegang.