»Det er jo ikke testen af software, der tager tid - det er at rette fejlene«

Jeg er også ret stor fan af gode tests.
Det der overbeviste mig var at næsten hver gang jeg skriver en test finder jeg en fejl. Specielt når man kombinerer det med et code-coverage tool, så man kan se, hvad man har glemt at teste.

Jeg kan ikke leve med, at vide at jeg ikke har checket for fejl i det jeg laver.

Denne uge har jeg lige lavet en ret stor refactoring, der berørte ca 10% af alle kodelinjer i hele vores kodebase. Det ville have været en umulig opgave, hvis vi ikke havde haft mange gode test til at fange fejl indtroduceret.

Men når jeg hører om værktøjer til test og kvalitetssikring fra IBM, Microsoft og HP, løber det koldt ned af ryggen på mig. Keep it simple, det behøver ikke være så avanceret. Lad være med at tro at værktøjer er løsningen, det er mere et spørgsmål om kultur, gode vaner, kode review osv. Vent med at indføre et værktøj, til der er en pain i processen, der skriger på et værktøj - ikke den anden vej rundt.

Ethvert program kan debugges for fejl og enhver kode kan refaktureres til at blive mindre.

Derfor kan ethvert program reduceres til én linje som ikke virker.

• Anonym

Every program has at least one bug and can be shortened by at least one instruction — from which, by induction, it is evident that every program can be reduced to one instruction that does not work.

• Ken Arnold (http://en.wikipedia.org/wiki/Ken_Arnold)

Det er lidt af en tilsnigelse, at test ikke tager tid.

Ordentlig test tager tid. Meget tid.

At det så sparer mere tid, end det tager, er en anden sag. Men verden har ikke brug for flere chefer, der tror, at test bare er noget, man lige kan klaske på til sidt i løbet af et par timer.

Hmm, så er man måske nået til et punkt, hvor man bruger en masse tid på brandslukning og har en deadline truende nær.

Jeg vil hellere anbefale, at man kigger på sådanne værktøjer løbende og implementerer dem så snart man har tid.

Det kan også give ny inspiration til kvalitetsmetrikker, man ikke selv havde tænkt på at måle på.

Og hold dig løbende orienteret om, hvordan andre sikrer deres kvalitet. Hvis det gælder JavaScript, har Allan tidligere lavet en liste over gode værktøjer:
http://www.version2.dk/blog/kodekvalitet-i-javascript-47057

Det er vigtigt, at overveje hvordan programmet skal kunne testes på en overskuelig og nem måde fra start, allerede når programmet designes. Nogle programmer er designet, så de er stort set non-testable.

Det er svært, at komme med en fast opskrift på, hvorledes det gøres. Men, det er altid vigtigt, at holde tingene simpelt. At opdele det, i testbare moduler. At søge at opnå determinisme i programmet - både designmæssigt, og ved at anvende metoder, der sikrer determinisme. F.eks. metoder, der sikrer imod ikke initialiserede variable og pointere. Typechecks osv. Specielt ved parallel programmering, ses ofte, at dårlige metoder, medfører resultatet kan afhænge af processernes udførselsrækkefølge, og dermed i nogle tilfælde fungerer, og i andre ikke. Selvom der findes "tools" der kan hjælpe i forbindelse med test, når der anvendes grafiske brugergrænseflader, så foretrækker jeg ofte selv, at der er en tekstbaseret brugergrænseflade under. Den kan også anvendes som basis, f.eks. for scripts.

Det er ikke muligt, at "teste" et produkt til at fungere, hvis det ikke er designet korrekt. Processen startes allerede i design fasen, og det er vigtigt, at allerede her, indrage problemstillinger som, hvordan vi skal sikre, at koden kommer til at fungere. Selvom et design, måske ikke er det mest simple, kan det vise sig, at det er nemmest at komme igennem. F.eks. fordi, at det er opdelt, i mindre enheder, der hver især er forsynet med en brugervenlig grænseflade, der gør at det kan forholdsvis testes og bruges individuelt.

Det kan også være væsentligt, med en strategi, så det ikke kun er programmørerne der er "overbevist" om at koden fungerer, og er villige til at skrive under på det. Lederen - selv direktøren - skal også gerne selv kunne anvende og bruge programmet fuldt ud, uden at kunne se fejl i programmet.

Det er ikke ualmindeligt, at softwarefejl starter som designfejl i designfasen, hvor der ikke er tage tilstrækkeligt hensyn til f.eks. muligheden for testing, og at systemet skal være stabilt. F.eks. kan anvendelsen af en protokol, som besluttes i designfasen, medføre instabilitet, og samme med ikke grundigt testede og godkendte metoder, operativsystemer, og platforme. Skal et design virke, er ofte nødvendigt, med grundige forundersøgelser, og forskning for at undersøge og eventuelt løse problemer, inden at design og udviklingen påbegyndes.

Jeg tror, at mange softwareprojekter starter for tidligt. Der laves ikke forundersøgelser nok. Ofte, skal en stor del af arbejdet - i nogle tilfælde også programmørarbejdet - placeres før, at design og udviklingsarbejdet begyndes. Fordi, at løse ender, skal løses, inden beslutninger der bygger på disse tages. Første trin er forskning. Og design, samt udvikling, skal tage udgangspunkt i forskningen.

Som et eksempel på manglende forskning, har jeg set protokoller, der stort set bare "besluttes". Dette medfører måske, at tingene skal opstartes i bestemt rækkefølge, at der skal holdes uspecificerede pauser, inden næste del opstartes, at systemet ikke er robust overfor en afbrydelse, eller genstart af et produkt, at der ikke er taget højde for strømforbrug, støj, eller interferrens osv. Og i nogle tilfælde, fatter dem der beslutter, end ikke hvad der tales om, hvis nogle "teknikkere" gør opmærksom på et problem. Beslutninger skal ikke tages. De skal vides.

Med fare for at jeg fuldstændig har misforstået hvad du skriver, så lyder det somom du advokerer for vandfaldsmodellen. Og den er langt fra optimal altid - men det afhænger jo af hvad man bygger.

Mange ting kan man ikke vide, de skal afprøves (måske endda i produktion):-)

Men du har ret i at et dårligt designet system, stadig er dårligt designet, selv om det har test. Jeg vil dog stadig hellere have et dårligt designet system med test, end et dårligt designet system uden tests, det giver blandt andet bedre mulighed for at refaktorere.

Mange ting kan man ikke vide, de skal afprøves (måske endda i produktion):-)

Netop derfor, skriver jeg at forskning, skal lægge før beslutning. I nogle tilfælde, kan designet også levne mulighed for beslutning senere, således der tages højde for den manglende viden. Det kan ske, ved at gøre produktet fleksibelt, konfigurerbar, eller programmerbart.

Men du har ret i at et dårligt designet system, stadig er dårligt designet, selv om det har test. Jeg vil dog stadig hellere have et dårligt designet system med test, end et dårligt designet system uden tests, det giver blandt andet bedre mulighed for at refaktorere.

Hvis et system, er designet dårligt nok, er det stort set umuligt at teste. Testing, er noget der skal indarbejdes, allerede i design fasen. Alt, bliver mere kompliceret, hvis du ikke overvejer, hvordan projektet skal laves, på en måde, så det kan gennemføres. Jeg har selv arbejdet med test, og fået opgaver, hvor der skulle testes ting, som umuligt kunne testes, fordi det ikke var lavet testbart fra design side. Så kan man jo kun fejlmelde det hele.