Bugtesten: verbeter met eindgebruikers de kwaliteit van je kanaal

Voor het succes van je digitale product of dienst is het belangrijk om je eindgebruiker te betrekken bij de doorgaande ontwikkeling ervan. Dit doe je door de eindgebruiker kritisch te laten kijken naar de functionaliteiten en gebruiksvriendelijkheid van je app, website of software. Crowdtesting is hiervoor een ideale oplossing. Ik noemde in mijn artikel ‘Crowdtesting: zo zet je de eindgebruiker écht centraal’ drie manieren waarop crowdtesting je digitale product verder kan helpen. Een van die manieren was bugtesten en vandaag ga ik hier wat dieper op in.

Stel, je bent op zoek naar een boek en je vindt ‘m online na een korte zoektocht. Twee vertrouwde webshops die het direct leveren en het prijsverschil tussen beide is een euro. Je klikt op de goedkoopste optie, stopt het boek in de winkelwagen, drukt op afrekenen en krijgt… een foutmelding. Je gaat terug, probeert het opnieuw en weer dezelfde foutmelding. Wat doe je? Voor mij is de keuze snel gemaakt: ik geef die extra euro bij de andere aanbieder uit.

Binnen en buiten de lijnen

Bugs zijn functionele fouten in software. Als ze voorkomen in webshops, apps en andere software, kunnen ze het verschil maken tussen of een klant een aankoop doet, of dat hij naar de concurrent stapt. Het is niet eenvoudig om zulke fouten eruit te halen, maar testen is hierbij van groot belang. Bugtesten zijn erop gericht om functionele fouten te lokaliseren. Dit kan op meerdere manieren, maar twee van de meest gangbare methoden zijn structured testing en exploratory testing. Je zou het zo kunnen zien dat je bij eerstgenoemde binnen de lijnen blijft en bij laatstgenoemde buiten de lijnen op onderzoek uit gaat.

1. Binnen de lijnen: gestructureerde bugtesten

Bij structured bugtesting gaat de tester uit van een specifieke use case, zoals de aanschaf van een boek. Aan de hand van een script wordt de tester door de use case heen geleid, maar vaak heeft de tester de vrijheid om binnen dit script naar eigen inzicht tot het einddoel te komen. Een voorbeeld van een use case binnen een gestructureerde bugtest:

In deze specifieke use case wordt er bekeken of de filtering goed werkt naar het inzicht van de tester. Ziet de tester bijvoorbeeld boeken die niet binnen een bepaalde genre of leeftijdscategorie passen? Verschijnen misschien andere productsoorten binnen een specifieke filtering? De resultaten van de filters wil je volledig laten aansluiten bij de verwachtingen van de klant.

2. Buiten de lijnen: exploratieve bugtesten

Deze vorm van bugtesten werkt, in tegenstelling tot gestructureerde bugtesten, niet met afgebakende scripts. Het grote voordeel hiervan is dat bij de tester keuzevrijheid gestimuleerd wordt. De tester bepaalt zelf het pad om tot een doel te komen, dat hij of zij tevens zelf definieert. Zo ontstaat er ruimte voor de tester om, allereerst, alternatieve customer flows te ontdekken en te proberen. Ten tweede maakt de keuzevrijheid mogelijk dat de tester op zoek gaat naar fouten en onduidelijkheden buiten vooraf bepaalde kaders. Tot slot stelt het de tester in staat een persoonlijke interpretatie te geven op het geheel. Exploratief testen leidt zo tot waardevolle resultaten die buiten de gebaande paden ontdekt worden.

3. Gecombineerd: gestructureerd en exploratief testen

Uiteraard kan voor use cases ook een combinatie van gestructureerd en exploratief testen toegepast worden, waarbij de opdracht wel binnen een gezet kader plaatsvindt, maar het einddoel open is. Een voorbeeld:

Dit voorbeeld toont dat de tester in het begin nog begeleid wordt met specifieke opdrachten. De tester moet afbeeldingen bekijken en inzoomen. In de laatste opdracht is de instructie echter open.

Gevonden bugs op je pad

Als de tester een fout vindt, is het van belang dat alle stappen duidelijk geregistreerd worden, zodat kan worden bekeken wat er aan de fout ten grondslag ligt en of de fout te reproduceren is. Op welk soort device komt de fout voor? In wat voor browser? De fouten kunnen na registratie worden gecategoriseerd en geclassificeerd, want de ene bug is de andere niet. Zo kan het zijn dat een bestelformulier niet wordt geladen (laadfout), tekst of een afbeelding niet goed uitgelijnd staat (weergavefout), iets niet goed geschreven is (spelfout) of vertaald (taalfout). Ook kan het zijn dat een pagina opeens niet werkt (crash) of er een onverwachte foutmelding wordt geretourneerd (error/foutmelding). Ook de ernst verschilt per bug. Een weergavefout waarbij een plaatje niet goed uitgelijnd is, weegt minder zwaar dan een knop in de winkelwagen die een foutmelding oplevert. De prioriteit is dan laag in het eerste geval, maar kritiek in het tweede geval. Het loont om een overzicht van iedere gevonden bug te hebben, die je product owner in toekomstige sprints mee kan nemen.

Crowd lust bugs rauw

De resultaten die worden verzameld met bugtesten geven op deze manier uitermate veel inzichten over de kwaliteit van je digitale toepassing en of de functionaliteiten van jouw app, website of software probleemloos werken voor je klanten. Er zijn verschillende manieren die je kunt inzetten om bugs te vinden en te voorkomen. De scripts die voor gestructureerde testen worden ingezet, zijn ook toe te passen binnen een geautomatiseerde setting bijvoorbeeld. Als het budget en de resources het toelaten, dan kan automatisering een efficiënte oplossing zijn, zeker voor gestructureerde testen.

Wil je exploratief testen, dan kun je eigenlijk niet om de eindgebruiker heen. Vergeet niet dat digitale toepassingen door en voor mensen worden gemaakt. Door crowdtesting (aanvullend) in te zetten, krijg je direct feedback van je doelgroep: eindgebruikers die testen op eigen devices. Dit maakt het mogelijk om, afhankelijk van je criteria en requirements, op iedere type device en besturingssysteem te kunnen testen.

Linksom of rechtsom

Fouten wil je vermijden en om dat te doen moet je testen. Daar kan je klein mee beginnen door zelf eens kritisch je website te bekijken op verschillende devices en schermgroottes en te onderzoeken of alles goed wordt weergegeven. Ook kun je avontuurlijk rondklikken om te zien of je bij iedere klik het verwachte resultaat te zien krijgt. Waardevoller is het echter om hier hulp bij in te schakelen. Ook dat kan al klein. Google biedt bijvoorbeeld vrij beschikbare testing-tools die je in kunt zetten om te checken of je website mobiel-vriendelijk is en of het snel genoeg laadt. En uiteraard heb je ook voor crowdtesting self-service tools, waarbij je zelf crowdtesters naar je digitale product of dienst laat kijken.

Kortom, genoeg mogelijkheden om fouten te voorkomen. Rest alleen nog de vraag: welk pad sla jij in voor het testen?

Headerfoto: William Iven via Unsplash