Tests voor je webshop: nice-to-have of musthave?

Je verwacht eigenlijk gewoon dat je webshop het altijd doet, net als je auto. Totdat er iets hapert of je een vreemd geluid hoort. Auto’s zijn complexe voertuigen vol bewegende en slijtende onderdelen die, ondanks regelmatig onderhoud, toch af en toe mee op kunnen houden. Dit is vergelijkbaar met een webshop. Een webshop is doorgaans een grote applicatie die bestaat uit het framework zelf (zoals Magento), code van derde partijen (zoals Magento modules uit de marketplace), en maatwerk (zoals een integratie met een ERP). Dit zou je kunnen zien als een auto met alle verschillende onderdelen, verbindingen en afhankelijkheden. Als je ergens een kleine verandering maakt in de applicatie kan dat onverwachte problemen veroorzaken.

We ontkomen er niet aan dat de code van een webshop aangepast moet worden. Aan de ene kant raakt software verouderd en zijn updates nodig om te voldoen aan de laatste security standaarden en bug fixes, aan de andere kant gaat het om nieuwe features zoals een loyaliteitsprogramma of nieuwe productconfigurator. Door regelmatig en consistent te testen, valideer je dat de belangrijkste functionaliteiten van een webshop na dit soort aanpassingen blijven werken.

Toch zien veel bedrijven testen als een bijzaak. Het kost tijd en geld, en zolang alles lijkt te werken, lijkt het niet nodig. Maar wat als een kleine aanpassing ervoor zorgt dat je checkout uitvalt? Of je voorraadbeheer niet meer klopt? Dan zijn de kosten van niet testen opeens veel hoger dan de investering in een goed testproces. In dit artikel gaan we in op de noodzaak van testen, het verschil tussen de soorten tests, de voor- en nadelen en wanneer je welke test inzet.

Wat voor soort test je schrijft hangt af van de soort functionaliteit die je wilt testen. Bij Bluebird Day werken we met de volgende tests, die samen ook wel de ‘test pyramid’ worden genoemd:

1. Handmatige tests

2. End-to-end tests

3. Integratietests

4. Unit-tests

Deze tests worden samen ook wel de ‘test pyramid’ genoemd. Hieronder gaan we op elke tests dieper in en beantwoorden we vragen als: waarom, wanneer en hoe je de test inzet voor jouw platform.

1 - Handmatige tests

Deze tests bestaan uit een set gebruikersinstructies en een checklist, die een persoon moet doorlopen en vaak aangevuld met documentatie en screenshots. In sommige gevallen zijn er ook screen captures (een korte schermopname van deze handelingen die in de webshop worden uitgevoerd) ter verduidelijking toegevoegd. Het schrijven en doorlopen van deze tests is vrij arbeidsintensief. Daarom schrijven wij deze tests alleen voor de essentiële basisfunctionaliteiten van een webshop, denk aan: de productdetailpagina, categoriepagina, checkout, winkelwagen en bepaalde onderdelen van ‘mijn account’. Hiernaast schrijven we in overleg met de klant ook testplannen voor grote of belangrijke (maatwerk)functionaliteiten zoals de productgroepen bij onze klant Fortune Coffee of de zoekfunctie voor CMS-pagina’s bij Dyka en Fortune Coffee. Het is goed om deze testplannen te documenteren. Wij doen dat bijvoorbeeld in Confluence, waar we voor elke klant een workspace onderhouden. Bij elke minor en major update van het platform doorlopen wij en de klant zelf deze tests.

Waarom en wanneer zou je deze handmatige tests inzetten? We zien een toegevoegde waarde in deze tests, omdat je goed vastlegt wat je wel (en dus niet test) en iedereen aan de hand van dezelfde acceptatiecriteria test. Zonder duidelijke acceptatiecriteria zou bijvoorbeeld voor de checkout het enige criterium zijn “dat je kan afrekenen”. Dit is niet SMART geformuleerd en daardoor is er een groot risico dat belangrijke functionaliteiten niet getest worden. Je hebt bijvoorbeeld verschillende betaalmethoden (zoals iDeal en creditcard) en het kan goed zijn dat de ene wel werkt en de andere niet. Daarnaast zitten er in de doorsnee checkout veel andere belangrijke functionaliteiten zoals de optie om een account aan te maken en verzendopties die ook getest moeten worden. Hieronder zie je twee screenshots van het testplan voor de checkout van VIA VAI die een goede indruk geven van de complexiteit van een checkout:

