Derfor opstår der fejl i softwareudvikling

Estimeret læsetid: 13 minutter

Du undrer dig måske over, hvorfor mennesker kan lykkes med at gennemføre store og komplekse byggeprojekter, og alligevel kæmper it-virksomheder med at levere softwareprojekter uden fejl. Her vil vi drøfte nogle grunde til, at der opstår fejl i softwareudvikling samt forslag til, hvad der kan gøres for at reducere eller helt undgå disse fejl.

To typer fejl

I grove træk så kan “programmeringsfejl” opdeles i to kategorier:

Den første består i egentlige fejl, hvorved noget ikke fungerer, mens den anden mere er en "forståelsesfejl", hvor kunden forventede et andet resultat, end dét han eller hun modtog.

Vi gennemgår mulige årsager til begge disse kategorier. Disse årsager er ikke stillet op for at indgyde tolerance overfor sløset softwareudviklingspraksis - men snarere for at sige, at selv når alt vedrørende processen er godt på plads, så er softwareudvikling stadig et meget udfordrende område.

Hvorfor opstår der programmeringsfejl?

En programmeringsfejl er en fejl, der får en hjemmeside, webshop, app eller anden software til pludselig ikke at virke eller at opføre sig underligt i forskellige situationer. Dette sker normalt på grund af en fejl i koden, eller fordi et eksternt system ikke fungerer som forventet.

Programmeringsfejl kan være særdeles frustrerende, fordi de ofte forekommer på de mest ubelejlige tidspunkter og i uventede “hjørner” af dit system.

Typisk opstår der fejl fordi udvikleren:

undlod at forudse en bestemt brugerhandling eller opførsel
begik en oplagt fejl
glemte at kontrollere om de data, der kræves for at udføre en handling, helt mangler eller er ukorrekte
brugte et eksternt system, der er offline eller leverer ukorrekte data
brugte funktionsbiblioteker, dvs. programtyper der er indbygget i operativsystemet, såsom Windows, som enten er forældede eller slet ikke findes på computeren eller serveren, hvor softwaren er installeret
arbejdede på opgaver, der måske har ligget uden for deres kompetence.

Softwarens kompleksitet

Når alt kommer til alt, så skabes software af mennesker, og mennesker vil uvægerligt begå fejl. Da mennesker udvikler software, vil det være irrationelt at forvente fejlfri software.

Når det så er sagt, er det også en kendsgerning, at al software, der er udviklet til at fungere med bestemte formål, er ekstremt kompleks, og ingen enkeltperson kan let overskue det hele.

Hver kodelinje kan have tusinder af mulige inputs, outputs, tilstande eller afhængigheder at holde styr på. Man kan sige, at hvor vi ganske vist kan dokumentere alle eventualiteter for hver kodelinje, så kan vi alligevel ikke være sikre på, at der ikke er nogen ukendt faktor, der kan forårsage en fejl. En kodelinje er en del af et helt system, og hele systemet skal testes for at sikre, at alle dele af applikationen fungerer korrekt.

Software påvirkes af eksterne faktorer

Ud over den kode som udgør et stykke software, er der også mange eksterne faktorer, der kan påvirke dets kvalitet. Disse faktorer ligger udenfor udviklerens kontrol, og forsøg på at rette systemet ind efter udfordringerne, som disse eksterne faktorer medfører, kan forårsage øget tidsforbrug og udviklingsomkostninger. Her er nogle ting, der skal med i overvejelserne:

Integration med eksisterende systemer i huset
Server og hosting
Integration med hardware
Integration med tredjepartsleverandører
Regulativer på området
Skalerbarhed

Vigtigheden af at teste software

Hvordan udfører din softwareudvikler tests?

Det er vigtigt at forstå og være enige om, hvordan dit softwarehus skal udføre deres softwaretest, så du ikke ender med at være nødt til at teste systemet selv.

Mange virksomheder hyrer freelancere, der ofte ikke har den infrastruktur eller tid, der er nødvendig for at kunne teste deres eget output. Desuden overser mange udviklere fejl, når de selv er dem, der tester det, de har udviklet. Problemet hér er, at når du er den, der har udviklet systemet, tester du ofte med de samme data og på samme måde. Det er dermed let at overse fejl, som måske havde været mere indlysende for andre personer, som ikke var en del af udviklingen fra starten.

Test skal udføres af personer, hvis eneste job det er at teste, og som har erfaring med, det de laver. For det første vil de være meget hurtigere til det. For det andet gør deres erfaring dem i stand til hurtigt at opdage fejl og dokumentere dem korrekt, så udviklerne kan rette fejlene.

Lidt om automatiseret test og unit tests

