Hvorfor opstår programmeringsfejl?

Udgivet: 22. November 2018

I denne blog vil jeg prøve at forklare hvorfor der ofte opstår bugs når man får lavet softwareudvikling, samt hvad man kan gøre for at mindske antallet af fejl.

Groft sagt kan man dele programmeringsfejl ind i to kategorier: Den første kategori er deciderede programmeringsfejl hvor et eller andet ikke virker; den anden kategori er forståelsesfejl hvor kunden forventer et andet resultat end det han eller hun får.

Programmeringsfejl

En programmeringsfejl er en fejl som gør at en hjemmeside, webshop eller app pludselig ikke virker eller opfører sig mærkeligt i forskellige situationer. Det sker som regel fordi en programmør laver en programmeringsfejl (“bug”), eller fordi et eksternt system ikke fungerer som forventet.

Programmeringsfejl kan være meget frustrerende fordi de har det med at opstå på det mest ubelejligt tidspunkt i et hjørne hvor man ikke forventer det.

Hvorfor opstår programmeringsfejl?

Fejl opstår fordi programmøren eller programmørerne:

  • Ikke forudså en speciel brugerhandling.
  • Lavede en decideret fejl, f.eks. en regnefejl.
  • Glemte at tjekke at de data som er nødvendige for at fuldføre en handling, er til stede, eller de er fejlbehæftet.
  • Benytter et eksternt system som leverer fejlfyldte data eller er offline.
  • Benytter såkaldte biblioteker (programstumper som er indbygget i styresystemet, fx Windows) som enten er forældede eller ikke er til stede på den computer eller server hvor softwaren er installeret.
  • Arbejder på opgaver som ligger ud over deres kompetenceområde.

Ovenstående er kun et meget lille udsnit af de fejl der kan opstå.

Testning

Hvordan tester din leverandør?

Det er vigtigt at man forstår og er enig i hvordan ens softwareleverandør tester det man får udviklet, således at man ikke ender op med selv at skulle teste.

Mange virksomheder får udviklet og bliver supporteret af freelancere som ikke har den infrastruktur (eller tid) som skal til, for at kunne teste deres output.
Hertil kommer at mange begår den fejl at de selv tester det de laver. Problemet er her at når man udvikler, så tester man ofte med de samme data og på den samme måde, og ser derfor ikke de fejl andre som ikke har deltaget i udviklingen, ville se.
Herudover er det en fordel hvis man benytter folk til at teste som er vant til at teste. For det første er de hurtigere, og for det andet ved de erfaringsmæssigt hvor programmørerne laver fejl, og kan derfor hurtigere lokalisere og dokumentere fejlene.

Hvordan undgår man at slutbrugeren finder fejl?

Man tester hver eneste gang en programmør har lavet en ændring.

Softwaretestning er en arbejdsopgave som tager tid. Mange begår den fejl at de ikke tester nok, fordi testning er forbundet med omkostninger og forbrug af tid. Resultatet er så at mange ender med at bruge tid på at kæmpe med fejl, til stor frustration for alle involverede fordi det hele bliver dyrere og ender med at tage mere tid.

Testmetoder:

  • Lad brugerne finde og rapportere fejlene. Det er indlysende at et sådant setup ikke er optimalt medmindre brugerne selv er programmører eller meget teknisk anlagt.
  • Benyt eksterne softwaretestere som gennemgår det færdige system og rapporterer fejl som så sendes videre til programmørerne. Det er en tidskrævende proces, og softwaretesterne kan nemt overse fejl fordi de ikke er en del af udviklingsteamet.
  • Benyt interne softwaretestere som arbejder sammen med programmørerne. Det er en meget effektiv måde at teste på.
  • Automatiser testning således at programmørerne et langt stykke af vejen selv kan teste det de udvikler, ved blot at "trykke på en knap". Problemet med denne løsning er at det er omkostningstungt at programmere det software som udfører den automatiske test. Hertil kommer at det ikke er nemt at automatisere “frontend”-testning. Det kan godt lade sig gøre, men det er tidskrævende og dyrt (naturligvis afhængigt af hvilken type system der er tale om).

