+31 35 543 1000 info@kza.nl

Is TDD (helemaal) het einde voor testers?

okt 11, 2018 | KZA Blogs, Testing Trends

Net als mijn eerder geschreven blog over agile werken wil ik nogmaals benadrukken dat dit niet mijn core-business is en dit stuk dan ook is geschreven vanuit mijn perspectief. Terwijl ik mij aan het verdiepen was in dit onderwerp viel me op dat er steeds allerlei testen in elkaar vallen of opvolgend aan elkaar zijn. Ik zal proberen dit zo duidelijk mogelijk te vermelden.

Nadat ik het woord TDD regelmatig heb horen vallen in ons kantoor heb ik hier meer onderzoek naar gedaan. Ik vroeg me namelijk af of je nog wel een tester nodig hebt als je TDD hebt geïmplementeerd binnen een organisatie. Voor diegene die nu een extra tabblad opent om het principe TDD op te zoeken, zie onderstaand.

Bij Test Driven Development schrijf je eerst een testscript alvorens je de programmatuur hebt geschreven. Dat klinkt nogal vreemd dus. Je begint met het schrijven van een unit-test. Het schrijven van deze test doe je op basis van de technische requirements, deze worden afgeleid vanuit de functional requirements. Om je een voorbeeld te geven; Stel je bouwt een lego-kraan dan kan een technische requirement zijn dat de blokjes goed gebouwd zijn (unit test) maar ook dat ze op elkaar zitten en passen (integratie test). Als dat namelijk niet goed gaat zal je kraan uiteindelijk omvallen. Een functionele requirement kan zijn dat de kraan ook iets op kan tillen en kan verplaatsen.

Dankzij de requirements werk je met bepaalde kaders waardoor overbodige functionaliteiten/code niet wordt geschreven. Hierdoor is het uiteindelijk geschreven stuk overzichtelijker en minder complex. Niet te vergeten, in het begin maak je een test die faalt. (Dat is ook wat waard, want er bestaan een hoop tests die false positives geven en altijd goed gaan als dat niet het geval had moeten zijn). Nadat je een falende test hebt ga je met de code aan de slag totdat de test goed gaat. Daarna kan je dan nog de code optimaliseren (refactoren) of uitbreiden.

In de ideale situatie zijn de tests zo ingericht dat deze op de lange termijn tijd besparen, alhoewel dit in het begin niet zo lijkt. Je bent namelijk eerst de tests aan het schrijven terwijl je in die tijd ook al een gedeelte had kunnen bouwen. Daar komt ook nog bij dat de meeste ontwikkelaars het helemaal niet leuk vinden om te testen, laat staan dat ze eerst een testscript moeten maken voordat ze mogen gaan spelen. In een TDD omgeving kunnen testers prima optreden als sparringspartner voor ontwikkelaars als het gaat om de codekwaliteit en kwaliteit van de unittests, door de typische testers mindset.

Voor een tester klinkt het als muziek in de oren. De code wordt beter geschreven en fouten worden eerder gevonden. Heeft de tester dan geen functie meer? Jawel. Het lijkt alsof alles is afgedekt door te beginnen met het schrijven van een unit-test maar een integratie test of systeem test is daarna van nog groter belang. Dit zal een tester alsnog moeten doen.

Daarnaast worden de software testers steeds meer T-shaped opgeleid waardoor ze zelf vaak ook (deels) kunnen programmeren. Zij kunnen dan de testscripts opstellen i.p.v. de ontwikkelaar. Maar betekent dit dan dat een ontwikkelaar pas een week later aan het werk kan?

Er blijven genoeg vragen over om een mooie discussie open te gooien! Wat is jouw mening over TDD?

Michelle de Bruijn

Corporate recruiter & digital marketeer