Leaders in software testing

Test Driven Development, de tester in pole position?

Leaders in software testing

Test Driven Development, de tester in pole position?

Test Driven Development, de tester in pole position?
Test Driven Development
Jako Datema 10 februari 2014
0 reacties

Hoe vaak heb ik een tester niet horen verzuchten “was ik maar eerder bij het proces betrokken, dan …”. Na ‘dan’ volgt vaak een bloemlezing over heldere specificaties, reële tijdsplanning en inzichtelijke risico (deel)gebieden. Stel dat dit goed geregeld is, dan verwacht je als tester minder fouten te vinden in de opgeleverde software. Heb je dan de ideale testsituatie gecreëerd? Ik denk dat je als tester moet streven naar het voorkomen van fouten in de software. Op basis van mijn ervaring stel ik dat dit met Test Driven Development kan!

Wat is Test Driven Development (TDD)?

Het schrijven van tests voordat de daadwerkelijke code wordt geprogrammeerd. De geschreven test is een unittest. Let wel, het schrijven van unittesten is iets anders dan TDD. Alleen als dit gebeurt vóór het schrijven van de daadwerkelijke code, spreken we van een TDD-aanpak.

Waarom Test Driven Development?

Het idee van de opdrachtgever wordt veelal (in detail) beschreven, geprogrammeerd en volgens een gestructureerde aanpak getest. Als tester kun je hopelijk invloed uitoefenen tijdens de ontwerpfase. Ook in de testuitvoer ben je in staat om de grootste risico’s inzichtelijk te maken en af te dekken. Maar op het ontwikkeltraject, daar waar de ontwikkelaar de software codeert, heb je slechts een kleine of geen invloed. Zou het niet fantastisch zijn om al tijdens het schrijven van de code invloed uit te oefenen op kwaliteit en functionaliteit?

Wanneer Test Driven Development?

Vaak lees je dat TDD in een (ontwikkel)methode thuishoort. Het wordt dan vooral gelabeld onder de categorie Agile development. Dit valt onder eXtreme Programming. Een van de toepassingen van eXtreme Programming is TDD.

Ik ben van mening dat TDD onafhankelijk van de ontwikkelmethode is toe te passen.Waterval, agile, RUP, Scrum, het kan allemaal. Het is iets tussen de ontwikkelaar en de computer (en ja, in mijn ogen ook de tester). Niemand kan de ontwikkelaar belemmeren om TDD toe te passen, het is een keuze die je maakt als ontwikkelaar en hopelijk ook als team, onafhankelijk van de gekozen aanpak. Zoals niemand een ontwikkelaar kan belemmeren om te debuggen, geldt dit ook voor TDD.

Hoe pas ik Test Driven Development toe?

1.  Zorg dat de code faalt

Je schrijft geen functionerende code voordat je een falende test hebt geschreven. Kortom, je schrijft een test voor nog niet bestaande functionaliteit. Als de code wel bestaat, moet  je zeker weten dat de het uitvoeren van de code eerst faalt. 

2. Zorg dat de code werkt

Als je hebt gezien dat de code faalt, zorg dan dat de code (en dus de test) slaagt. Doe dit op een zo simpel mogelijke manier (simpel ≠ dom). Beperk je telkens tot slechts één unittest. Het is anders niet duidelijk welk stuk code faalt. Elk nieuwe test is nieuwe bewijs dat de code correct functioneert. Zet je te grote stappen dan bestaat de reële kans dat de test onnodig ingewikkeld wordt waarmee fouten in de unittest sluipen.

 3. Zorg dat de code nog beter werkt

Als de code correct functioneert, kijk dan waar je de test kunt verbeteren. Maak de test generiek, vereenvoudig de test of gebruik een (nog) logischer naam. Zie je unittest als een valnet zoals ze in het circus gebruiken. Je kunt nu naar hartenlust verbeteren omdat je al die unittests hebt die je vertellen of je iets kapot hebt gemaakt.

De conclusie

Pas je Test Driven Development op bovenstaande wijze toe, dan:Test Driven Development door Jako Datema, test consultant bij Polteq

  • heb je 24/7 inzicht in de kwaliteit van de software;
  • kun je elke functionele wijziging, hoe groot en ingewikkeld ook, aanpassen met behoud van en inzicht in de softwarekwaliteit;
  • ben je klant van je eigen software en je ziet direct dat functionaliteit niet prettig werkt;
  • lever je altijd werkende software op. Als een van je testgevallen faalt is het onmogelijk om de rest van de code te compileren.

Jako Datema, test consultant bij Polteq 

Reageren

Om SPAM te voorkomen wordt uw bericht na goedkeuring door de webmaster geplaatst.

Het e-mailadres wordt niet gepubliceerd.


Reacties

Er zijn nog geen reacties.

Onderwerpen

Laatste reacties

Beste Amresh, Bedankt voor je reactie. Jouw vraag is doorgestuurd naar onz...
› Lees verder

polteq

Ik wil me graag aanmelden voor het traineeship maar de webpagina Trainee So...
› Lees verder

Amresh Bandhoe

Bedankt voor je reactie. Ik zorg ervoor dat je z.s.m. de gewenste informati...
› Lees verder

polteq
Polteq (NL)Printerweg 523821 AD AmersfoortNederlandT +31 (0) 33 277 35 22E info@polteq.com
Polteq (BE)Interleuvenlaan 623001 Heverlee (Leuven)BelgiëT +32 (0) 16 39 48 04E infobe@polteq.com