Ekspert: Danske udviklere sjofler test af deres kode

Der er ikke samme håndværksmæssige kunnen som før hos udviklerne, mener dansk proceskonsulent. Derfor er der tit alt for mange fejl i store projekter, selvom de kunne undgås.

Når et stort it-projekt viser sig ikke at virke efter hensigten - måske oven i købet efter flere års forsinkelse - venter en dyr og besværlig brandslukning og oprydning, før kunden kan blive tilfreds. Måske må systemet faktisk opgives helt, som det for nyligt skete for politiets Polsag-system til en halv milliard kroner.

Men disse problemer kan forebygges, og ofte kan fejlene føres tilbage til manglende test og forkert design hos de enkelte udviklere. Sådan lyder meldingen fra Jakob Føns, der i 14 år har arbejdet som proceskonsulent for store it-projekter og i dag har firmaet SQA Consult.

»Når kvaliteten ikke er høj nok, er det tit, at nye teknologier og højere kompleksitet i it-systemerne får skylden. Men i de fleste projekter er det svage led de enkelte udvikleres basale håndværksmæssige kunnen, altså det at skrue et stykke kode sammen, så det virker efter hensigten,« siger Jakob Føns til Version2.

Hans arbejde består typisk af at analysere nødlidende it-projekter og finde årsagerne til, at der er for mange fejl, når hele komplekset bliver sat sammen og skal brugertestes.

Og selvom det ikke kan gøres til en generel regel, oplever han tit, at der ikke er nok fokus på at kvalitetssikre koden i det første led - direkte fra den enkelte udviklers hånd.

Det var for eksempel problemet på KMD’s store projekt Opera. Her kæmpede projektledelsen med et højt antal fejl i koden og forsøgte at forbedre test-funktionen sidst på ’samlebåndet’.

Da en analyse i stedet viste, at problemerne opstod helt i starten af processen, blev der sat ind her, og det nedbragte antallet af fejl i koden med hele 50 procent. Samtidigt blev den samlede produktivitet rundt regnet fordoblet.

Læs mere om kodefejlene Opera-projektet: Truende fiasko vendt til succes: Sådan lugede KMD 3 ud af 4 softwarefejl væk i monsterprojekt

Det er god skik at unit-teste al kode, altså sikre at hver en stump løser sin opgave rigtigt, men alligevel sker det ofte alt for tilfældigt, forklarer konsulenten.

Løsningen er enten kun at have dygtige udviklere, som også altid sætter en ære i at teste hver eneste kode-aflevering grundigt - eller at projektledelsen stiller faste krav om unit-test af al koden.

»For at være en rigtig dygtig udvikler, skal man være ekstremt stærk på både teknologi, logik og systematik. Men disse typer er der ikke nok af til at dække it-branchens behov for udviklere. Så du kan ikke overlade det til den enkelte, men må stille krav om fælles standarder for design og unit-test,« siger Jakob Føns.

Fjern 95 procent af fejlene

Det er svært og meget dyrt at undgå alle fejl i et stykke kode, men målet er også bare at bringe det ned på et acceptabelt niveau. Det giver nemlig den bedste økonomi alt i alt.

»Hos Nasa er det vildt dyrt at udvikle software, fordi hele missionen er på spil, og der ikke må være fejl i. Men for almindelige it-projekter er det optimalt at få fjernet 95 procent af alle fejl, inden systemet kommer i produktion. Projekter, der leverer dårligere kvalitet, er også dyrere,« siger Jakob Føns.

Desværre lever de fleste it-projekter ikke op til den standard og har altså væsentligt flere fejl, der skal rettes i produktionssoftwaren. Opgaven med at luge fejl ud, når softwaren skal i produktion, bliver overladt til test- og kvalitetssikringsfolk, og nogle steder kan det også godt lade sig gøre at få et godt produkt ud til sidst. Det koster bare mange kræfter.

»Hvis man er dygtig til systemtest, kan man måske godt levere god kvalitet i sidste ende. Men hvis man i stedet kunne forhindre mange af fejlene fra at komme ind i systemet i første omgang, kunne man gøre det meget billigere,« siger proceskonsulenten.

