Voordelen van testgestuurde ontwikkeling: belangrijkste statistieken & onderzoeken
In dit artikel bespreek ik enkele statistieken en onderzoeken over testgedreven ontwikkeling om te begrijpen hoe deze is toegepast, wat de voordelen zijn en met welke uitdagingen teams bij deze aanpak te maken krijgen.
Traditioneel verloopt het softwareontwikkelingsproces lineair. In de afgelopen decennia zijn agile systemen echter steeds populairder geworden (maar liefst 87% van de teams volgt een agile of vergelijkbare aanpak). Daardoor is softwareontwikkeling verschillende methodologieën gaan omarmen die rekening houden met de vereisten en het karakter van het project.
De techniek van testgedreven ontwikkeling (TDD) is een van de methoden die in het gebied van agile softwareontwikkeling de aandacht heeft getrokken.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In een onderzoeksartikel dat is gepubliceerd door het Institute of Electrical and Electronics Engineers zeggen auteurs Yahya Rafique en Vojislav Misic dat “Testgedreven ontwikkeling (TDD) tot de hoeksteenpraktijken van het ontwikkelingsproces van Extreme Programming (XP) behoort” (Bron).
Van de man die TDD naar verluidt heeft ontwikkeld, wordt gemeld dat hij “in 2003 stelde dat TDD eenvoudige ontwerpen aanmoedigt en vertrouwen wekt” (Bron). Er blijven echter vragen bestaan over de beweringen over productiviteit en kwaliteit die over TDD zijn gedaan.
We hebben de tijd genomen om de nieuwste TDD-statistieken te verzamelen om de gedane beweringen te toetsen.
Dit artikel begint met het definiëren van het concept TDD en het verschil met de traditionele aanpak. Vervolgens bekijken we enkele statistieken die de beweringen over TDD bevestigen of juist verwerpen.
Wat is testgedreven ontwikkeling?
Testgedreven ontwikkeling is een aanpak waarbij een test wordt geschreven voordat de softwareontwikkelaar de productiecode maakt die aan de test voldoet. Het basisidee van deze techniek is dat de schrijver van de code de tijd krijgt om na te denken over het ontwerp of de vereisten voordat functionele code wordt geschreven.
TDD-proces
- De test schrijven: In TDD begint elke nieuwe functie met het schrijven van een test. De programmeur moet de specificatie en vereisten van de functie begrijpen. Om dit te bereiken, moet diegene gebruikersverhalen en gebruiksscenario's doornemen om het doel van de nieuwe code die wordt ontwikkeld te begrijpen.
- De test mislukt: Nadat de programmeur de test heeft geschreven, voert diegene deze uit. Omdat er nog geen code is om de test te implementeren, zal de test mislukken. Dit bevestigt dat het geautomatiseerde testframework correct werkt en sluit de mogelijkheid uit dat de nieuwe test altijd slaagt omdat deze defect is.
- De code schrijven: Nu weet de programmeur dat de functie volgens het ontwerp werkt. Vervolgens schrijft diegene de code die voor de test slaagt. De code hoeft niet perfect te zijn of de test uitstekend te doorstaan, maar dat is niet belangrijk. Van de ontwikkelaar wordt niet verwacht dat diegene code schrijft die verder gaat dan de functionaliteit waarop de test is gericht.
- De tests uitvoeren: Omdat de programmeur weet dat de functie werkt zoals ontworpen, kan diegene bij het uitbrengen van nieuwe code een testbeheertool gebruiken om die test opnieuw uit te voeren. Zo krijgt diegene de bevestiging dat de meest recente update de vorige functie niet heeft beschadigd.
- De code herstructureren: In TDD moet de codebasis voortdurend worden opgeschoond naarmate deze groeit. Omdat de belangrijkste focus van de programmeur in de bovenstaande fasen alleen lag op het schrijven van de code, zorgt deze fase voor efficiëntie. De interne structuur van de broncode van het programma kan worden verbeterd, terwijl de externe kenmerken behouden blijven. In deze fase kunnen duplicaten worden verwijderd en nieuwe functionaliteiten worden toegevoegd.
- Herhalen: De bovenstaande stappen worden automatisch herhaald om ervoor te zorgen dat de TDD-cycli alle functies omvatten.
Verschillen tussen TDD en traditionele ontwikkeling
Om TDD te begrijpen, is het zinvol om vast te stellen waarin deze aanpak verschilt van traditionele programmeermethoden.
Het belangrijkste verschil is dat traditionele methoden een lineair proces volgen, terwijl TDD een cyclisch proces doorloopt.
Programmeurs die traditionele testmethoden gebruiken, beginnen met het maken van de code en richten zich pas aan het einde van het ontwikkelingsproces op de test. Daarentegen begint degene die het TDD-model volgt met het maken van de test en ontwikkelt vervolgens de code die aan de test voldoet. Deze aanpak deelt veel principes met de shift-leftbeweging binnen het testen van software.
Hoewel de programmeur die de traditionele aanpak gebruikt aandacht kan besteden aan de juistheid van de code, loopt diegene het risico niet alle fouten in de code te ontdekken. De programmeur die de TDD-methode gebruikt, werkt aan de code totdat deze de test doorstaat, door de code te refactoren. Dit wordt gedaan totdat de code aan de functionaliteit voldoet, een proces dat waarschijnlijk tot minder fouten leidt.
Is TDD langzamer of sneller dan traditionele testontwikkeling?
Wat betreft de vraag of TDD het programmeerproces sneller maakt, zijn er tegenstrijdige statistieken uit verschillende bronnen.
Een casestudy waarbij software-engineeringteams van Microsoft en IBM waren betrokken, concludeerde dat de “teams een toename van 15-35% in de initiële ontwikkelingstijd ondervonden” toen ze de TDD-techniek gebruikten. In het onderzoek wordt echter opgemerkt dat dit cijfers zijn die “subjectief door het management zijn geschat” (Bron).
Wanneer we dit bekijken vanuit het perspectief dat onderzoeken van Microsoft en IBM wijzen op kwaliteitsverbeteringen, kan worden betoogd dat TDD op de lange termijn tijd bespaart die anders nodig zou zijn geweest om problemen op te lossen. De teams bij Microsoft en IBM waren het met deze visie eens (Bron).
Een onderzoek naar de eerste percepties van ervaren professionals bij het gebruik van TDD concludeert dat “nadat de eerste moeilijkheden om te begrijpen waar te beginnen en hoe een test te maken voor een functie die nog niet bestaat zijn overwonnen, deelnemers meer vertrouwen krijgen om nieuwe functies te implementeren en wijzigingen aan te brengen dankzij de brede testdekking” (Bron). Dit lijkt erop te wijzen dat dingen na verloop van tijd verbeteren.
Programmeur en auteur van “Software samenstellen” en “JavaScript-toepassingen programmeren ,” Erick Elliot schrijft voor het onlinepublicatieplatform Medium.com over hoe TDD zijn leven veranderde. Elliot is het ermee eens dat het proces in het begin langzaam kan zijn, maar zegt: “ergens rond de twee jaar gebeurde er iets magisch: ik begon sneller te programmeren met unittests dan ik ooit zonder had gedaan” (Bron).
Het lijkt erop dat het gebruik van TDD dingen aanvankelijk kan vertragen. Als we dit echter vanuit een langetermijnperspectief bekijken, kan de tijd die wordt bespaard door code van betere kwaliteit de tijd compenseren die in het begin verloren gaat. Bovendien mag worden verwacht dat programmeurs sneller zullen werken naarmate ze beter worden in TDD.
Er zijn ook veel andere factoren waarmee rekening moet worden gehouden bij het meten van de tijd die nodig is om een resultaat van hoge kwaliteit te bereiken. Luister voor meer informatie hierover naar de aflevering van Niall Lynch in de podcast The QA Lead over het meten van T2Q (tijd tot kwaliteit).
Leidt TDD tot minder fouten?
In de bovenstaande bespreking wordt als een van de belangrijkste voordelen van TDD genoemd dat het tot minder fouten leidt. Maar komen de statistieken hiermee overeen?
Dezelfde onderzoeken naar de engineeringteams van Microsoft en IBM die hierboven zijn genoemd, concludeerden dat “de defectdichtheid vóór de release van de vier producten met 40% tot 90% daalde ten opzichte van vergelijkbare projecten waarin de TDD-praktijk niet werd gebruikt.” Concreet rapporteerden de IBM-teams een daling van 40% in defectdichtheid, terwijl de teams van Microsoft een daling van 60-90% rapporteerden (Bron).
Ondersteunen statistieken over testgestuurde ontwikkeling de conclusie dat TDD een betere kwaliteit oplevert?
Op basis van de resultaten van een onderzoek dat werd gepresenteerd tijdens het Eerste internationale symposium over IEEE in Finland in 2007, rapporteren Maria Siniaalto en Pekka Abrahamsson dat is aangetoond dat TDD een betere codekwaliteit oplevert dan software die zonder TDD is ontwikkeld (Bron).
In hun paper verwijzen Siniaalto en Abrahamsson naar een onderzoek dat in China is uitgevoerd en concludeerde dat TDD de procesbewaking en taakinschatting verbeterde. In hetzelfde onderzoek wordt geconcludeerd dat “TDD ook het volgen van consistente werkwijzen en richtlijnen bevordert.” Dit leidt tot een betere kwaliteit met minder defecten. Bovendien konden de teams die TDD gebruikten hun defecten sneller herstellen (Bron).
Een onderzoek onder ontwikkelaars met gemiddeld ongeveer tien jaar professionele ervaring, uitgevoerd om hun percepties bij het gebruik van TTD te onderzoeken, citeert een ontwikkelaar die zegt: “TDD heeft me geholpen de code te verbeteren en leesbaarder te maken.” Een andere deelnemer meldt dat “TDD een betere onderhoudbaarheid mogelijk maakt” (Bron).
Bevordert TDD een eenvoudiger ontwerp?
Boby George en Laurie Williams, die beiden werkzaam zijn bij de afdeling Computerwetenschappen van de North Carolina State University, voerden een experiment uit waarbij 24 programmeurs in twee groepen werden verdeeld: de ene groep gebruikte TDD en de andere de lineaire aanpak.
George en Williams melden dat van de deelnemers “92% van de ontwikkelaars geloofde dat TDD code van hogere kwaliteit oplevert, 79% dacht dat TDD een eenvoudiger ontwerp bevordert en 71% vond dat de aanpak merkbaar effectief was” (Bron).
Deze statistieken over testgestuurde ontwikkeling met betrekking tot kwaliteit geven een sterke aanwijzing dat TDD inderdaad leidt tot code van hogere kwaliteit en een eenvoudiger ontwerp.
In een artikel dat is gepubliceerd door het gratis leerplatform Guru99.com zegt Kanchan Kulkarni: “TDD maakt de code eenvoudiger en duidelijker. Het stelt de ontwikkelaar in staat minder documentatie bij te houden” (Bron).
Is het eenvoudig om TDD-ontwerp toe te passen?
Uit het experiment van George en Williams bleek dat 56% van de professionele ontwikkelaars het moeilijk vond om een TDD-mentaliteit te ontwikkelen, terwijl 23% beweerde dat het ontbreken van een voorafgaande ontwerpfase de reden voor deze moeilijkheid was. Van alle respondenten vond 40% dat de invoering van TDD moeilijk is (Bron).
Deze statistieken over testgestuurde ontwikkeling met betrekking tot invoering geven aan dat TDD als moeilijk toepasbaar wordt gezien.
Wordt TDD overschat?
In een artikel dat op Medium.com is gepubliceerd, gebruikt Tylor Borgeson, die zichzelf omschrijft als een fullstacksoftwareontwikkelaar met interesse in machine learning, AI, infrastructuur, DevOps en Agile, de kop “Testgestuurde ontwikkeling wordt overschat.” Het feit dat hij de kop tussen aanhalingstekens heeft geplaatst, laat echter zien dat dit geen uitspraak van hemzelf is.
Borgeson richt zich vervolgens tot degenen die zeggen dat de methode wordt overschat en traag is. Hij vertelt hun dat de meeste mensen die deze mening hebben de methode niet lang genoeg hebben gebruikt. Aan het einde van zijn artikel zegt hij: “Ga nu testgestuurde ontwikkeling oefenen totdat het geen pijn meer doet” (Bron).
Wat nu?
Leer QA-benaderingen van experts in de podcast The QA Lead
Schrijf je in voor de nieuwsbrief van The QA Lead om onze nieuwste handleidingen en podcastafleveringen te ontvangen
Schrijf je in voor de wachtlijst van het online communityforum van The QA Lead, waar je best practices kunt delen met andere professionals op het gebied van QA en softwaretesten.
We hopen je daar te zien!
