Steeds vaker worden in projectbudgetten uren gereserveerd om een website, webshop of webapplicatie te testen. Als potentiële opdrachtgevers dit horen is hun eerste reactie vaak: ‘Dan test ik het zelf wel.’ In dit blog leg ik uit waarom je beter kunt laten testen door een tester en hoe we dit bij Netvlies aanpakken. Hiervoor gebruik ik een aantal termen die je wellicht niet kent. Daarom vind je onderaan de blog een begrippenlijst. Een tester hanteert een gestructureerde aanpak om al voor de livegang uitgebreid te testen. De kwaliteit gaat omhoog en de kans dat de eindgebruiker ergens tegenaan loopt wordt een stuk kleiner. Dat voorkomt een negatieve ervaring en, in het slechtste geval, een negatief beeld van jouw merk.
Zelf testen vs. laten testen
We merken dat klanten vaak onvoldoende tijd hebben om grondig op verschillende browsers en apparaten te testen. Ze zijn druk met het regelen van andere zaken rondom de nieuwe website en niet te vergeten hun eigen werkzaamheden. Een tester heeft wel voldoende tijd en kan, doordat hij bij hetzelfde bureau werkt, makkelijker schakelen met developers. Als niet duidelijk is hoe iets getest moet worden of wat de bevindingen van de tester betekenen, kan dit snel worden besproken. Daarnaast heeft een tester zicht op de verbanden tussen functionaliteiten en gevolgen van aanpassingen. Als je bij A iets wijzigt heeft dit gevolgen voor B. Ook hier moet je op anticiperen. De content in het Content Management Systeem wordt doorgaans door de klant zelf gevuld. Dit gebeurt vaak aan het einde of halverwege het project. Normaal krijg je op dat moment pas zicht op dingen die niet naar behoren werken. De developer moet hier weer opnieuw induiken. Door dit door een tester te laten testen, krijg je eerder zicht op problemen in het contentbeheer en kunnen deze problemen eerder worden opgelost. Met name bij een webapplicatie moeten rollen en rechten uitgebreid getest worden. Je moet zowel aan de voor- als achterkant van de webapplicatie testen of je niet meer kan dan je rechten moeten toelaten. We zien vaak dat een klant alleen zijn of haar eigen rol test. Bij livegang wordt dan pas duidelijk of andere rollen naar behoren werken. Tot slot merken we dat klanten en developers met een gekleurde bril naar het product kijken. Developers zijn dag in dag uit met het product bezig, waardoor dingen vanzelfsprekend worden. Als je iets hebt gebouwd zie je bepaalde patronen niet en beschik je over te veel voorkennis. Ditzelfde geldt voor de klant.
Rol en werkzaamheden tester
Een tester test functionaliteiten onder andere op worst case scenario’s: wat gebeurt er als er iets gebeurt dat niet in de normale flow past? Bijvoorbeeld als een gebruiker wil inloggen, maar een verkeerd wachtwoord of gebruikersnaam gebruikt. Krijgt de gebruiker informatie over wat er fout gaat of wordt hij ineens doorgestuurd naar een 404-pagina? Als tester ben je eigenlijk advocaat van de duivel. Je bent kritisch en besteed aandacht aan wat fout gaat. Met als doel de kwaliteit waarborgen.
Onze aanpak: testen tijdens Scrumproject
Als tester maak ik bij Netvlies onderdeel uit van het projectteam. We merken dat dit de lijnen kort houdt en de kwaliteit van het testwerk waarborgt. Ook onze projectmethodiek Scrum draagt hieraan bij. In korte periodes - sprints - leveren we een werkend deelproduct op. Dat stelt ons in staat om op basis van de nieuwste inzichten, zoals bevindingen van de tester, tijdig bij te sturen. Bij een waterval project is minder of zelfs geen ruimte om op de bevindingen van de tester te anticiperen. Scrum biedt meer flexibiliteit. Daarnaast kun je steeds stukjes van een product functioneel testen in plaats van in een keer het totaal product. Tijdens een Scrumproject is er geen vast testmoment, omdat de tester afhankelijk is van de voortgang van het team. Als alle onderdelen van de user story - een specifieke wens op basis van een afgekaderde functionaliteit die op basis van business value wordt ontwikkeld - klaarstaan, wordt de functionaliteit getest. Stel dat de user story een login functie is. Alle scenario’s die je als gebruiker bij een login kunt doorlopen, moeten worden getest. De expertise van een tester is zeer waardevol bij het opstellen van de scenario’s, omdat niet iedereen alle mogelijke scenario’s kent. Met het gevaar dat niet alles getest wordt. Bij een ‘simpele’ login kan het aantal scenario’s al gauw oplopen naar minimaal tien. Bijvoorbeeld:
- een succesvolle login;
- verkeerd wachtwoord ingevuld;
- verkeerde loginnaam ingevuld;
- verkeerd wachtwoord en loginnaam ingevuld;
- wachtwoord vergeten in te vullen;
- loginnaam vergeten in te vullen;
- loginnaam en wachtwoord niet ingevuld;
- proberen op een pagina te komen waar je na inloggen geen rechten toe hebt;
- proberen op een pagina te komen waar je na inloggen rechten toe moet hebben;
- en proberen op een pagina te komen waar je geen rechten toe hebt, omdat je niet bent ingelogd.
Stapsgewijs testen op alle browsers en apparaten
Om de developers en klant, die de website met content vult en inricht, niet in de weg te zitten, werkt de tester in een eigen testomgeving. De developer moet zorgen dat een user story klaar staat op deze testomgeving. Voordat de tester begint, neemt hij de Definition of Done door. Dit is een door het Scrumteam samengestelde omschrijving van een afgeronde user story. Bijvoorbeeld, in het geval van een login functie, dat een succesvolle login mogelijk is, ook als er bij de eerste inlogpoging foutieve gegevens zijn ingevuld. De tester test de user story op elke browser en op elk apparaat. Niet elke organisatie beschikt over alle browsers en apparaten die hun doelgroep gebruikt, waardoor alleen de browsers en apparaten die men zelf gebruikt worden getest. In het ergste geval blijkt na de livegang dat de doelgroep op een veelgebruikt apparaat niet kan inloggen. Een tester beschikt doorgaans over (vrijwel) elk veelgebruikt apparaat en kan dit wel vooraf testen.
Bevindingen vastleggen
De bevindingen worden op vaste wijze vastgelegd, zodat de developer precies weet wat hij waar moet aanpassen. Bevindingen worden onder andere voorzien van een screenshot en url. Om te bepalen welke bevindingen, op basis van prioriteit, eerst moeten worden opgepakt wordt onderscheid gemaakt tussen bugs, issues en optimalisaties. Bug - (Deel van) functionaliteit die niet werkt en daardoor niet gebruikt kan worden. Issue - Staat werking van functionaliteit niet in de weg, maar kan zorgen voor een negatieve gebruikerservaring. Optimalisatie - Verbetert gebruikerservaring, maar heeft geen gevolgen voor werking functionaliteit als dit nu niet wordt opgepakt. De developer moet bevindingen op basis van prioriteit aanpassen. De tester test dit opnieuw om vast te stellen of de aanpassing geen gevolgen heeft voor niet-aangepaste onderdelen. Een bug of issue is pas opgelost als de aanmelder de aanpassingen werkend heeft gezien. Laten we weer even terug gaan naar het inlog voorbeeld. De tester logt in op een webapplicatie met verkeerde inloggegevens en de webapplicatie blijft de inlogpagina tonen. Er wordt geen feedback gegeven over waarom inloggen niet lukt. De tester legt de bug vast door middel van een korte samenvatting: wat is de bug, op welke apparaten en browsers komt de bug voor, hoe kun je de bug reduceren en hoe zou het eigenlijk moeten werken. Daarnaast worden een screenshot en url toegevoegd, zodat de developer de bug makkelijk kan zien en vinden. De developer krijgt een melding en gaat aan de slag om de bug te fixen. Als hij klaar is, doorloopt de tester het scenario opnieuw. De tester logt in met verkeerde inloggegevens en krijgt een melding waarom niet kan worden ingelogd. Tot slot wordt de opgeloste bug bij de klant geverifieerd. Hiermee is de bug opgelost en de user story afgerond. 
Het testproces tijdens een Scrumproject.
Testen door een tester heeft dus een aantal voordelen ten opzichte van zelf testen. Een tester beschikt over voldoende tijd en middelen om jouw website, webshop of applicatie grondig te testen. Daarnaast kan een tester makkelijk schakelen met developers, heeft de tester een frisse blik en ziet de tester verbanden tussen functionaliteiten en gevolgen van aanpassingen. Dankzij de gestructureerde aanpak gaat de kwaliteit omhoog en is de kans dat de eindgebruiker ergens tegenaan loopt een stuk kleiner.
Begrippenlijst
Scrum - Projectmethodiek waarbij in sprints een werkend (deel)product wordt opgeleverd.
Sprint - Een periode van 2 of 3 weken, waarin we met een multidisciplinair team samen een set van wensen (user stories) oppakken.
User story - Eén specifieke wens op basis van een afgekaderde functionaliteit.
DoD - Definition of Done. Door het team samengestelde omschrijving van een afgeronde user story.