Fordele ved testdrevet udvikling: Vigtig statistik og undersøgelser

I denne artikel gennemgår jeg nogle statistikker og undersøgelser om testdrevet udvikling for at forstå, hvordan det er blevet anvendt, fordelene og de udfordringer, teams står over for med denne tilgang.

Traditionelt foregår softwareudviklingsprocessen lineært. I de seneste årtier, hvor agile systemer imidlertid er blevet mere populære (så mange som 87% af teams følger en agil eller agil-lignende tilgang), er softwareudvikling begyndt at tage forskellige metoder til sig, som tager højde for projektets krav og karakter.

Metoden testdrevet udvikling (TDD) er en af de metoder, der har tiltrukket sig opmærksomhed inden for agil softwareudvikling.  

I en forskningsartikel udgivet af Institute of Electrical and Electronics Engineers siger forfatterne Yahya Rafique og Vojislav Misic, at “Testdrevet udvikling (TDD) er blandt de grundlæggende praksisser i udviklingsprocessen Extreme Programming (XP)” (Kilde). 

Det siges, at den person, der udviklede TDD, “i 2003 udtalte, at TDD fremmer enkle designs og skaber tillid” (Kilde). Der er dog stadig spørgsmål om de påstande om produktivitet og kvalitet, der fremsættes om TDD. 

Vi brugte noget tid på at indsamle de nyeste TDD-statistikker for at afprøve de fremsatte påstande.

Denne artikel begynder med at definere begrebet TDD, og hvordan det adskiller sig fra den traditionelle tilgang. Derefter ser vi på nogle af de statistikker, som enten bekræfter eller afviser de fremsatte påstande om TDD.    

Hvad er testdrevet udvikling?

Testdrevet udvikling er en tilgang, hvor en test skrives, før softwareudvikleren opretter produktionskoden, der skal opfylde testen. Den grundlæggende idé med denne teknik er at give den person, der skriver koden, tid til at overveje designet eller kravene, før der skrives funktionel kode.  

TDD-processen

1. Skriv testen: I TDD begynder alle nye funktioner med at skrive en test. Programmøren skal forstå specifikationen og kravene til funktionen. For at opnå dette skal vedkommende gennemgå brugerhistorier og anvendelsestilfælde for at forstå formålet med den nye kode, der udvikles.   
2. Testen fejler: Når programmøren har skrevet testen, kører vedkommende den. Da der endnu ikke er nogen kode til at implementere den, vil testen fejle. Dette bekræfter, at den automatiserede testramme fungerer korrekt, og udelukker muligheden for, at den nye test altid består, fordi den er defekt. 
3. Skriv koden: Nu ved programmøren, at funktionen fungerer i overensstemmelse med designet. Vedkommende skriver nu den kode, der består testen. Koden er måske ikke perfekt eller består måske ikke testen fremragende, men det er ikke vigtigt. Udvikleren forventes ikke at skrive kode ud over den funktionalitet, som testen blev oprettet for at kontrollere.
4. Kør testene: Når programmøren ved, at funktionen fungerer som designet, kan vedkommende bruge et teststyringsværktøj til at køre testen igen, hver gang der udgives ny kode. Det giver validering af, at den seneste opdatering ikke har ødelagt den tidligere funktion.  
5. Refaktorér koden: I TDD skal kodebasen løbende renses, efterhånden som den vokser. Da programmørens primære fokus i de ovenstående faser kun var at skrive koden, sikrer denne fase effektivitet. Den gør det muligt at forbedre den interne struktur i programmets kildekode, samtidig med at de eksterne egenskaber bevares. Denne fase kan fjerne duplikeringer og tilføje ny funktionalitet.   
6. Gentag: De ovenstående trin gentages automatisk for at sikre, at TDD-cyklusserne dækker alle funktionerne.  

Forskelle mellem TDD og traditionel udvikling

For at forstå TDD synes det passende at fastslå, hvordan metoden adskiller sig fra traditionelle tilgange til programmering.