De testpunten in dit plan zijn zo geformuleerd dat ze meetbaar zijn, het voor iedereen duidelijk is wat wel en niet getest wordt en wat de definitie is van “het werkt”. Daarnaast signaleren we - door de extra aandacht op deze functionaliteiten - soms ook andere zaken die niet goed werken of simpelweg verbeterd zouden kunnen worden. Dit zijn dingen die je niet snel zal zien als je oppervlakkig en a-systematisch test. Denk aan een foutmelding in de verkeerde taal of het niet netjes uitlijnen onder het betreffende formulierveld hiervan.

2 - End-to-end tests

End-to-end tests zijn geautomatiseerde tests die bezoekersgedrag simuleren aan de hand van een set instructies voor specifieke, veelvoorkomende handelingen. Denk aan het toevoegen van een artikel aan de winkelwagen en dit afrekenen met iDeal.

Hoe zet je zo’n test nu precies in? Je kunt zulke tests schrijven in www.endtest.io. Binnen deze webomgeving kan je uitgebreide sets aan handelingen configureren via een web interface. Deze zijn vervolgens weer onder te verdelen in testsuites (een bundel van tests) en genereren een uitgebreid verslag met screenshots en screen captures. Wij voeren deze tests dagelijks en geautomatiseerd uit voor onder andere klanten als Dyka, zie hieronder. Daarnaast worden ze ook automatisch uitgevoerd bij een uitrol naar de staging- en productieomgevingen na aanpassingen aan de webshop. In onderstaande screenshot van endtest.io zie je een reeks tests voor verschillende handelingen binnen een webshop.

End-to-end tests kunnen pas uitgevoerd worden nadat wijzigingen op een server zijn uitgerold, omdat je een functionele webshop nodig hebt om te kunnen testen. Natuurlijk wil je liever vooral testen of alles werkt, dus nog voordat je webshop live gaat. Daarom voeren wij deze tests eerst uit op een actuele, functionele kopie van de live omgeving. Als deze tests slagen, zetten we de wijzigingen live op de productieomgeving en voeren we voor de zekerheid nogmaals de tests uit op deze omgeving.

De scenario’s voor de end-to-end tests zijn vaak gebaseerd op de handmatige tests. Vaak is het doorlopen van zo’n handmatige test dan niet meer nodig. Dit scheelt een hoop tijd en bovendien is zo’n test consistenter omdat je het menselijke aspect weglaat. Deze tests zijn wel redelijk gevoelig voor wijzigingen en moeten in dat geval aangepast worden.

3 - Integratietests

Integratietests zijn geautomatiseerde tests die in code geschreven worden en die delen van een applicatie testen. Software bestaat uit verschillende functionaliteiten die met elkaar verbonden zijn. Op het moment dat een klant een order plaatst in een webshop dan gebeuren er een heleboel dingen. Zo wordt bijvoorbeeld de winkelwagen omgezet naar een order en geleegd, een bevestigingsmail verzonden naar de klant en de voorraden van die producten bijgewerkt. Daarnaast vinden er nog veel meer processen plaats, die je goed zou kunnen testen met een integratietest.

Laten we er een voorbeeld bijpakken. Stel dat je klanten punten sparen na het doen van een aankoop en deze later kunnen verzilveren, dan worden deze punten in de database opgeslagen. Om dat goed te testen, kun je een integratietest schrijven. Hierbij plaats je een order om te valideren dat de punten goed bijgeschreven worden. Dat doe je door in de test een artikel aan te maken waar je 100 punten mee kunt sparen en een order met dit artikel te plaatsen. Dit wordt volledig met code gedaan. Vervolgens valideert de test of de punten daadwerkelijk opgeslagen zijn in de database. Dit is niet of heel lastig te testen met een end-to-end test omdat deze tests niet in de database kunnen ‘kijken’ en ook geen producten met punten kunnen aanmaken (dit is uiteraard alleen door de beheerder van de webshop te doen). Met een integratietest heb je dit probleem niet, omdat je meer controle hebt over deze aspecten. Je voegt immers zelf een product toe met een bepaald aantal punten en je bent niet afhankelijk van of je het aantal punten in de checkout kunt zien, omdat je in de database kunt kijken. De grondslag voor zo’n test is vrij duidelijk: punten vertegenwoordigen geld en daarom wil je goed testen dat een klant bijvoorbeeld niet onbeperkt punten kan verdienen door in zijn browser steeds heen en terug te gaan naar de checkout.

