Wij weten dat de oplossingen die we maken belangrijk zijn voor onze klanten. Ze zorgen bijvoorbeeld als webshop voor een bron van inkomsten. Andere oplossingen, zoals een intranet of webapplicatie, zijn misschien wel kritisch binnen het dagelijkse werk van werknemers. Wanneer deze oplossingen niet goed werken of er ineens fouten optreden waar dit eerst niet was, kan dit erg vervelend zijn. Het kan zelfs ontzettend veel geld kosten wanneer een webshop hierdoor minder producten verkoopt of werknemers minder efficiënt kunnen werken (of zelfs tijdelijk helemaal niet hun werk kunnen doen).
Daarom proberen wij zo goed mogelijk te testen. Door middel van testen kunnen wij bugs vinden, kwaliteit verhogen, kwaliteit handhaven en daarmee kwaliteit garanderen. Door goed te testen kunnen we het vertrouwen van de eindgebruiker in de gemaakte oplossing waarborgen, zodat de klant het vertrouwen in ons als online partner blijft behouden. Maar hoe test je goed wanneer vraagstukken bijvoorbeeld groot, complex en afhankelijk van externe systemen zijn in een wereld waar we steeds meer platformen en devices krijgen en dus willen ondersteunen?
Testen is een expertise an sich
Natuurlijk testen developers hun eigen werk en kun je als klant de functionaliteit controleren aan de hand van wat er is afgestemd, maar als een project groter wordt kan het overzicht al snel zoekraken. Voorbeeld: een simpel loginformulier heeft in een bepaald geval ±15 verschillende uitkomsten aan de hand van hoe je het formulier invult, ofwel scenario’s. Zo heb je onder andere een happy flow scenario waarin de gebruiker het formulier invult zoals bedoeld is, maar je hebt ook worst case scenario’s zoals het vergeten in te vullen van een wachtwoord, het invullen van een verkeerd wachtwoord, verkeerde gebruikersnaam én wachtwoord, etc. Pak al je scenario’s en doe dit maal het aantal devices, platformen en browsers die worden ondersteund en je hebt al snel veel unieke situaties waar in theorie iets fout zou kunnen gaan. Wijzigingen of nieuwe functionaliteit kunnen impact hebben op de bestaande oplossing en daarom zouden alle belangrijke functionaliteiten nog een keer nagelopen moeten worden na een update. Maar wanneer je in de laatste kwart van het ontwikkeltraject na elke wijziging meer dan 1000 scenario’s handmatig moet doorlopen kan je wel een beetje moedeloos worden…
Geautomatiseerd scenario’s testen
Het ligt voor de hand om het nalopen van de verschillende scenario’s te automatiseren. Maar hoe past dit in het proces? Om te beginnen gaan bijvoorbeeld de ontwikkelaar, tester en klant/product owner* samen zitten om de scenario’s uit te schrijven en toe te voegen aan de user stories *. Op deze manier wordt er meer inzicht en detail aan de story toegevoegd, meer gediscussieerd en het wordt voor iedereen duidelijker wat er daadwerkelijk moet worden gebouwd. Aannames en eventuele misverstanden kunnen hierdoor worden voorkomen. Een voorbeeld van hoe zo’n sessie er uit zou kunnen zien kan je bekijken in onderstaande video:
(* Niet bekend met de Scrumtermen user stories en product owner? Bekijk onze Scrumpagina.) Belangrijk is dat deze scenario’s zo worden opgezet dat deze leesbaar zijn voor niet-technische mensen, maar door een vaste manier van schrijven ook in de gecodeerde testen kan worden meegenomen. Op deze manier is er een waarheid waar het hele team mee uit de voeten kan en maakt het dat de uiteindelijke testresultaten goed te lezen zijn. Hierdoor is het later snel vast te stellen waar eventuele problemen zich bevinden. Een bekende taal om een scenario in op te zetten is Gherkin: 
Hoe werkt dit dan in de praktijk?
Geschreven tests kunnen dagelijks worden uitgevoerd, of wanneer ontwikkelaars nieuwe code geschreven hebben en willen toevoegen aan bestaande functionaliteiten. Op deze manier krijgen ze snel feedback over dingen die dus een negatieve impact hebben op bestaande code, zodat ze dit kunnen herstellen voordat er in de ‘live’ omgeving bugs geïntroduceerd worden. Door de tests in omgevingen als Browserstack te draaien, kun je gebruik maken van alle browsers en toestellen die deze diensten aanbieden. Hierdoor zit er weinig verschil in de manier waarop de gebruiker de scenario’s doorloopt en de tests worden uitgevoerd. De dagelijkse uitvoering van tests is ook zeker handig om eventuele afhankelijkheden zoals een koppeling of API van een derde partij te kunnen monitoren. Resultaten van tests kun je in verschillende tools inzien en ook geautomatiseerd naar verschillende teamleden mailen wanneer er dingen niet goed gaan. Op deze manier zijn de juiste mensen altijd snel op de hoogte om eventueel proactief actie te ondernemen op interne en externe problemen. 
Meerwaarde
Wanneer een traject in de eindfase belandt is het fijn om op de laatste functionaliteiten of details te kunnen focussen, in plaats van bugs te moeten oplossen die in eerder gemaakte functionaliteiten zijn geïntroduceerd. Of nog erger, misschien kom je er niet achter dat er fouten in de code zijn geslopen en komt de gebruiker er zelf achter wanneer hij een product in de webshop wil afrekenen en dit lukt niet, waardoor je conversie misloopt. Het vertrouwen van de gebruiker is snel verloren en kan moeilijk terug te winnen zijn. De kans is groot dat deze bezoeker hetgeen wat hij/zij wilt kopen ergens anders gaat zoeken. Het automatisch testen is essentieel in het voorkomen van zulke situaties, zeker omdat het in grote projecten praktisch onmogelijk is om alle situaties goed handmatig te testen. Is het daadwerkelijk nodig om voor alle scenario’s tests te schrijven? Dat kan natuurlijk wel, maar kost heel veel tijd en geld. Door middel van risicoanalyse kan de tester een advies geven over welke tests daadwerkelijk geschreven moeten worden. Vitale onderdelen van de te ontwikkelen oplossing zullen hierin naar voren komen en een situatie zoals eerder geschetst zal niet meer voorkomen. Bestellen in een webshop is namelijk van cruciaal belang! Binnen kleine projecten kan de conclusie zijn dat het niet nodig is om te automatiseren en dat handmatig testen voldoende is, maar bij projecten met meerdere ontwikkel sprints en een langetermijnvisie kun je eigenlijk niet zonder geautomatiseerde tests. Ja, initieel kost het geld om tests te automatiseren. Het is echter wel van cruciaal belang als je geen risico wil lopen op rework en bugfixes, waarmee vertrouwen van de eindgebruiker verloren kan worden. Je kunt dus met zekerheid zeggen dat het een investering is die zich uiteindelijk terugbetaalt. En als we heel eerlijk zijn, dit is de stabiliteit en kwaliteit die een klant verwacht. Toch?