Den væsentligste forskel er, at de traditionelle metoder følger en lineær proces, mens TDD gennemgår en cyklisk proces. 

Programmører, der bruger de traditionelle testmetoder, begynder med at oprette koden og fokuserer først på testen i slutningen af udviklingsprocessen. Den, der følger TDD-modellen, begynder derimod med at oprette testen og udvikler derefter den kode, der opfylder testen. Denne tilgang deler mange principper med shift-left-bevægelsen inden for softwaretest.

Mens programmøren, der bruger den traditionelle tilgang, kan fokusere på kodens korrekthed, risikerer vedkommende ikke at opdage alle kodens fejl. Programmøren, der bruger TDD-metoden, arbejder med koden, indtil den består testen, ved at refaktorere koden. Dette fortsætter, indtil koden opfylder funktionaliteten, hvilket sandsynligvis resulterer i færre fejl.

Er TDD langsommere eller hurtigere end traditionel testudvikling?

Hvad angår spørgsmålet om, hvorvidt TDD får programmeringsprocessen til at gå hurtigere, er der modstridende statistikker fra forskellige kilder. 

Et casestudie med Microsoft- og IBM-teams bestående af softwareingeniører konkluderede, at “teams oplevede en stigning på 15-35 % i den indledende udviklingstid”, da de brugte TDD-teknikken. Studiet bemærker dog, at dette er tal, der er “subjektivt estimeret af ledelsen” (Kilde). 

Hvis man ser på det ud fra perspektivet om, at undersøgelserne fra Microsoft og IBM viser, at der var forbedringer i kvaliteten, kan man argumentere for, at TDD på lang sigt sparer den tid, der ellers ville have været nødvendig for at løse problemer. Teamsene hos Microsoft og IBM var enige i dette synspunkt (Kilde). 

Et studie, der fokuserede på erfarne fagfolks indledende opfattelser ved brug af TDD, konkluderer, at “efter at have overvundet de indledende vanskeligheder med at forstå, hvor man skal begynde, og hvordan man opretter en test for en funktion, der endnu ikke findes, opnår deltagerne større tillid til at implementere nye funktioner og foretage ændringer på grund af den brede testdækning” (Kilde). Det, dette synes at antyde, er, at tingene forbedres med tiden. 

Programmøren og forfatteren til “Sammensætning af software” og “Programmering af JavaScript-applikationer”, Erick Elliot, skriver til den online udgivelsesplatform Medium.com og fokuserer på, hvordan TDD ændrede hans liv. Elliot er enig i, at processen kan være langsom i begyndelsen, men siger: “omkring to år senere begyndte der at ske noget magisk: Jeg begyndte at skrive kode hurtigere med enhedstests, end jeg nogensinde havde gjort uden dem” (Kilde).  

Det ser ud til, at brugen af TDD kan gøre tingene langsommere i begyndelsen. Men hvis man ser på det på lang sigt, kan den tid, der spares gennem kode af bedre kvalitet, opveje den tid, der går tabt i begyndelsen. Det kan også forventes, at programmører sandsynligvis arbejder hurtigere, efterhånden som de bliver bedre til TDD. 

Der er også mange andre faktorer, man skal tage i betragtning, når man forsøger at måle den tid, det tager at opnå et resultat af høj kvalitet. Du kan høre mere om dette i Niall Lynchs episode i The QA Lead-podcasten om måling af T2Q (tid til kvalitet).

Resulterer TDD i færre fejl?  

I diskussionen ovenfor blev en af de største fordele ved TDD præsenteret som, at det resulterer i færre fejl. Men stemmer statistikkerne overens med dette? 

De samme undersøgelser, der involverede ingeniørteams hos Microsoft og IBM, konkluderede, at “fejltætheden før udgivelsen for de fire produkter faldt med mellem 40 % og 90 % sammenlignet med lignende projekter, der ikke anvendte TDD-praksissen.” IBM-teamene rapporterede specifikt et fald på 40 % i fejltætheden, mens Microsofts teams rapporterede et fald på 60-90 % (Kilde). 

