UX Testing in Agile teams

Auteur: Kimberly Snoyl  ● kimberly.snoyl@capgemini.com

Redactie: Eric Spaargaren en Paul Beving

Mijn naam is Kimberly Snoyl en ik ben sinds 2014 werkzaam als tester bij Capgemini. Vanwege mijn MSc in Interaction Design ben ik altijd erg geïnteresseerd in de User Experience (UX). Ik heb daarom in 2016 ook een Meetup groep ‘Ladies that UX’ in Utrecht opgericht. Als softwaretester viel mij de afgelopen zes jaar een aantal dingen op. Welke dingen zijn dat?

A. Er is altijd sprake van tijdsdruk in Agile ontwikkelteams, vooral als tester, aangezien je pas echt kunt testen wanneer de functionaliteit opgeleverd is.

B. Als tester is de focus voornamelijk om te testen of de nieuwe functionaliteit voldoet aan de vooraf gestelde eisen. De rol wordt ook wel ‘functioneel tester’ genoemd.

Vanwege mijn achtergrond in Interaction Design miste ik de eindgebruiker in mijn werk: we krijgen een opdracht van de business en het ontwikkelteam bouwt de functionaliteit. Als je geluk hebt, is er een UX Designer betrokken in het team en mag je soms Usability Testen bijwonen, maar zelf hebben we nauwelijks contact met de eindgebruiker, op de Gebruikers Acceptatie Test (GAT) na – en dan is het al te laat.

De focus van de GAT is om de release te accepteren en te controleren of de functionaliteit voldoet, terwijl je de gebruikers al voor de ontwikkeling erbij moet betrekken om te weten of überhaupt behoefte is voor wat je gaat bouwen en tijdens de bouw ervoor te zorgen dat wat je bouwt ook voldoet aan wat de gebruikers nodig hebben en of het wel intuïtief is in gebruik.

Ik vind de betrokkenheid van de eindgebruiker belangrijk en vond dat veel te weinig terug in mijn werk. Daarom ben ik mij gaan focussen op de UX aspecten die ik wél kon meenemen in het testen. Ten eerste heb ik me aangesloten bij de Usability Testing Guild bij Capgemini. We gaven presentaties om onze collega’s bewust te maken van het belang van Usability Testing en hebben er uiteindelijk ook een cursus Usability Testing voor opgezet.

Helaas werd ik als tester nog steeds niet of nauwelijks betrokken bij Usability Testing bij de klant, omdat ik in het ontwikkelteam zat en de Usability Testen plaatsvinden in de Design-fase, dus vóór de ontwikkeling.

Uiteindelijk ben ik in aanraking gekomen met Accessibility Testing en daar kon ik wél mijn hart ophalen. Dit is zeer geschikt voor de ontwikkelfase. Je kunt bijvoorbeeld toetsenbord toegankelijkheid testen of de applicatie door een screenreader halen. Ook zijn er verschillende tools om het contrast en het correct gebruik van code te controleren.

Toegankelijkheid wordt, net als andere UX aspecten, vaak door de business niet als meest belangrijk gezien en komt daardoor in de ‘nice to have’ bak, wat uiteindelijk betekent dat het nooit wordt gerealiseerd. Vaak is dit ook door onwetendheid: ze denken dat het heel moeilijk of duur is om een website toegankelijk te maken, maar dit hoeft niet duur te zijn. Ook weten ze niet om hoeveel mensen het gaat, maar dit is al gauw 25% van de Nederlandse bevolking die geen gebruik kan maken van websites en apps als deze niet gebouwd worden.

Ik vind het belangrijk dat testers weten dat de ‘niet functionele kwaliteitsattributen’ niet vergeten moeten worden. Niet alleen functionaliteit is belangrijk, maar ook de ervaring die hoort bij het gebruik van het product. Je kunt als team bijvoorbeeld ook een uurtje per sprint besteden aan Exploratory Testing en daarbij de applicatie gebruiken alsof je een gewone gebruiker bent. Voordeel hiervan is dat er geen script vereist is en dat iedereen het kan doen.

Om dit gemakkelijk te maken voor testers, heb ik een lijst van UX Testing technieken opgesteld. Voor een uitgebreide versie kun je mijn artikel op LinkedIn lezen. Voor dit artikel heb ik de technieken opgenomen die mij het meest aanspreken:

  1. Usability Testing: wordt meestal door UX Designers gedaan, maar vaker dan je denkt zijn er geen UX Designers in het team en kun jij als tester deze rol op je nemen. Cross functional teams: laten we niet alleen in rollen en silo’s denken, maar ontwikkel je als een breed inzetbare kracht (Pi shape).
  2. Accessibility Testing, zoals eerder genoemd. Je kunt hiervoor de WCAG checklist gebruiken.
  3. Heuristieken van Nielsen: checklist van tien heuristieken welke je gemakkelijk erbij kan pakken tijdens een drukke sprint. Je zou deze checklist wellicht ook kunnen automatiseren.
  4. Exploratory Testing, zoals eerder besproken.
  5. Gebruik Persona’s in user story’s: dus in plaats van ‘as a user I want X so that I can do Y’, maar meteen ‘As Eric, I would like to be able to find the help page at any time so that I can look up how to use the app’ en hiermee dek je impliciet ook meteen waarom Eric deze functionaliteit wil, want als je Eric kent, dan weet je dat hij niet zo bekend is met apps en daarom graag een uitlegpagina wil kunnen vinden als hij vastloopt (dat staat in de persona die bij Eric hoort).

De belangrijkste boodschap die ik met dit artikel mee wil geven is dat wij als testers niet moeten vergeten om ook de User Experience in acht te nemen bij het ontwikkelen en testen van een applicatie. Soms kan dat zelfs belangrijker zijn dan goed werkende functionaliteit. Je website kan functioneel helemaal zijn getest, maar nog steeds kunnen gebruikers gefrustreerd zijn. Bijvoorbeeld: je klikt op een link en je komt op een pagina met een foutmelding ‘Error500: excuses, deze pagina is niet beschikbaar’. Dan is er misschien wel een mooie pagina bedacht voor deze omstandigheden, maar de foutboodschap is niet gebruiksvriendelijk. Gebruik nooit foutcodes wanneer je met de gebruikers communiceert. Maak er een minder technische boodschap van en nog mooier: zeg dat er automatisch een bericht wordt gestuurd naar het development team bijvoorbeeld. Zoiets maakt een gebruiker juist blij: ‘Hé, ze zijn op de hoogte dat het niet werkt en ze gaan er wat aan doen!’. Op deze manier maak je het contact met de gebruiker en word je menselijk en benaderbaar. Want dat is één van de belangrijkste zaken als het om UX gaat: we willen niet dat onze gebruikers gefrustreerd zijn, maar juist dat ze het leuk vinden om onze applicatie te gebruiken en terug willen keren of het willen aanbevelen.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *