Fordeler ved testdrevet utvikling: Viktig statistikk og forskning

I denne artikkelen gjennomgår jeg statistikk og studier om testdrevet utvikling for å forstå hvordan det har blitt tatt i bruk, fordelene med metoden og utfordringene team møter med denne tilnærmingen.

Tradisjonelt foregår programvareutviklingsprosessen lineært. I løpet av de siste tiårene har imidlertid programvareutvikling begynt å ta i bruk ulike metoder som tar hensyn til prosjektets krav og egenart, etter hvert som smidige systemer blir stadig mer populære (så mange som 87% av teamene følger en smidig eller smidiglignende tilnærming).

Teknikken testdrevet utvikling (TDD) er én av metodene som har fått oppmerksomhet innen smidig programvareutvikling.  

I en forskningsartikkel publisert av Institute of Electrical and Electronics Engineers sier forfatterne Yahya Rafique og Vojislav Misic at «Testdrevet utvikling (TDD) er blant kjernepraksisene i utviklingsprosessen ekstrem programmering (XP)» (Kilde). 

Mannen som skal ha utviklet TDD, skal ha «uttalt i 2003 at TDD oppmuntrer til enkel utforming og skaper tillit» (Kilde). Det er imidlertid fortsatt spørsmål knyttet til påstandene om produktivitet og kvalitet som er fremsatt om TDD. 

Vi tok oss tid til å samle inn den nyeste TDD-statistikken for å undersøke påstandene.

Denne artikkelen begynner med å definere TDD-konseptet og hvordan det skiller seg fra den tradisjonelle tilnærmingen. Deretter ser vi på noe av statistikken som enten bekrefter eller avviser påstandene om TDD.    

Hva er testdrevet utvikling?

Testdrevet utvikling er en tilnærming der en test skrives før programvareutvikleren lager produksjonskoden som skal oppfylle testen. Grunntanken med denne teknikken er å gi den som skriver koden tid til å vurdere utformingen eller kravene før funksjonell kode skrives.  

TDD-prosessen

1. Skrive testen: I TDD begynner alle nye funksjoner med at det skrives en test. Programmereren må forstå spesifikasjonen og kravene til funksjonen. For å oppnå dette må programmereren gå gjennom brukerhistorier og brukstilfeller for å forstå hensikten med den nye koden som utvikles.   
2. Testen mislykkes: Når programmereren har skrevet testen, kjøres den. Siden det ennå ikke finnes kode som implementerer den, vil testen mislykkes. Dette bekrefter at det automatiserte testrammeverket fungerer som det skal, og utelukker muligheten for at den nye testen alltid vil bestå fordi den er mangelfull. 
3. Skrive koden: Nå vet programmereren at funksjonen fungerer i henhold til utformingen. Deretter skriver programmereren koden som består testen. Koden trenger ikke å være perfekt eller bestå testen på en fremragende måte, men det spiller ingen rolle. Utvikleren forventes ikke å skrive kode utover funksjonaliteten testen ble laget for å kontrollere.
4. Kjøre tester: Når programmereren vet at funksjonen fungerer som utformet, kan programmereren bruke et teststyringsverktøy til å kjøre testen på nytt hver gang ny kode lanseres. Dette gir bekreftelse på at den nyeste oppdateringen ikke har ødelagt den tidligere funksjonen.  
5. Refaktorere kode: I TDD må kodebasen kontinuerlig ryddes opp etter hvert som den vokser. Ettersom programmererens hovedfokus i de foregående trinnene var å skrive koden, sørger dette trinnet for effektivitet. Det gjør det mulig å forbedre den interne strukturen i programmets kildekode samtidig som de eksterne egenskapene bevares. Dette trinnet kan fjerne dupliseringer og legge til ny funksjonalitet.   
6. Gjenta: Trinnene ovenfor gjentas automatisk for å sikre at TDD-syklusene dekker alle funksjonene.  

Forskjeller mellom TDD og tradisjonell utvikling

For å forstå TDD virker det hensiktsmessig å se på hvordan metoden skiller seg fra tradisjonelle tilnærminger til programmering.

Hovedforskjellen er at tradisjonelle metoder følger en lineær prosess, mens TDD går gjennom en syklisk prosess. 

Programmerere som bruker tradisjonelle testmetoder, begynner med å lage koden og konsentrerer seg først om testen på slutten av utviklingsprosessen. På den annen side begynner den som følger TDD-modellen, med å lage testen og utvikler deretter koden som oppfyller testen. Denne tilnærmingen deler mange prinsipper med «shift left»-bevegelsen innen programvaretesting.

Mens programmereren som bruker den tradisjonelle tilnærmingen, kan rette oppmerksomheten mot at koden er korrekt, risikerer vedkommende å ikke oppdage alle feilene i koden. Programmereren som bruker TDD-metoden, arbeider med koden til den består testen, gjennom refaktorering av koden. Dette gjøres til koden oppfyller funksjonaliteten, en prosess som sannsynligvis fører til færre feil.

Er TDD tregere eller raskere enn tradisjonell testutvikling?

Når det gjelder spørsmålet om TDD gjør programmeringsprosessen raskere, finnes det motstridende statistikk fra ulike kilder. 

En casestudie som involverte programvareingeniørteam fra Microsoft og IBM, konkluderte med at «teamene opplevde en økning på 15–35 % i den innledende utviklingstiden» da de brukte TDD-teknikken. Studien påpeker imidlertid at dette er tall som «er subjektivt anslått av ledelsen» (Kilde). 

Hvis man ser på dette fra perspektivet om at studiene fra Microsoft og IBM viser at kvaliteten ble forbedret, kan man hevde at TDD på lang sikt sparer tiden som ellers ville vært nødvendig for å rette opp problemer. Teamene hos Microsoft og IBM var enige i dette synet (Kilde). 

En studie som fokuserte på de innledende oppfatningene til erfarne fagfolk som brukte TDD, konkluderer med at «etter å ha overvunnet de innledende utfordringene med å forstå hvor man skal begynne, og hvordan man lager en test for en funksjon som ennå ikke finnes, får deltakerne større trygghet til å implementere nye funksjoner og gjøre endringer på grunn av den brede testdekningen» (Kilde). Dette synes å antyde at ting blir bedre med tiden. 

I en tekst for den nettbaserte publiseringsplattformen Medium.com fokuserer programmereren og forfatteren av «Sammensetting av programvare» og «Programmering av JavaScript-applikasjoner», Erick Elliot, på hvordan TDD endret livet hans. Elliot hevder at prosessen kan være treg i begynnelsen, men sier: «Et sted rundt toårsmerket begynte noe magisk å skje: Jeg begynte å kode raskere med enhetstester enn jeg noen gang hadde gjort uten dem» (Kilde).  

Det ser ut til at bruk av TDD kan gjøre ting tregere i begynnelsen. Men hvis man ser på det i et langsiktig perspektiv, kan tiden som spares gjennom kode av bedre kvalitet, kompensere for tiden som går tapt i begynnelsen. Det kan også forventes at programmerere sannsynligvis arbeider raskere etter hvert som de blir bedre på TDD. 

Det finnes også mange andre faktorer å ta hensyn til når man prøver å måle tiden det tar å oppnå et resultat av høy kvalitet. Hvis du vil vite mer om dette, kan du høre på episoden med Niall Lynch i The QA Lead-podkasten om måling av T2Q (Tid til kvalitet).

Fører TDD til færre feil?  

I diskusjonen ovenfor er en av de viktigste fordelene ved TDD som ble presentert, at det fører til færre feil. Men er statistikken enig i dette? 

De samme studiene som involverte ingeniørteamene hos Microsoft og IBM, konkluderte med at «feiltettheten før lansering for de fire produktene gikk ned med mellom 40 % og 90 % sammenlignet med tilsvarende prosjekter som ikke brukte TDD-praksisen». IBM-teamene rapporterte spesifikt en nedgang på 40 % i feiltetthet, mens teamene hos Microsoft rapporterte en nedgang på 60–90 % (Kilde). 

