Waarom zou je eigenlijk testen?

Elke developer die iets ontwikkelt, test of de nieuwe code de gewenste functies uitvoert. Soms past de nieuwe code echter meer aan dan enkel de gewenste functie en heeft het effect op andere delen, functies of interacties van je applicatie. Iets wat je als developer niet altijd 100% op je vizier kan hebben, maar wat wel voor bugs of problemen kan zorgen voor eindgebruikers. Door het vooraf te testen kan je de kans op bugs bij een release aanzienlijk verkleinen.

Een goede test onderzoekt of de geschreven code één of meerdere functies van de applicatie beïnvloedt. Door middel van een testprocedure worden er verschillende elementen van de applicatie bij elke nieuwe update getoetst. Werkt het element of een bepaald onderdeel daarvan niet naar behoren? Dan gaat het project terug de ontwikkeling in.

Wat test je? 

Je kunt verschillende onderdelen testen van je code. Bijvoorbeeld codekwaliteit en -stijl of de zogenaamde unit-tests. Het woordje "unit" zou vertaald kunnen worden naar "eenheid". Het komt erop neer dat je een bepaalde eenheid test op specifieke functionaliteit. En alleen die eenheid. Een voorbeeld van een unit test zou kunnen zijn: het aanmaken van een nieuw account en checken of dit account ook echt kan inloggen. Een tweede unit test kan dan de gebruiker weer proberen te verwijderen of te deactiveren. Eigenlijk is wat je zelf als ontwikkelaar doet tijdens het maken van een nieuwe functie ook al een soort unit test, maar dan handmatig in plaats van automatisch.

Op welke manieren kun je testen?

We stipten al kort even automatisch testen aan - maar naast verschillende tests heb je ook meerdere testmethodes. We leggen de vier meest voorkomende testmethodes aan je uit:

Geautomatiseerd

Dit gebeurt meestal als eerste, of op zijn minst nadat je je eigen handmatige unit tests hebt doorlopen. In het geval van  zoals Git kun je ook een "pipeline" opzetten. Na het uploaden van je code gaat deze pipeline automatisch lopen, waardoor er een aantal (afzonderlijke) tests gedraaid wordeversiebeheersystemenn. Je kunt ook per project andere tests instellen om alles automatisch te laten checken. Zo'n pipeline wordt ook wel Continuous Integration (CI) genoemd.

Grote nadeel? Je moet op korte termijn wel flink wat tijd vrijmaken om die tests in eerste instantie op te stellen. Maar ‘elk nadeel heb z’n voordeel': op de lange termijn scheelt het flink wat manueel en herhalend werk.

Je kunt natuurlijk ook zonder Git of pipeline automatische tests uitvoeren. Denk bijvoorbeeld aan een testscript wat meerdere keren per dag draait en zelf gewoon de code ophaalt uit Git. Dan heb je geen integratie met je versiebeheer maar de tests verlopen wel volledig automatisch. Ook dat zou je CI kunnen noemen.

Reviewen

Misschien kan je het niet echt als échte test beschouwen, maar reviewen is zeker een belangrijk onderdeel van de testfase. Bij Beer n tea maken we daarom gebruik van het 4-eyes principle. Elk stuk code gaat langs een tweede collega en wordt gecheckt op logica en mogelijke verbeteringen. Die dubbelcheck is handig omdat de reviewer nét andere dingen ziet dan de maker van de code. Wat dacht je bijvoorbeeld van tikfoutjes? Iets wat in elke taal snel over het hoofd wordt gezien of overheen wordt gelezen door de ‘schrijver’. 

Tijdens een dergelijke review wordt de code ook gebruikt om een functionele test te doen. Doorgaans gebeurt deze check nadat de CI de tests succesvol heeft gedaan. 

Interne user test

Naast een check door developers uit het team, is het vaak ook heel waardevol om niet-developers mee te laten testen. Juist omdat ze geen ontwikkelaars zijn, zullen ze andere ideeën hebben over hoe iets moet functioneren of kunnen ze andere problemen simuleren. Misschien klikken ze net ergens anders dan wat de developer tijdens het schrijven van de code voor ogen had, of vullen ze andere waardes in dan verwacht bij een invoerveld. Bijvoorbeeld: stel dat een e-mailveld ook een websiteadres accepteert, wat gebeurt er dan als de applicatie een e-mail stuurt?

Externe user test

Nadat alle interne tests gedaan zijn, kan er ook aan klantzijde worden getest. Vaak is dit weer nét anders dan de interne user test, omdat de klant zelf een beter beeld heeft hoe een functie hoort te werken én hoe de eindgebruiker, de klant van de klant, de applicatie zal gebruiken. Deze externe user-test vinden wij altijd erg nuttig: het bevat inzichten van de eindgebruikers waarmee we de functionaliteiten van de applicatie nóg beter op het doelpubliek kunnen afstemmen.

En hoe doet Beer n tea dat?

Bij Beer n tea gebruiken we een combinatie van verschillende testprocessen om tot het beste eindresultaat te komen. Dat doen we in 4 stappen

1. Nadat de code naar Git is geüpload, start een pipeline met meerdere fasen. 

   • Build: hierbij wordt code van derde partijen (libraries) gedownload en klaar gemaakt om door het project zelf gebruikt te worden.
     
     

   • Test: validatie van de gedownloade libraries, syntax- en codekwaliteitschecks, unit tests, assetgeneratie van templates (bijv. less naar CSS) en statische analyse.
     
     

   • Cache: een aantal caches wordt aangelegd. Denk hierbij aan een cache voor de libraries zoals die uiteindelijk in gebruik zijn genomen, dus na alle eventuele conversies en installatiestappen.
     
     

2. Als de pipeline slaagt wordt vervolgens de code (handmatig) gereviewd. Eventuele verbeteringen worden doorgevoerd door degene die de code heeft geschreven.
   
   

3. Daarna testen een aantal interne medewerkers of het in ieder geval voldoet aan de specificaties van de klant.
   
   

4. Als laatst zullen een aantal medewerkers van de klant ook checken hoe de functie werkt. Wijzigingen in deze testfase kunnen vaak worden opgelost door een stukje uitleg bij de functie (voor de gebruiker of eindgebruiker) of door minimale code-aanpassing.

Bij elke wijziging of verbetering van de code moet het hele testproces opnieuw worden doorlopen, ongeacht de testfase waarin het zich bevindt. Dit herhaalt zich net zo lang tot de code goedgekeurd wordt in alle testfases. Zodoende weten we zeker dat de code aan onze kwaliteitseisen voldoet.

Conclusie

Zoals je misschien hebt kunnen lezen: elke vorm van testen heeft zijn eigen doel en is misschien niet in elke situatie van toepassing. Maak je bijvoorbeeld een applicatie voor intern gebruik, dan zijn de interne en externe user tests eigenlijk gewoon hetzelfde. Of misschien is het project te klein om uren bezig te zijn met het opstellen van automatische tests en kun je ervoor kiezen om die handmatig te checken.

Toch pleiten we voor een goede testprocedure met testprotocollen die goed te volgen zijn. In de meeste gevallen zal je een combinatie van reeds genoemde testmethodes nodig hebben om de kwaliteit van je webapplicatie te waarborgen en mogelijke bugs of problemen bij een release vroegtijdig te identificeren en op te lossen.