Wanneer maak je geen gebruik van integratietests? In de productieomgeving. In het bovenstaand voorbeeld wil je niet dat er zomaar een product wordt aangemaakt en een order geplaatst wordt op een productieomgeving. Deze tests draaien daarom altijd op een actuele en functionele kopie van de live omgeving. Nieuwe aanpassingen aan de webshop kunnen niet live gezet worden als deze tests niet slagen. Net als end-to-end-tests worden integration tests ook geautomatiseerd uitgevoerd bij elke wijziging aan de webshop.

4 - Unit-tests

Dan de laatste: de unit tests. Dit is een stukje code dat één specifiek stukje code in de applicatie test. Hoe dit werkt is het best uit te leggen aan de hand van een metafoor: een testbank voor een brandstofpomp. In deze metafoor is de brandstofpomp de unit-test en de pomp de functionaliteit die we willen testen.

Een brandstofpomp zorgt ervoor dat een verbrandingsmotor op het juiste moment in de juiste hoeveelheden brandstof krijgt. De brandstofpomp wordt aangestuurd door de boordcomputer van de auto die de pomp exact vertelt hoeveel brandstof nodig is. Voor een fabrikant van brandstofpompen is het praktisch als hij zijn pompen eenvoudig kan testen zonder deze eerst steeds in een auto in te bouwen. Dat zou efficiënt noch rendabel zijn. Daarnaast zou het hele merkwaardige situaties opleveren zoals auto’s die met 120 km per uur rondjes door de fabriekshal rijden om de brandstofpomp bij die snelheid te kunnen testen. Ook kan de technische staat van die voertuigen de werking van de brandstofpomp negatief beïnvloeden.

Bij een unit-test wil je altijd volledige controle over de invoer hebben en daarbij valideren of de uitvoer overeenkomt met wat je verwacht. Met zo’n testbank kan de fabrikant precies dat doen. Met een unit-test doen wij hetzelfde in de code. We kunnen bijvoorbeeld een stukje code testen dat het totaalbedrag van een order berekent, zonder dat we eerst een klantaccount aan moeten maken en een order moeten plaatsen.

Unit tests zijn doorgaan snel te schrijven en toe te passen bij projecten. Doordat we de tests steeds automatisch uitvoeren bij wijzigingen in de code verkleinen we de kans dat bepaalde functionaliteiten ongemerkt omvallen; Als een test faalt, kan die code namelijk niet live gezet worden. Voor unit-tests is - in tegenstelling tot handmatige tests, end-to-end tests en integratietests - geen complete en functionerende kopie van de webshop nodig: enkel het stukje code dat getest wordt is noodzakelijk om de test te draaien.

Daarnaast kunnen unit-tests zelfs de ontwikkeltijd helpen verkorten. Developers hoeven geen complexe situaties na te bootsen om verschillende scenario’s te testen maar kunnen die eenvoudig simuleren.

Zoals je hierboven hebt kunnen lezen, kun je elke test op verschillende manieren inzetten. Zo hebben ze ook allemaal eigen voor- en nadelen. Hieronder vatten we eens goed samen voor de handmatige, end-to-end, integratie en unit tests welke dit precies zijn.

Handmatige test

Voordelen:

• Overzichtelijk wat er (niet) getest wordt.

• Iedereen test a.d.h.v. dezelfde instructies.

• Omdat deze handmatig worden getest heb je ook de context waarom iets mogelijk niet of wel werkt.

Nadelen:

• Het kost veel tijd om ze te schrijven, onderhouden en te doorlopen.

• Testpunten kunnen aan interpretatie onderhevig zijn.

• Je kan per ongeluk onderdelen overslaan of verkeerd testen.

• Worden enkel bij minor en major updates doorlopen omdat het zo arbeidsintensief en dus kostbaar is.

End-to-end test

Voordelen:

• Worden geautomatiseerd uitgevoerd wat veel tijd scheelt.

