Testen, hoe maak je het leuk?
Zonder een hoop mensen te willen beledigen, testen is een beetje het lelijke eendje in het ontwikkelproces. Iedereen snapt het nut ervan, maar stakeholders hebben liever nieuwe functionaliteit en developers schuiven het daarom graag naar achteren. Want laten we eerlijk zijn, nieuwe dingen bouwen is veel leuker.
Maar helaas, dit is niet verstandig. Testen zijn belangrijk en nodig. Hoe maak je het als developer dan toch leuk voor jezelf? Hoe zorg je ervoor dat het testen een vaste plek krijgt in het proces? Bij mijn huidige opdracht hebben we dat erg goed onder controle. In deze blog zal ik beschrijven hoe.
In mijn team van vier fullstack ontwikkelaars, hebben we de regel dat twee stories tegelijk in progress mogen zijn. Hierdoor worden we gedwongen om samen te werken.
We starten een story met het opzetten van een testraamwerk. Dit houdt in: het beschrijven van alle mogelijke goed- en fout situaties die kunnen optreden. Welke functionaliteit moet er minimaal maar ook maximaal zijn? Belangrijk om hiermee te beginnen, zodat alle mogelijke gaten in de requirements er direct worden uitgefilterd. Dit zorgt ervoor dat voordat we beginnen met bouwen, alle neuzen dezelfde kant op staan.
Wanneer dit klaar is splitsen we de story op en gaan we parallel aan het werk. De een bouwt de functionaliteit, de ander schrijft de testen. Dit doen we in zowel de frontend als de backend. In theorie zouden we dus met vier personen aan een story kunnen werken.
Aan deze manier van werken zitten enorm veel voordelen. Iedereen heeft kennis van alle functionaliteit dus niemand is onmisbaar. Door parallel te werken worden verwachtingen van elkaar scherp gesteld en is de eerste reviewslag over de code al geweest. Nog een groot voordeel wat voor mij goed werkt, is het uitdagen van elkaar tijdens het bouwen. Brainstormen over wat allemaal mogelijk is met de nieuwe functionaliteit. Het is wel belangrijk om scope creep goed in de gaten te houden. Nauwe betrokkenheid van de product owner en scrum master is erg belangrijk.
Om het iets concreter te maken, wat maken we voor typen testen? We hebben de volgende onderverdeling gemaakt
- Isolated testen. Specifieke testen per class of component. Dit houdt in, unit testen voor (complexe) functionaliteit. De user interface daarbij niet meegenomen.
- Shallow testen: isolated tests met ondersteuning van de user interface. Denk aan form validation, enablen en disablen van knoppen naar verwachting, enzovoorts
- Integratie testen: alle mogelijke foutsituaties die in de communicatie tussen frontend en backend kunnen optreden. Bijvoorbeeld meldingen dat de backend niet beschikbaar is of foutieve gegevens die zijn geüploaded. Om dit te kunnen testen zetten we met NodeJS een mock RESTServer op die statuscodes en berichten teruggeeft op basis van de URL.
- End-to-end testen: de daadwerkelijke communicatie tussen frontend en backend. Enkel de happy flows worden getest met een door Flyway opgezette testdatabase.
Tot slot nog een leuke tip om mensen buiten je team te betrekken in jouw team’s testproces. Organiseer een Bughunt. Stel teams op van ongeveer drie personen en ga een half uur lang met die groep fouten in het product zoeken. Het team met de meest gevonden bugs, wint. Hierdoor krijg je snelle feedback, een lijst vol issues om op te lossen en zichtbaarheid van je product binnen de organisatie!
Ik hoop jullie hiermee voldoende geïnspireerd te hebben hoe belangrijk en vooral hoe leuk testen kan zijn. Bedankt voor het lezen!