Støtter statistikk om testdrevet utvikling konklusjonen om at TDD gir bedre kvalitet?

Basert på resultatene fra en studie som ble presentert på det første internasjonale IEEE-symposiet i Finland i 2007, rapporterer Maria Siniaalto og Pekka Abrahamsson at TDD har vist seg å gi bedre kodekvalitet sammenlignet med programvare som er utviklet uten TDD (Kilde). 

I artikkelen sin viser Siniaalto og Abrahamsson til en studie gjennomført i Kina, som konkluderte med at TDD forbedret prosessoppfølging og oppgaveestimering. Den samme studien konkluderer med at «TDD også fremmer etterlevelsen av konsekvente praksiser og retningslinjer.» Dette gir bedre kvalitet med færre feil. Teamene som brukte TDD, var også bedre i stand til å rette feilene sine raskere (Kilde).  

En studie gjennomført blant utviklere med omtrent ti års yrkeserfaring i gjennomsnitt, for å undersøke deres oppfatninger ved bruk av TDD, siterer en utvikler som sier: «TDD har hjulpet meg med å forbedre koden og gjøre den mer lesbar.» En annen deltaker rapporterer at «TDD gir bedre vedlikeholdbarhet» (Kilde).  

Fremmer TDD enklere design?

Bobby George og Laurie Williams, som begge arbeider ved Institutt for informatikk ved North Carolina State University, gjennomførte et eksperiment der 24 programmerere ble delt inn i to grupper: den ene brukte TDD, og den andre den lineære tilnærmingen.

George og Williams rapporterer at av deltakerne mente «92 % av utviklerne at TDD gir kode av høyere kvalitet, 79 % mente at TDD fremmer enklere design, og 71 % mente at tilnærmingen var merkbart effektiv» (Kilde).  

Denne statistikken om testdrevet utvikling og kvalitet gir en sterk indikasjon på at TDD faktisk resulterer i kode av høyere kvalitet og enklere design.

I en artikkel publisert av den gratis læringsportalen Guru99.com sier Kanchan Kulkarni: «TDD gjør koden enklere og tydeligere. Det gjør det mulig for utvikleren å vedlikeholde mindre dokumentasjon» (Kilde). 

Er det enkelt å ta i bruk TDD-design?

Basert på eksperimentet til George og Williams mente 56 % av de profesjonelle utviklerne at det var vanskelig å komme inn i en TDD-tankegang, mens 23 % hevdet at mangelen på en innledende designfase var årsaken til denne vanskeligheten. Av alle svarene mente 40 % at det er vanskelig å ta i bruk TDD (Kilde).

Denne statistikken om testdrevet utvikling og innføring viser at TDD oppfattes som vanskelig å ta i bruk.

Er TDD overvurdert? 

I en artikkel publisert på Medium.com bruker Tylor Borgeson, som omtaler seg selv som en fullstack-programvareutvikler med interesse for maskinlæring, KI, infrastruktur, DevOps og smidig utvikling, overskriften «Testdrevet utvikling er overvurdert.» Det at han har satt overskriften i anførselstegn, viser imidlertid at dette ikke er et utsagn han selv kommer med.  

Borgeson henvender seg deretter til dem som sier at metoden er overvurdert og langsom, og forteller dem at de fleste som har dette synet, ikke har brukt metoden lenge nok. På slutten av artikkelen sier han: «Gå nå og øv på testdrevet utvikling til det ikke gjør vondt lenger» (Kilde).

Hva skjer videre?

Lær om QA-metoder fra eksperter i The QA Lead-podkasten

Meld deg på nyhetsbrevet til The QA Lead for å få våre nyeste veiledninger og podkastepisoder

Meld deg på ventelisten til The QA Leads nettbaserte fellesskapsforum, der du kan dele beste praksis med andre fagfolk innen QA og programvaretesting.

Håper vi sees der!