De bèta-test van een website of bepaalde software is van cruciaal belang voor het latere succes ervan: testers gaan op zoek naar zwakke plekken, de stabiliteit wordt onderzocht en de uiteindelijke feedback kan het project nog aanzienlijk verbeteren. Maar wat bepaalt of zo’n beta test vruchten afwerpt? Vooral de kwaliteit van die feedback. Dat is niet altijd evident: aangezien het om een beta versie gaat, kan er heel wat misgaan en kunnen er verschillende bugs opduiken. En als de tester deze problemen niet op de juiste manier in kaart brengt en communiceert, kan er heel wat kostbare informatie verloren gaan. Idealiter voldoet de feedback dan ook aan enkele voorwaarden.
1. Vergeet niet: het is een test.
Zoals gezegd: er kunnen en zullen fouten in de bèta-versie zitten. Het is net de bedoeling dat we die vinden en wegfilteren. Stoor je dus niet aan bugs, missing links of knoppen die niet werken, maar beschouw ze integendeel als ‘eureka’-momenten. Ook niet alle content zal in deze fase al aanwezig zijn – probeer daar abstractie van te maken.
2. Neem de tijd
Goed en grondig: zo zou een test idealiter moeten gebeuren. Ga er dus niet in zeven haasten overheen, maar neem je tijd om de bèta-versie uitvoerig uit te proberen. Want alleen zo zul je er de cruciale mankementen weten uit te vissen.
3. Laat niets achterwege
Noteer alles wat niet werkt of wat jou gewoon stoort tijdens het testen: hoe meer informatie de developers hebben om mee te werken, hoe beter ze het project kunnen maken. Denk dus niet te snel dat een bepaalde opmerking banaal of overbodig is. Laat – zeker in het geval van een serie tests – ook zeker weten welke OS(-versie), resolutie en browser(versie) je gebruikt.
4. Antwoord in een traject
Omschrijf duidelijk de handeling en de fout die er het gevolg van is:
‘als ik dit command uitvoer, krijg ik een foutmelding die (…) vermeldt.’ Alleen met werkbare, concrete feedback kunnen wij gericht aan de slag – je moet er met andere woorden niet per se een verhaal rond gaan breien.
5. Maak gebruik van screenshots
Aangezien een beeld vaak meer zegt dan 1000 woorden, is het heel nuttig om te werken met screenshots.
Zo zien wij ook meteen het probleem.
6. Groepeer je feedback
Uiteraard zijn we blij met jouw feedback, maar nog een tikkeltje blijer als we die gebundeld krijgen, zodat we die gemakkelijker kunnen verwerken. Bij losse opmerkingen kan er altijd eentje tussen de mazen van het net glippen, en dat is uiteraard niet de bedoeling. Maak dus al zeker een onderscheid tussen algemene elementen (bijvoorbeeld fouten in de navigatie) en specifieke zaken (zoals fouten op bepaalde pagina’s).
7. Alle feedback is welkom
Ben je geen digital wizard? Dat is ook absoluut niet nodig: daarom werken we nu eenmaal met meerdere testers. Intuïtieve feedback is even welkom als gespecialiseerde input – soms is die zelfs beter, omwille van de frisse kijk van de ‘leek’.
8. Wees een beetje discreet
Het is een bèta-versie, dus er zullen per definitie fouten in zitten.
We zouden het dan ook erg appreciëren als je deze versie niet gaat delen of verspreiden via Twitter, Facebook, een blog… – we doen er immers alles aan om uiteindelijk tot de best mogelijke versie te komen.
9. Verwacht je aan een aangepaste timing
Om foutjes in een testomgeving te corrigeren, maken we een planning, zodat we alle feedback samen en gerichter kunnen aanpakken. Deze timing zal dan ook afwijken van degene die je gewend bent – aanpassingen in een testomgeving kunnen nu eenmaal geen voorrang krijgen op een live project.
10. Volg onze checklist
We winnen allebei tijd als je niet in het wilde weg gaat testen. Daarom stellen we voor elk project een checklist/vragenlijst op met
handelingen die je zeker zou moeten uitvoeren. Wanneer je die als guideline gebruikt, zal de testfase een stuk efficiënter
verlopen. Maar uiteraard kan je ons altijd opvallende zaken melden die buiten dit traject vallen.
Heb je deze vuistregels graag bij de hand? Download onze bèta-bijbel!
Ben je geselecteerd als bèta-tester? Neem dan je rol heel serieus: je bent niet voor niets uitverkoren. Maar ga tijdens het traject voor helderheid, door te allen tijde het KISS-principe (Keep It Simple, Stupid) te hanteren. Waar stel je problemen vast en hoe communiceer je die zo helder en eenduidig mogelijk aan de developer, zodat die ermee kan werken?
Denk daar eens over na, aan de hand van deze tips (die uiteraard geen wet zijn, aangezien elke project uniek en dus anders is). Wie weet schakelt het bedrijf je in de toekomst opnieuw in voor een beta test, of geniet je van één van hun incentives?