• Worden bij elke codewijziging uitgevoerd.

• Configureerbaar via een webomgeving.

Nadelen:

• Het kost veel tijd om ze te schrijven.

• De tests zelf kunnen falen bij wijzigingen in de html of code en moeten dan aangepast worden.

• Je bent beperkt in wat je kunt testen.

• Je betaalt een vergoeding aan endtest.io.

Integratietest

Voordelen:

• Veel controle over data en wat je test.

• Worden geautomatiseerd uitgevoerd wat veel tijd scheelt.

• Worden bij elke codewijziging uitgevoerd.

Nadelen:

• Het kost veel tijd om ze te schrijven.

• Het draaien van de tests kost veel tijd en er moet een aparte testomgeving bijgehouden worden.

Unit-tests

Voordelen:

• Veel controle over data en wat je test.

• Worden geautomatiseerd uitgevoerd wat veel tijd scheelt.

• Worden bij elke codewijziging uitgevoerd.

• Heel snel te schrijven.

• Kunnen de ontwikkeltijd verkorten.

• Kosten weinig tijd om uit te voeren.

• Geen aparte testomgeving nodig.

Nadelen:

• Test geen onderdelen (integraties); testen die slagen bieden geen volledige garantie dat alle onderdelen samen wel werken.

Bij ons is testen een belangrijk onderdeel van het ontwikkelproces. Een klant verwacht vanzelfsprekend van ons dat zijn webshop goed blijft werken na wijzigingen, en dat vraagt van ons een passend testbeleid. Tests zijn voor ons het instrument om kwaliteit te waarborgen. Als je besluit om niet te testen is er een groot risico dat een webshop bij een minor of major update niet goed werkt. Dat kunnen triviale zaken zijn zoals een afbeelding die niet getoond wordt maar er kunnen ook ernstiger problemen optreden. Hierbij kun je denken aan integraties met een ERP die niet (goed) meer werken waardoor orders niet verwerkt worden. Of klanten die niet meer kunnen afrekenen omdat de betaalstatus van orders niet aangepast wordt na het afrekenen. Maar je kan hierbij ook denken aan niet functionerende “store switcher” waardoor bezoekers uit Nederland bijvoorbeeld de Deense variant van je webshop te zien krijgen.

Wij schrijven bijvoorbeeld standaard bij elk project unit-tests, omdat deze snel te schrijven zijn en veel bugs kunnen voorkomen. De ontwikkelkosten voor deze tests zijn daardoor minimaal. Daarnaast vinden we het belangrijk om gebruikerstests te doorlopen bij minor en major updates. Zonder deze tests kunnen we anders niet garanderen dat de belangrijkste functionaliteiten van de webshop correct functioneren. Als een klant kiest voor end-to-end tests kunnen de handmatige tests overgeslagen worden, waardoor we ook en kan de doorlooptijd van een minor of major update aanzienlijk verkorten. De kosten voor het ontwikkelen van deze tests verdien je dan al snel terug. Andere tests die zichzelf terugverdienen zijn de integratietests. Hiermee testen we functionaliteiten of specifieke onderdelen, die je niet met een end-to-end test kan testen.

Het ontwikkelen van tests kan ten koste gaan van de ontwikkeling van nieuwe features. Dat kan bij sommige klanten een belemmering zijn om tests te laten ontwikkelen, omdat het belang van een nieuwe feature soms groter lijkt. Daarentegen zie je dat bugs vaak ook veel tijd en geld kosten en daarnaast frustratie kunnen geven bij bezoekers van de webshop.

Als je de juiste balans vindt tussen wat je wel en niet test en wat voor soort tests je toepast, dan vallen die kosten enorm mee. Daarnaast werken wij natuurlijk ook het liefst aan nieuwe, conversieverhogende features die onze klanten helpen te groeien en is er dus op dit vlak een gemeenschappelijk belang om die balans te vinden.

We kunnen ons voorstellen dat je na het lezen van dit artikel nog vragen hebt. Het is wellicht lastig voor te stellen wat dit nu in de praktijk voor jouw webshop betekent. Daarom gaan we graag met je in gesprek om deze vragen weg te beantwoorden en om samen in goed overleg te bepalen hoe we de kwaliteit van jouw webshop het beste kunnen waarborgen.

Neem contact op