Je testprogramma staat of valt bij de betrouwbaarheid van testen. Met een QA proces (Quality Assurance) waarborg je de kwaliteit en implementatie van een A/B test. We kunnen met geavanceerde data analyse de betrouwbaarheid van de testen berekenen. Hierbij is het belangrijk dat gebruikers daadwerkelijk de variant van een A/B test hebben gezien. Om hier zeker van te zijn is een goed QA-proces belangrijk, in dit artikel leggen Developer Bas Boland en Lead User Experience Expert uit hoe je deze kwaliteit kan waarborgen.
Er zijn veel verschillende test tools in omloop, ieder met hun eigen manier om een preview van de test te bekijken. De preview mode van de testing tools is niet altijd betrouwbaar. Soms worden veranderingen anders weergegeven, wordt de test op het verkeerde moment geladen, bevat het bugs, of wordt de test überhaupt niet geladen. Dit heeft te maken op welke manier de test geladen wordt in de preview mode en hoe deze uiteindelijk geladen wordt wanneer de test live gaat. Het liefst wil je zo dicht mogelijk in de buurt komen van de daadwerkelijke test.
We proberen daarom de preview mode zo veel mogelijk te vermijden en gebruiken een andere methode om te testen: de QA cookie. Door de QA cookie te gebruiken zien we wat de daadwerkelijke gebruiker te zien krijgt, dus weten we met zekerheid dat de test correct draait.
Testen met de QA cookie in QA proces
Tijdens ons QA proces zetten we eerst de nieuwe variant in de test op 100%.
En vervolgens zetten we bij Audience targeting Cookie QA = true.
Dit betekent dat we de test live kunnen zetten zonder dat onze bezoekers iets te zien krijgen, alleen wijzelf als we de cookie gebruiken.
De cookie aanmaken
Om de QA-cookie te maken, volg je de volgende stappen:
- Open een webbrowser.
- Ga naar een willekeurige website.
- Maak een bladwijzer aan.
- Noem het ‘QA cookie’.
- Zoek de bladwijzer knop die je net hebt gemaakt.
- Klik met de rechtermuisknop en kies Bewerken/Aanpassen/Eigenschappen.
- Plak javascript:document.cookie=’QA=true;path=/’ in het URL-veld zoals getoond in de screenshot hieronder.
- Druk op opslaan.
javascript:document.cookie=’QA=true;path=/’
De QA cookie gebruiken in QA proces
Om de cookie vervolgens te gebruiken ga je naar de pagina waar de test op draait en druk je op de cookie in je favorieten.
Vervolgens zie je als je Google Chrome gebruikt het volgende op je scherm:
Dit betekent dat de cookie ingesteld is. Wanneer je de pagina herlaadt door op de refresh knop te drukken, zal de oorspronkelijke pagina weer geladen worden en worden de wijzigingen zichtbaar.
Niet alle browsers hebben hetzelfde gedrag wanneer je op de knop drukt. In onder andere iOS Safari zie je geen feedback na de druk op de knop. In dit geval kun je, nadat je op de knop hebt gedrukt, de pagina meteen refreshen en worden de wijzigingen zichtbaar.
Devices
De weergave van een test op verschillende apparaten en browsers komt niet altijd overeen. Chrome en iOS Safari hebben bijvoorbeeld regelmatig kleine verschillen, waardoor een experiment dat er goed uit ziet bij de één niet altijd probleemloos werkt bij de ander. Zo heeft iOS Safari bijvoorbeeld vaak problemen met het scrollen van elementen binnen de pagina en schaduwen. Wij testen daarom onze testen op verschillende browsers en apparaten, zoals Windows, Mac, Android en iOS.
Natuurlijk heeft niet iedereen alle apparaten tot zijn/haar beschikking. Daarom gebruiken wij naast de fysieke apparaten ook BrowserStack, een online tool die de gebruiker de optie geeft om te testen op allerlei systemen.
Dependencies, timing en flicker effecten
Wanneer een experiment clientside wordt geladen is de timing essentieel: als het te vroeg geladen wordt is de oorspronkelijke code of het element nog niet geladen en kan de aanpassing niet worden toegepast. Als het te laat wordt geladen heb je kans op een flicker effect. Dit betekent dat je eerst het oude element ziet, en vervolgens na een korte pauze pas het nieuwe element. Als dit binnen een paar milliseconden gebeurt, is dit niet hinderlijk en vaak niet eens waarneembaar. Is dit bijvoorbeeld een seconde dan is het wel waarneembaar en heeft het effect op de User Experience en dus op het resultaat van het experiment.
Om de dependencies, timing en flicker effecten te controleren kun je de snelheid van je internetverbinding tijdelijk verlagen, dit noemen we throttling. Dit kun je doen in de developer tools van je browser, hieronder Google Chrome. Op deze manier kun je zien of de test in de juiste volgorde geladen wordt en of de code netjes op elkaar wacht voor het uitgevoerd wordt.
Als je problemen hebt met flicker effect, is het goed om te controleren of je snippet van je test tool zo vroeg mogelijk op de pagina wordt geladen. Het best is daarom om de snippet in de head van je HTML te plaatsen.
Events in console
Een bijkomend voordeel van deze manier van testen is dat het mogelijk is om de cookiewaarde te lezen met een eenvoudig stukje code en vervolgens alleen console.log berichten te sturen wanneer de cookie bestaat.
Hieronder zie je onze implementatie, waar we een aangepaste console.log sturen met andere vormgeving en testId zodat het zeer eenvoudig is om te zien welke berichten door onze testen worden gegenereerd.
Elk event dat wij tracken, krijgt ook een output in de console, zodat we stapsgewijs door de hele test kunnen lopen en zien welke events er worden verstuurd.
… Even tussendoor: we sturen elke drie weken een nieuwsbrief met daarin de laatste blogs, teamupdates en natuurlijk nieuws over het aanbod in onze academy. Klik hier om je in te schrijven.
Kwaliteit
Wat is nu kwaliteit als je het hebt over Quality Assurance? Uiteindelijk wil je dat een test betrouwbaar is ontwikkeld zodat je met zekerheid kan zeggen dat je experiment goed is uitgevoerd. Daarbij wil je bugs, flicker effecten en dependencies uit kunnen sluiten en met zekerheid kunnen zeggen dat je test visueel correct geladen wordt, de events binnen komen en de targeting aansluit op het experiment en hypothese.
Gebruik hiervoor onze checklist. Wil je deze checklist ontvangen, neem dan contact met ons op.
