Sikkerhed er kedeligt

Test-driven development har ikke nødvendigvis noget med sikkerhed at gøre. Det er jo mere eller mindre bare en implementation af mange af de gode ting fra extreme/agile programming - hvis man koder af sted der ud af uden at have en detaljeret plan er det jo ret vigtigt at have nogen test cases så man kan se om man ødelægger noget kode et andet sted inden man checker sin kode ind...

Med hensyn til emnet, så tror jeg ikke at det bliver sådan at man som udvikler skal vide alt om sikkerhed, men snarere at samarbejdet med sikkerhedsfolkene bliver tættere. En fornuftig virksomhed vil jo nok oplyse programmørerne om det, når de laver noget slamkode så de kan lære af deres fejl...

Jeg læser ikke indlægget som om Kresten sætter lighedstegn mellem sikkerhed og test - bare at begge emner traditionelt har været lige usexede at arbejde med, men nu er test blevet hot ved hjælp af TDD. Så er spørgsmålet - hvad skal gøre sikkerhed hot? Og hvilke dele af sikkerhed skal udvikleren bekymre sig om?

Er jo så nok det rigtige spørgsmål at stille.

Mit svar på det spørgsmål er nok noget i stil med "fordi det betaler sig". Enhver programmørs drøm er vel at lave software som virker, og det er efter min mening langt nemmere med TDD, fordi du tvinger dig selv til at definere hvordan din kode skal virke før du skriver den.

Det gør man selvfølgelig også mere komplicerede processer, men der laver man ofte først et helt kompendie inden man har skrevet så meget som en enkelt linje kode, og det virker nok demotiverende på de fleste først at skrive en helt masse specifikation der bare skal smides ud igen bagefter.

Den ypperligste form af dette er nok doctest, hvor dine tests ikke bare fungerer som tests, men også som dokumentation. http://en.wikipedia.org/wiki/Doctest

Jeg tror den største motivationsfaktor for folk err at det føles produktivt at gøre det – at det giver mening i en eller anden forstand.

Kan det så overføres til sikkerhed? Næppe. Sikkerhed er ikke en metodologi, men "a state of mind". Du kan ikke gøre sikkerhed, du kan kun tænke det med i din kode.

Det er et eller andet, som programmørerne ikke forstår, når de ikke ved at tests er en interaktiv del af programmeringsprocessen.
Jeg kan ikke lave en enkeltkædet liste, uden at fejle. Hvis jeg ikke retter fejlen selv, og står inde for, at mit software fungere, så vil fejlen ofte ikke opdages. Fejlen opdages oftest ikke straks, men senere, og da er antallet af fejl enormt, og i praksis er det umuligt at teste.
Når en programmør udvikler noget, er vigtigt at de sætter en ære i, at lave noget som fungerer og fungerer pålideligt. At de bruger tid på, at lege med det de laver, for at se at det fungerer. Måske skal de bruge en dag at lege med deres komponent, eller algorithme, før de opdager den fejler. Det er langt bedre, at bruge denne dag, end at lade fejlen opdages i "slut-testen".
En slut-test skal altid vise, at tingene fungerer. Og ellers, har programmørerne ikke sat en ære i at lave tingene fejlfrit.

Genneralt er metoden følgende: Et program, hardware, eller andet består af komponenter. Disse dele sættes sammen til en ny komponent. En kompleks komponent, er svær at bevise og fejlteste, og skal helst opdeles i mindre komponemter. Disse skal helst give en mening, og må gerne kunne bruges. Hver enkelt komponent, og delkomponent skal testes. Ikke kun slut resultatet. Alle disse tests, er ikke test afdelingens ansvar, men den enkelte programmør. Det er programmøren, som tager ansvaret for sit arbejde og han/hun leverer kun noget som fungerer. Det er det vigtige, når man sætter en ære i at lave ordentligt arbejde.
Et program testes reelt to gange. Hver enkelt del testes af to personer: Udvikler og bruger. Er du programmør, og bruger en komponent, er din første opgave at teste denne. Denne test, skal vise to ting: 1. At komponenten fungerer. Og 2. At du forstår, hvordan komponenten virker. Du må ikke bruge en komponent du får, uden at først teste den, uanset den downloades på nettet og tusinder har testet den før dig. Måske er noget galt i din forståelse.
Når du endeligt har udviklet noget, skal du også teste dit eget arbejde. Du må gerne bruge tid på det, for fejlene kan være komplekse. Selvom du prøver både base case, og de andre cases, så er risiko for, at du har overset noget. Lidt legeri skader normalt ikke, og hvis du opdager noget ikke fungerer, er det vigtigt at rette fejlen, før andre får den deffekte komponent. I et økonomisk system, vil du typisk blive hængt op på dit og dat, hvis du som virksomhed leverer den videre til en anden og dit er deffekt. Så er det ikke kun din komponent der fejler, men måske også følgefejl du kan blive erklæret ansvarlig for.
I den sidste ende mangler en test, hvis alt skal testes to gange. Det er sluttesten. Det svarer til brugeren. Her må intet gå galt. Går noget galt, går det til fyresedlen til programmøren.

En programmør der ikke tester dels det som bruges, og sit eget inden det leveres, er en død programmør.
Normalt er krav om dokumentation for hver enkelt komponent og delkomponent, i form at både beskrivelse, tekniske karakteristika for komponenterne, og bevis for de er testet. Til selv en simpel komponent, er altid dokumentation om alle faktorer, der kan have betydning for brugere af komponenten. Det er typisk strømforbrug/indstruktionsforbrug, store O funktionen og dens kompleksitet, ram forbruget osv. Hvis en af disse dele ikke er nævnt, er den default uendelig, og ingen kan bruge noget med et uendeligt forbrug. Man står inde for det man beskriver i dokumentationen, og står inde for, at man har testet tingene så godt som muligt, og garanterer for hver enkelt komponents kvalitet.

Derudover skal vi være opmærksomme på, at de fleste fejl skyldes dårlige programmeringssprog. Et programmeringssprog, kan have "tendens" til fejl og mangel på stabilitet, tilfældigheder og uforudsigelighed, meddens andre ikke laver fejl. I nogle sprog, kan en programmør nemt spolere noget for andre - og i andre sprog, er det umuligt at ødelægge eller påvirke andres software.
De fleste programmeringssprog er så dårlige at brug af dem, kun viser at programmøren ikke har udført sit indledende arbejde: At teste, at de ting der "bruges" fungerer, og fungerer pålideligt, inden det tages i brug. Programmeringssprog og operativsystemer er samtidigt så grundlæggende, at man reelt ikke bør begynde at anvende dem, før alle fejl er rettet og produkterne er fejlfri. Det er bedre, at sætte alverdens udviklere og forskere ind på at udvikle et ordentligt programmeringssprog, end at begynde at udvikle applikationssoftware før dette arbejde er gjort og gjort godt. Er sproget, eller compileren gjort dårligt, øges programmeringsarbejdet for dem der anvender det måske med en faktor 10 - eller værre, og test arbejdet kan blive infinit. Sproget - og operativsystem - skal være i orden, inden man vælger at blive programmør. Ellers bør man måske læse til datalog og få det gjort i orden.