Understøtter statistikker om testdrevet udvikling konklusionen om, at TDD giver bedre kvalitet?

Baseret på resultaterne af et studie, der blev præsenteret ved det første internationale symposium om IEEE i Finland i 2007, rapporterer Maria Siniaalto og Pekka Abrahamsson, at TDD har vist sig at give bedre kodekvalitet sammenlignet med software, der er udviklet uden TDD (Kilde). 

I deres artikel henviser Siniaalto og Abrahamsson til en undersøgelse gennemført i Kina, som konkluderede, at TDD forbedrede procesopfølgning og opgaveestimering. Den samme undersøgelse konkluderer, at "TDD også fremmer overholdelsen af konsekvente praksisser og retningslinjer." Dette resulterer i bedre kvalitet med færre fejl. De teams, der anvendte TDD, var også bedre i stand til at rette deres fejl hurtigere (Kilde).  

En undersøgelse blandt udviklere med omkring ti års erhvervserfaring (i gennemsnit) havde til formål at undersøge deres opfattelser ved anvendelse af TDD og citerer en udvikler, der siger: "TDD har hjulpet mig med at forbedre koden og gjort den mere læsbar." En anden deltager rapporterer, at "TDD giver større vedligeholdelsesvenlighed" (Kilde).  

Fremmer TDD et enklere design?

Boby George og Laurie Williams, der begge arbejdede på Institut for Datalogi ved North Carolina State University, gennemførte et eksperiment, hvor 24 programmører blev opdelt i to grupper: Den ene anvendte TDD, og den anden anvendte den lineære tilgang.

George og Williams rapporterer, at "92 % af udviklerne mente, at TDD giver kode af højere kvalitet, 79 % mente, at TDD fremmer et enklere design, og 71 % mente, at tilgangen var mærkbart effektiv" (Kilde).  

Disse statistikker om testdrevet udvikling og kvalitet giver en stærk indikation af, at TDD faktisk resulterer i kode af højere kvalitet og et enklere design.

I en artikel udgivet af den gratis læringsportal Guru99.com siger Kanchan Kulkarni: "TDD gør koden enklere og tydeligere. Det gør det muligt for udvikleren at vedligeholde mindre dokumentation" (Kilde). 

Er det nemt at indføre TDD-design?

I George og Williams' eksperiment mente 56 % af de professionelle udviklere, at det var vanskeligt at indtage en TDD-tankegang, mens 23 % hævdede, at manglen på en indledende designfase var årsagen til denne vanskelighed. Af alle svarene mente 40 %, at det var vanskeligt at indføre TDD (Kilde).

Disse statistikker om testdrevet udvikling og indførelse viser, at TDD anses for at være vanskeligt at indføre.

Er TDD overvurderet? 

I en artikel udgivet på Medium.com bruger Tylor Borgeson, som beskriver sig selv som en fullstack-softwareudvikler med interesse for maskinlæring, AI, infrastruktur, DevOps og agil udvikling, overskriften "Testdrevet udvikling er overvurderet." Det faktum, at han har sat overskriften i anførselstegn, viser imidlertid, at dette ikke er et udsagn, han selv fremsætter.  

Borgeson henvender sig derefter til dem, der siger, at metoden er overvurderet og langsom, og fortæller dem, at de fleste, der har denne opfattelse, ikke har anvendt metoden længe nok. Som afslutning på sin artikel siger han: "Gå nu ud og øv dig i testdrevet udvikling, indtil det ikke længere gør ondt" (Kilde).

Hvad er det næste?

Lær om QA-tilgange fra eksperter i podcasten The QA Lead

Tilmeld dig nyhedsbrevet fra The QA Lead for at få vores nyeste vejledninger og podcastafsnit

Skriv dig på ventelisten til The QA Leads onlineforum, hvor du kan dele bedste praksis med andre fagfolk inden for QA og softwaretest.

Håber, vi ses der!