Softwares kompleksitet betyder, at det er umuligt at teste det i alle retninger. Softwarefirmaer løser dette problem ved at implementere forskellige processer, såsom at sætte standarder for kodning og benytte forskellige testmetoder.

Automatiseret test er én praksis, som virksomheder kan implementere for at spare tid og gøre tingene hurtigere. Det er imidlertid vigtigt først at overveje omkostningerne ved dens implementering, før det sættes i værk.

Hvis du kun opdaterer din software en eller to gange om året, vil det sandsynligvis blive for dyrt at udvikle automatiserede tests - medmindre det er til applikationer, hvor omkostningerne ved fejl er så høje, at de overstiger omkostningerne ved at udvikle automatiserede tests.

Automatiseret test er især gavnligt til software, hvor du konstant foretager små ændringer og opdateringer måske 3-4 gange om ugen. Desuden er det nærmest umuligt at teste et system 3-4 gange om ugen, så det bliver da ligefrem nødvendigt med automatiserede tests.

Udviklere indarbejder også "programbidder" i deres kode, som automatisk tester dele af systemet. Det er noget af en kompliceret proces, men det er dybest set et stykke software, der automatisk validerer et andet stykke software, når det bliver leveret. Hvis resultaterne ikke stemmer overens, bliver udvikleren underrettet om den fejl, der skal rettes.
Unit test og automatiseret test er to elementer, der bruges i Continuous Integration (CI), hvor en udvikler - i en perfekt verden - blot skal trykke på en knap, når han eller hun afslutter en opgave, hvorefter den automatisk testes og installeres.

Hvordan tester man effektivt?

Man tester hver gang en udvikler har foretaget en ændring eller opdatering af systemet.

Softwaretest er en opgave, der tager tid. Det er en almindelig fejltagelse ikke at teste nok eller helt at se bort fra testfasen, fordi tests forbindes med høje omkostninger og stort tidsforbrug. Dette resulterer imidlertid i, at der kæmpes med fejl, og alle involveret i projektet frustreres, når dét bliver endnu dyrere, og ender med at tage endnu længere tid.

Her er nogle tilgængelige metoder:

Lad brugere finde og rapportere fejlene, selvom denne opsætning muligvis ikke er optimal, medmindre brugerne selv er udviklere eller er meget teknisk orienterede.
Brug eksterne softwaretestere til at gennemgå det færdige system og rapportere fejl, der skal videresendes til udviklerne, selvom dette kan være en tidskrævende proces, da testerne ikke er en del af det interne team.
Brug interne softwaretestere, der arbejder hånd i hånd med udviklerne - dette er en meget effektiv måde at teste på.
Automatisér test, så udviklerne let kan teste det, de har udviklet indtil videre med blot et tryk på en knap. Det kan være dyrt at programmere den software, der udfører den automatiske test. Det er også meget vanskeligt at automatisere frontend-test - selvom dette kan gøres, kan det være både tidskrævende og dyrt, afhængigt af hvilket system der er tale om.

Skiftende krav fra kunden

De fleste kunder eller brugere ved ikke, hvad de vil have, før de ser det. Sandheden er ofte, at det først er, når de rent faktisk begynder at bruge softwaren, at de begynder at forstå, hvad de har brug for. På grund af dette ændrer krav og specifikationer sig konstant gennem udviklingsforløbet, hvilket også kan bidrage til de fejl, der dukker op i det endelige produkt.

Undersøgelser har vist, at et gennemsnitligt softwareudviklingsprojekt undergår cirka 25% ændringer i kravene fra “requirements of completion”-stadiet til dets første udgivelse. Dette er et almindeligt snigende og omsiggribende problem, der tynger næsten alle projekter. Almindeligvis begynder kunder eller deres brugere at snige nye krav ind, når de første designs er gjort færdige. Designet fungerer som et visuelt grundlag for dem til, at tænke dybere over hvad de i egentlig gerne vil have - og dermed lave ændringer.

Ændring af ethvert softwarekrav, selv en lille ændring, kan have utilsigtede konsekvenser. Høj grad af indbyrdes afhængighed mellem modulerne gør systemet fejlbarligt. Her er nogle eksempler:

Den første instruktion fra kunden til sit softwarefirma er at udvikle et system, hvor brugerne først skal registrere sig og logge ind. Systemet kan ikke bruges af anonyme og uregistrerede brugere. Et af modulerne, DisplayProducts, er afhængigt af denne log-in-proces. DisplayProducts er en procedure, der bruges til at vise visse produkter, baseret på brugeren, der er logget ind. Efter nogen tid besluttede kunden at ændre det oprindelige krav, og bad sit softwarefirma om at ændre systemet til at give anonyme brugere lov til at bruge webshoppen. Tilpasning til denne kravændring betyder, at DisplayProducts-proceduren risikerer at fejle, fordi den ikke mere har noget parameter for, hvilke produkter der skal vises, da brugere nu kan bruge websitet uden at logge ind.

Oprindeligt ønskede kunden, at dansk var det eneste sprog, der kunne ses på hele websitet. Undervejs i udviklingen bad kunden sit softwarefirma om at tilføje engelsk som valgmulighed. Denne ændring har stor indflydelse på brugergrænsefladen. Resultatet er, at nogle tekst-labels måske ikke længere passer på visse dele af siden, hvis indholdet på det nye sprog optager mere plads end forventet og planlagt.

Kunden ville have sit softwarefirma til at udvikle en app, der registrerer afstand til et køretøj. Under indsamlingen af krav blev det aftalt, at måleenheden, der skulle bruges, var meter. ShowDistance-proceduren blev udviklet til at vise afstanden i meter. Afstands-outputtet ved denne procedure bruges til at oprette en rapport, der viser afstanden i den korrekte enhed “m”. På et tidspunkt ønskede kunden, at appen skulle ændres og have ændret afstandsenheden fra meter til fod. Hvis ShowDistance-proceduren så bliver ændret til at vise fod som ny måleenhed, men rapporten ikke bliver opdateret til at vise den rette måleenhed, vil rapporten vises forkert med imperiale værdier og metriske måleenheder.

Et modul, der beregner medarbejderløn og laver en rapport, har arbejdet på live-serveren. Kunden gav yderligere oplysninger, der også skulle inkluderes i lønberegningen. Da denne ændring blev implementeret, blev modulet ændret og testet, og det fungerede fint i udviklingsmiljøet. Da systemet blev lanceret live, opstod der imidlertid tilfældige nedbrud. Dette skyldtes en server timeout, forårsaget af den ekstra beregning, der krævedes for at håndtere de tilføjede oplysninger, og den mængde data der skulle processeres. Udviklingsmiljøet havde ikke nok data til at udløse timeout’en.

Fejl på grund af misforståelser

Fejl opstår også som følge af misforståelser eller fejlkommunikation mellem kunden og udvikleren.

Udviklere er ikke tankelæsere, så du kan ikke forvente, at de forstår alt, hvad der skal gøres, og hvordan tingene fungerer i din branche, uden at alle detaljerne er forklaret. Der er ting, der kan være helt logiske for dig, men være volapyk for udviklere uden dit branchekendskab.

Her er nogle tips til minimering af denne type fejl:

Start med at vælge et softwarefirma, der forstår din branche.
Hvis du ikke ved, hvad du vil, skal du ikke påbegynde projektet. Det er rigtig vigtigt, at du ved, hvad du vil have ud af projektet, allerede inden du går i gang.
Lad udvikleren nedfælde specifikationerne baseret på det, du fortæller ham eller hende. Dermed vil der være en ”tjekliste” at følge , og det vil være let at se, om opgaven er forstået korrekt.
Lad være med at sige sådan noget som "Vi finder ud af det senere" eller "Udvikleren ved, hvad der skal gøres, når hun/han kommer til det," hvis du endnu ikke er sikker på, hvad du gerne vil have, der skal ske med projektet. Udvikleren ved det selvfølgelig ikke, hvis ikke du selv gør.
Undgå at lave et kæmpeprojekt fra starten. Målet er at lave en MVP-løsning. Opdel projektet i faser, da det vil være lettere for udvikleren at forstå nøjagtigt hvad, der skal gøres hvornår. Du reducerer også risikoen for, at der udvikles på funktionaliteter, som ender med ikke at blive brugt, fordi du efter hver fase har mulighed for at overveje, hvad der skal være en del af den næste fase, baseret på de ting, du fandt ud af i den foregående fase.
Sidst men ikke mindst: Kommunikér så tydeligt du kan. Misforståelser kan medføre store problemer, men de kan let undgås ved ordentlig kommunikation.

Bug-fri software?

Der er ingen stensikre regler, der kan udrydde softwarebugs, og som du har læst, er der mange faktorer, der spiller ind. Det betyder imidlertid ikke, at softwarefirmaer bare kan læne sig tilbage. I sidste ende er det kvaliteten af deres arbejde - og deres forretning - der står på spil her. Dét er grunden til, at softwareudviklingsfirmaer opretholder processer og indfører kvalitetssikring eller test-units. De investerer også i værktøjer og medarbejdere til at fange fejl, og i sidste ende forbedre kvaliteten af den software, de producerer.

AUTHOR

Peter Skouhus

En dansk iværksætter, der ejer 1902 Software Development, et it-selskab på Filippinerne, hvor han har boet siden 1998. Peter har stor erfaring inden for IT-udvikling, strategisk it-ledelse og salg.