Han henviser til forskning fra amerikaneren Barry Boehm, der konkluderede, at besparelserne typisk ville være 40-50 procent af projektets samlede pris, hvis man strammede op og fulgte velkendte best practices.

»Det er et astronomisk beløb, der er på spil. Den slags afgør, om et firma overlever eller ej,« siger Jakob Føns.

Brandslukkerne får heltestatus

Alligevel er der ikke ret meget fokus på at tage fejlene ved roden, selvom prisen for at rette en fejl stiger med en faktor ti, hver gang fejlen smutter videre til næste fase af projektet.

»Og selvom man retter fejlen til sidst, bliver det aldrig samme kvalitet, som hvis man havde undgået den fra starten af. Man ender med en lappe-løsning, som bliver meget dyrere at vedligeholde,« siger han.

En af forklaringerne på, at området ikke får mere opmærksomhed, kan være kulturen omkring dem, der bliver sat til at rette fejlene. Det er tit de dygtigste udviklere, som får til opgave at være brandmænd og redde hele projektet, hvis det kører skævt.

»Det bliver dem, som sidder hele natten og finder fejl, som bliver projektets helte. Der er ikke samme prestige i bare at aflevere kode, som er gennemtestet og virker. Men kulturen skal ændres, og den onde cirkel skal brydes, så de dygtigste bliver flyttet hen tidligere i processen. Der skal være prestige i at arbejde med arkitektur og teknikker til test-automatisering,« siger Jakob Føns.

Udviklerne kan også føle, at der ikke er tillid til deres evner, når der bliver indført fastere krav om test af alle kodestumper. Derfor er det også meget vigtigt ikke at bruge analyserne af de fejl, der opstår, til at rangordne medarbejderne.

»Der kommer aldrig noget godt ud af at udpege enkelte udviklere som gode eller dårlige. Måske har de udviklere, som laver flest fejl, også de mest komplekse opgaver,« siger konsulenten.

Krav om unit-test og mere kontrol af koden fra starten af er i øvrigt kun ét ud af flere værktøjer for at få skabt en god, velfungerende it-løsning, understreger Jakob Føns. Et andet indsatsområde er for eksempel at skifte vandfaldsmodellen ud med agil udvikling. Kort fortalt handler det om at dele opgaverne op i små, afsluttede bidder og løbende tilpasse systemet til kundens krav.

Får man tidligt i projektforløbet bygget det grundlæggende skelet i et it-system og sikret sig at kritiske krav kan opfyldes, så bliver det også meget nemmere at teste resten af koden løbende. Men ingen af løsningerne er mirakelkure hver for sig.

»Agil udvikling i form af Scrum hjælper på at få den rigtige løsning. Men skal man nærme sig fejlfri og vedligeholdelsesvenlig kode, skal der også fokus på mere basale best practices inden for software engineering,« siger Jakob Føns.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Simon Jonassen

Der er ikke samme håndværksmæssige kunnen som før hos udviklerne, mener dansk proceskonsulent. Derfor er der tit alt for mange fejl i store projekter, selvom de kunne undgås.

Kunne det tænkes at udviklerne bliver presset for meget, med stramme deadlines osv ?

I øvrigt, så skal koden helst testes hele vejen igennem processen, ikke bare til slut !

Man kunne faktisk få nogle hele fantastiske produkter hvis man lyttede mere til kunden og involverede kunden i udviklingsprocessen, så får man jo taget hånd om fejl, uhensigtsmæssigheder og misforståelser med det samme !

/Simon :-)

  • 6
  • 0
Henrik Rathje

yeps... også her er agil udvikling en fordel.. det fordeler ansvar til kunden.. ansvar for at tage stilling til hver eneste stykke funktionalitet, og hvordan det kan, skal kunne, testes.