Lidt om automatiseret testning

Mange vil sikkert vælge at lave automatiseret testning af deres software, men det er vigtigt at man laver en kalkule over omkostningerne, før man sætter et sådant projekt i søen.

Hvis man kun har behov for at opdatere sit software en eller to gange om året, vil det højst sandsynligt være for dyrt at udvikle automatiseret testning, medmindre der er tale om applikationer hvor omkostningerne ved fejl er så høje at de overstiger omkostningerne ved at udvikle automatisering (banker har helt sikkert automatiseret testning).

Automatiseret testning er specielt godt når man laver mange små ændringer i sit software. Der findes virksomheder som laver opdateringer 3-4 gange om ugen. Det er næsten umuligt at teste en applikation 3 eller 4 gange per uge, så det er derfor nødvendigt at automatisere testning.

Indbyggede softwaretests (unit tests)

Sluttelig skal lige nævnes at nogle programmører indbygger "programstumper" som tester programdele, f.eks. beregninger, automatisk. Det er lidt komplekst, men virker groft sagt på den måde at det resultat som et stykke software leverer, valideres af et andet stykke software automatisk. Hvis de to resultater ikke er ens, så får programmøren besked om at der er en fejl som skal rettes.

Unit tests og automatiseret testning er to af de komponenter som bruges i continuous integration hvor en udvikler, i den perfekte verden, trykker på en knap når han eller hun er færdig med en opgave, og så testes og installeres det som er udviklet, automatisk.
Når continuous integration virker, sparer det meget tid og giver virksomheder mulighed for at lave daglige opdateringer i deres software fordi det hele laves af en computer.

Forståelsesfejl

Den anden kategori af fejl er såkaldte forståelsesfejl, altså en fejl som er opstået fordi programmøren ikke har forstået hvad der skal laves, eller laver fejl som burde være undgået hvis programmøren havde forstået opgaven korrekt.

Programmører kan ikke læse tanker, og man kan ikke forvente at han eller hun forstår alt hvad der skal laves, og hvordan tingene gøres i den branche du arbejder med, uden at det bliver forklaret. Der vil være ting som er fuldstændig logiske for dig, men ikke logiske for programmører uden branchekendskab.

Forståelsesfejl kan minimeres ved at følge nogle simple principper:

  • Start med at vælge en leverandør som forstår sig på din branche.
  • Hvis ikke du ved hvad du vil have, så lad være med at starte projektet. Det er meget vigtigt at du ved hvad du vil have ud af projektet, før du går i gang.
  • Lad programmøren skrive kravspecifikationen baseret på det du fortæller ham eller hende. Ved at gøre det sådan vil der være "check og balance" i tingene, og det er nemt at se om opgaven er rigtigt forstået.
  • Lad være med at sige noget i retning af: "Det finder vi ud af på et senere tidspunkt" eller "det må programmøren lige lave når han eller hun kommer til det", når ikke du ved hvordan en opgave skal løses. Jeg kan garantere dig for, at programmøren ved ikke lige hvordan det skal løses, hvis ikke du selv gør!
  • Undgå at lave et kæmpe projekt. Del projektet ind i faser, f.eks. af 2 ugers varighed. Ved at dele projektet ind i faser er det for det første nemmere for en programmør at forstå hvad der skal laves, og for det andet mindsker man risikoen for at udvikle funktionaliteter som ender med ikke at blive brugt, fordi man efter hver eneste fase evaluerer hvad der skal med i den næste fase, baseret på det man har lært i den forrige fase.

Sidst, men ikke mindst, så gør alt hvad du kan, for at kommunikere klart, tydeligt og uden omsvøb. Misforståelser skal undgås for enhver pris, for det er meget dyrt at rette op på.

Author

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.