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 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 u 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 uw tijd
Goed en grondig: zo zou een test idealiter moeten gebeuren. Ga er dus niet in zeven haasten overheen, maar neem uw tijd om de bèta-versie uitvoerig uit te proberen. Want alleen zo zult u er de cruciale mankementen weten uit te vissen.
3. Laat niets achterwege
Noteer alles wat niet werkt of u 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 een serie tests, ook zeker weten welke OS(-versie), resolutie en browser(versie) u 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 – u 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, kunt u ook werken met screenshots.
Zo zien wij ook meteen het probleem.
6. Groepeer uw feedback
Uiteraard zijn we blij met uw 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
Bent u 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 u 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 u 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 u 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 u niet in het wilde weg gaat testen. Daarom hebben we een checklist/vragenlijst opgesteld met
handelingen die u zeker zou moeten uitvoeren. Wanneer u die als guideline gebruikt, zal de testfase een stuk efficiënter
verlopen. Maar uiteraard kunt u 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: het bedrijf heeft je niet voor niets geselecteerd. 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 er mee 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?