Test Driven Development: vakantie voor de tester!

In veel software ontwikkeltrajecten komt testen aan het eind van een oplevering. In scrum omgevingen wordt testen zelfs vaak bij de ontwikkelaars gelegd. De term ‘multifunctioneel team’ maakt dat de klant of werkgever ervan uitgaat dat de ontwikkelaars de tests ook wel kunnen uitvoeren. Met of zonder tester erbij, in scrum of stiekem toch traditioneel gestuurde projecten gaat het vaak als volgt: “Bijna klaar voor productie, o ja, nog even testen”. En (tussen de regels door): “zorg vooral dat je niet te grote issues vindt want aan de klant is beloofd dat we morgen opleveren.”

Een goed testproces is essentieel voor de kwaliteit. En kwaliteit kost tijd. Op den duur levert het geld op, maar op de korte termijn heeft het vaak geen prioriteit.

Het staartje van elk traject.

Zo niet bij Test Driven Development. In deze filosofie komt testen aan kop. Zonder test geen code, hoorde ik onlangs iemand betogen over TDD. Een uitgangspunt waar veel testers alleen maar van dromen. Het mooie van deze filosofie is dat de ontwikkelaars de tests zelf schrijven. Het gaat namelijk over unit tests die de werking van de code op het laagste niveau valideren.


Hoe ziet het proces van TDD eruit?

De TDD ontwikkelcyclus, die in het algemeen door een ontwikkelaar wordt doorlopen, ziet er als volgt uit:

  • Run de bestaande tests (als ze er zijn; bij de eerste run heb je nog niets) en kijk of ze allemaal slagen.
  • Voeg een nieuwe test toe die het stukje code test dat je nog gaat toevoegen.
  • Run de tests nog een keer, en valideer dat de nieuwe test faalt.
  • Voeg vervolgens het nieuwe stukje code toe.
  • Valideer dat de nieuwe test slaagt (en de bestaande tests ook nog steeds).

Voordelen te over dus.

Testen wordt een “Doe het zelf, vooraf” voor het ontwikkelteam in plaats van een “oh ja, testen moet ook nog” aan het einde van het ontwikkeltraject, door de tester die lang heeft moeten wachten. Als deze methode consequent wordt toegepast, bevat elk stukje nieuwe code een test die slaagt. Complete testdekking, 100%. Een droom komt uit voor de tester. Hij of zij kan permanent op vakantie!

Tester met vakantie (Text Image).png

Geeft TDD inderdaad vanzelf garantie voor kwaliteit?

Je kunt misschien denken dat die permanente vakantie inderdaad in het verschiet ligt. Complete dekking met unit tests klinkt heel betrouwbaar en goed; de onderste laag, het fundament van de testpyramide, is helemaal nagelopen. Toch zijn er overwegingen die deze uitspraak in twijfel trekken, en waardoor het testwerk toch meer is dan TDD alleen. Een tester kan, helaas pindakaas, niet op vakantie. Er staan in een test driven development project nog steeds vragen voor hem open:

1. Welke unit tests moeten worden gemaakt?

In de praktijk blijkt dat als TDD wordt toegepast, dit niet zo nauwgezet wordt gevolgd als hierboven beschreven. Dat toch niet alle code vooraf wordt gegaan door een test. Dan moet er gekozen worden welke code een test krijgt en welke niet. Dit kan het beste bepaald worden door te kijken naar de business waarde van dat deel van het systeem. De product owner moet bepalen, met het team (inclusief de tester) als belangrijke adviseur, welke onderdelen van de software zoveel toegevoegde waarde hebben dat tests echt onontbeerlijk zijn. Dat betekent dat er ook bepaald wordt welke onderdelen zonder tests mogen bestaan. Als de tests daarna volgens die strategie geïmplementeerd zijn, is het nodig dat de tester regelmatig monitort of de tests inderdaad de afgesproken delen van het systeem nalopen.

2. Wat doen de unit tests eigenlijk?

Daarnaast moeten de tests zélf ook getoetst worden. Het hebben van een test voor de belangrijke stukken code is niet genoeg. Een test kan ook een foutje bevatten, het kan bijvoorbeeld voorkomen dat de test altijd een 'OK' uitkomst meegeeft, of iets doet of meet dat de werking van de code helemaal niet verifieert. De tester moet het team helpen door mee te kijken en vragen te stellen over wat de tests doen.

3. Wat moet het systeem als geheel eigenlijk doen?

Volgens de wellicht ouderwetse waterval-aanpak moet op elk niveau de juiste test worden uitgevoerd. Bij het schrijven van de code zijn dat unit tests, daarna komen keten- of integratietests en dan zijn er nog de end-to-end tests. Als je test driven ontwikkelt, kun je er weliswaar vanuit gaan dat de gebouwde componenten goed zijn, maar blijft het nodig ketentests te doen. Deze ketentests testen de integratie tussen de componenten; werken de componenten ook daadwerkelijk samen om de gewenste werking van het systeem als geheel te bereiken? Met de end-to-end tests, die daar dan weer boven hangen, loop je de gebruiker-gedreven scenario’s af, in de UI van het systeem. Hiermee kijk je of het systeem aan de verwachtingen voldoet die in de user story zijn geschetst.


Nog geen bounty-eiland….

Al met al genoeg te doen voor een tester. Een TDD traject geeft niet vanzelf garantie voor kwaliteit, helaas. Maar, mits goed toegepast, legt de TDD methode wel degelijk meer nadruk op testen. Het geeft de tester een aanknopingspunt om mee te doen aan het ontwikkeltraject. Daarnaast moet de tester zich nog steeds bezighouden met keten- en end-to-end tests.

Helaas... pindakaas (Text Image).png

Het bounty-eiland laat nog even op zich wachten, maar is een stukje dichterbij gekomen.

Bounty island voor de tester (Visual).png

Ik dank collega Daniël voor zijn blik vanuit de praktijk en de opbouwende discussies die we samen over dit onderwerp hebben gevoerd.


Test Driven Development: vakantie voor de tester!

Betabitter Maartje