dog kan scrum ikke løse noget, men kun guide.. for den store udfordring er at få forretningen til at tage netop ANSVAR.. det er ikke udvikleren, der skal afgøre hvordan og hvad der skal funktionelt testes.. det er forretningen.
unit tests er fine, men det er kvaliteten af disse tests der er vigtige.. det er jo nemt at lave en unittest der ikke tester det korrekte.
code coverage i forbindelse med unit test, test-driven-development mm. er vejen frem.. i store projekter.. i små projekter er det ofte overkill der hæmmer sig selv.. men det er en laaang snak :-)

er dog lidt ked af af alle udviklere i princippet nu skydes for boven at de er inkompetente!.. det er MEGET mere komplekst end det, og netop som Simon siger: har nogen måske presset på for at få mere funktionalitet og skrue ned for testen? igen vil en agil tankegang med ansvarsfordeling til forretningen kunne hjælpe.

test-first er et godt princip her.. og det skal især forretningen lære at bruge.

SÅ. det er ikke kun udviklere der skal være obs på test.. det er i HØJ grad endnu mere forretningen/kunden der skal være obs!

  • 3
  • 0
Erik Silkjær

"... at projektledelsen stiller faste krav om unit-test af al koden". Det har altid været god latin.
Unit-test udføres typisk af den udvikler, der har skrevet koden. Men har han/hun lært at teste?
Mange fejl kunne undgås hvis it-virksomhederne sikrede sig, at dem de sætter til at teste også har den fornødne udannelse.
Man sætter ikke en tester til at kode, uden at testeren har lært at kode, vel? Men det omvendte er helt normalt. Altså at en udvikler tester uden at have lært det!

  • 0
  • 0
Erik Silkjær

"... at projektledelsen stiller faste krav om unit-test af al koden". Det har altid været god latin.
Unit-test udføres typisk af den udvikler, der har skrevet koden. Men har han/hun lært at teste?
Mange fejl kunne undgås hvis it-virksomhederne sikrede sig, at dem de sætter til at teste også har den fornødne udannelse.
Man sætter ikke en tester til at kode, uden at testeren har lært at kode, vel? Men det omvendte er helt normalt. Altså at en udvikler tester uden at have lært det!

  • 0
  • 0
Erik Silkjær

"... at projektledelsen stiller faste krav om unit-test af al koden". Det har altid været god latin.
Unit-test udføres typisk af den udvikler, der har skrevet koden. Men har han/hun lært at teste?
Mange fejl kunne undgås hvis it-virksomhederne sikrede sig, at dem de sætter til at teste også har den fornødne udannelse.
Man sætter ikke en tester til at kode, uden at testeren har lært at kode, vel? Men det omvendte er helt normalt. Altså at en udvikler tester uden at have lært det!

  • 0
  • 0
Henrik Rathje

mjoee.. men hvis han/hun har hørt efter i timen, så burde de kende til unit tests.

code coverage tools kan så nemt afsløre om de tester de korrekte dele af koden.

det er så kodehyrden/arkitekten/teknisk PLs opgave at checke at det overholdes og at unittests har en reel kvalitet.
Udover at der seføli ALTID skal være review af unit tests.. review bør naturligvis foretages af en anden udvikler end den der har skrevet koden, og sammen gennemgår de den så.

Du har nok ret i at det er sådan det BURDE være, men ofte prioriteres tests (alle former) meget lavt.. især når dealine nærmer sig.. skarpt forfulgt af manglende dokumentation!

heldigvis ser det fra min stol ud til, at denne trend er ved at forsvinde.. og test bliver mere og mere en integreret del af udviklingen. Og er efterhånden ogsånoget der finder vej til krav specs hos kunderne.. heldigvis.

  • 1
  • 0
Simon Jonassen

En programmør kan da sagtens teste sit kode uden at ha' en stor frokromet uddannelse ! Det er dog ikke sikker at han/hun formår at lave de samme slags "stress-test" som én der kun beskæftiger sig med test.....

Den allerbedste tester er jo den der skal anvende systemet i sin dagligdag.... det er også der jeg vil hen - involvere dog de personer som skal sidde med systemet dagen lang !

/Simon :-)

  • 2
  • 0
Christian Jul Jensen

Som jeg oplever det vil de fleste udviklere meget meget gerne have lov til at gøre tingene "rigtigt" med unit-test / TDD, CI/CD osv.

Men oftest er kunder mest fokuseret på den umiddelbare anskaffelsespris, og test-coverage er simplethen ikke en parameter der bliver lagt vægt på. Det er stort set altid kun antal features og pris.

Jeg har efterhånden besvaret en del off. udbud og andre RFP'er, og der er stort set aldrig konkrete mål for kode-kvalitet og test-coverage, når det svinger sig højt skal man levere en beskrivelse af procedurer for kvalitetssikring.

Men lur mig om ikke det oftest er den med lavest pris pr. feature ratio der får opgaven.

  • 3
  • 0
Simon Jonassen

Selvfølgelig skal kunden ha' fokus på kvalitet kontra pris - men bare fordi kunden får det "billigt" behøver man da ikke at slække på test i udviklingsfasen !

Alt for mange gange har jeg set at "kunden" ikke er kunden - dvs. at "kunden" er et organ som skal styre projektforløbet og ikke den "lille" mand på gulvet som egentlig skal anvende systemet.....

Desværre bliver den rigtig kunde næsten aldrig indraget i projektet men bliver bare præsenteret for et eller andet mere eller mindre færdig produkt !

/Simon :-)

  • 0
  • 0
Chris Bagge

Jeg kan sagtens være enig med Jakob i, at det er vigtigt at den enkelte udvikler får testet sin software, og at testen kan genbruges, når der skal laves rettelser. Det der, efter min erfaring koster kassen, er når systemovervejelserne og grænseflader ikke er på plads i store systemer. Et manglende overordnet systemdesign er vigtigt. Hvordan tester en udvikleren de krav der ikke blev specificeret / blev forkert specificeret? Den Agile model med en 'stakeholder' der løbende følger med holder ikke for store systemer. Man begynder ikke 'lige' at lave om på kravene til interfacet mellem to leverandører.

For at få en kultur på banen, hvor test indgår positivt, så er vi også nødt til at komme væk fra vores "hvem er den skyldige" holdning. Dette så vi finder ud af hvorfor fejl opstår, så vi kan få håndteret det.

Det at finde de mange fejl, og få udbedret dem, er en, om end nødvendig, årsagsbehandling. Vi skal i stedet for hen og finde fejl og mangler så tidligt som muligt og også meget gerne årsagen til at de opstod.

  • 0
  • 0
Thomas Eldblom

Efter at have brugt en del år efterhånden på at udvikle og kigge på andre udvikleres løsninger er det min erfaring at kvalitetsproblemer oftere ligger i udviklerens personlige ambitioner og kompetencer end i kendskabet til metoder og værktøjer. Hvis vi i udviklerstanden var halvt så dygtige til at holde os til kun at løse kravene og skrive pæn - clean - kode som vi er til at kaste os over design patterns, forkromede arkitekturer og nye værktøjer så ville kvaliteten være væsentlig bedre.

  • 3
  • 0
Frithiof Andreas Jensen

Kunne det tænkes at udviklerne bliver presset for meget, med stramme deadlines osv ?


Det kan også tænkes at udviklerne presser sig selv for meget ved at hive en masse spændende tools og frameworks ind i projektet uden at have hverken tid eller ressourcer afsat i projektet til at lære hvordan man bruger dem ordentligt.

... Næste projekt har man lært noget af erfaringen og bruger nye frameworks og tools fordi "de gamle var noget lort" ... ;)

  • 0
  • 0
Michael Christensen

Efter min mening, så gøres der for lidt ud af test. Der allokeres ikke ressourcer nok til teste. Jo tidligere, der testes i et projekt - også kravspec og anden basis dokumentation, jo billigere er fejlene at rette - og jo mindre impact får de måske i projektet. Udviklerne kan godt teste visse dele af deres kode selv, men ofte er friske, uafhængige og kritiske øjne godt at have på. Da jeg midt på eftermiddagen kiggede her på V2, så jeg tre artikler om test. Denne og to, hvor ting var ved at skride. Det tyder på, at selv i store projekter, så er test en undervurderet diciplin.

  • 0
  • 0
Jakob Føns

Jeg havde nok valgt en anden titel til indlægget. Noget i stil med "Pris og kvalitet kan godt gå hånd i hånd", da jeg ikke er interesseret i ensidigt at placere skylden for manglende kvalitet hos udviklerne, men det er så til gengæld en kedelig titel.

Jeg er meget enig i kommentarerne og er, som det fremgår af indlægget, stor fortaler for agil udvikling. Scrum alene er dog ikke nogen garanti for succes. Agil udvikling handler også om enkelt design og testautomatisering.

Der er her en ting, som måske ikke fremgik klart nok af indlægget. Jeg omtaler de rene programmeringsfejl, hvor den enkelte udvikler laver et stykke kode, der ikke virker som udvikleren selv havde tænkt sig. På en række nødlidende projekter har jeg foretaget fejlanalyser der viste, at omkring 80% af alle fejl var af denne type. Udviklerne klassificerede selv fejlene og var enige i analysernes resultater. Denne type fejl kan udviklerne sagtens forebygge, når de bliver opmærksomme på problemet.

Når analytikere, udviklere og testere sættes sammen i et team og får rammerne til at organisere deres eget arbejde, da lærer de af hinandens styrker og løfter det fælles kompetenceniveau.

En af de rigtige gode elementer i Scrum er den såkaldte Retrospective, der afslutter hvert sprint (iteration), hvor fokus er på procesoptimering.

Styrkelse af test kompetencerne hos den enkelte udvikler hjælper ikke kun på unit testen. Det fører til et bedre internt design i de enkelte komponenter og har en fejlforebyggende effekt. Tidlig test er godt, men forebyggelse er naturligvis endnu bedre.

På nystartede udviklingsprojekter bør man så vidt muligt sikre, at alle test løbende automatiseres (f.eks. test driven development). Det er helt afgørende for projektets mulighed for løbende at tilpasse it-systemet til nye krav. Hvis testautomatiseringen ikke indføres fra staren af, så mister projektet i praksis hurtigt denne mulighed og sætter agiliteten over styr.

  • 0
  • 0
Michael Christensen

De agile metoder fordrer en test efter afslutning af iterationerne. Er testen ikke automatiseret, så bliver denne test efter blot få iterationer alt, alt for omfattende at gennemføre, dermed bliver den af hensyn til omkostningerne reduceret, så den kun dækker de nye elementer i koden - og så bliver den værdiløs, da den ikke tager højde for påvirkning af eksisterende elementer i koden.

Tidlig test er godt. I min optik er tidlig test også test af, om der er:
- modstridende krav,
- krav, der er umulige at opfylde,
- krav, der er misforståede osv.

Ved at teste så tidligt, at der ikke er skrevet kode endnu, så kan du fange nogle af de ovennævnte bøffer, der kan være nogle af de allerdyreste i et projekt.

Udviklerne kan langt hen af vejen teste deres egen kode - eller kollegernes; men jeg er helt enig i, at sammenfletning af udviklere, testere og folk fra forretningen bidrager til, at testprocessen bliver endnu mere effektiv, da programmører kan blive "blinde" overfor problematiske områder i koden (egen dårlig erfaring).

  • 0
  • 0
Jakob Føns

Men lur mig om ikke det oftest er den med lavest pris pr. feature ratio der får opgaven.

Det er naturligvis rigtigt, og her er den vigtige pointe, at pris og kvalitet går hånd i hånd, når man satser på fejlforebyggelse og tidlig test.

De organisationer, der internt fokuserer på høj kvalitet i hele udviklingsforløbet, opnår den mindste udviklingstid og kan derfor tilbyde den laveste pris.

Hvis man udelukkende fokuserer på time-to-market, bliver man oftests indhentet af den dårlige kvalitet inden man kan levere første version af produktet.

Se f.eks. denne artikel af Steve McConnell: http://www.stevemcconnell.com/articles/art04.htm

  • 1
  • 0
Log ind eller Opret konto for at kommentere