Det er forkert, at man kan teste sig til sikkerhed. Det designer man sig til, ved at holde ting simple og overskuelige. "Simpelt" og "Overskueligt" er sjældent ord, jeg ser brugt om Windows.
Det er korrekt. Mange tror, at man kan lave en stor applikation på mange millioner af linier, og så sætte en test-ingeniør, til at bruge brugergrænsefladen nogle timer - hvorefter den er "testet"!
Test, er ikke direkte et "bevis" for fungerende software. Og selvom det oftes påstås at software er testet i "hoved og røv", så er det normalt ikke korrekt. En analyse, af de linier som reelt er udført ved testen, viser det ofte kun er under 40% af den samlede kode! Og alligevel "påstår" man, at det er testet i "hoved og røv". Sandheden er måske, at der er brugt masser af tid på test - men at det overhovedet ikke er testet. Selv hvis 98% af linierne har været udført i testen, ses ofte at det er de sidste 2%, som der er fejl i! Og endeligt, er det at se på om linier har været udførte, jo langtfra nok. Men, er det ikke gjort, kan vi da ikke kalde det nogen test. Vi må som minimum sikre os, at 100% af alle linier har været udført.
Når vi får et produkt til test, så skal det helst være fejlfrit. Er der bare éen fejl - så er denne kun toppen af et isbjerg, og vi må forvente der er en million. Derfor, skal software være 100% fejlfrit når det leveres til test.
Måden, at opnå dette, er at også teste enhver lille del af softwaren grundigt, og at ikke have store programblokke. Et stort program, består af mindre blokke - og de små blokke, må for ingens vedkommende være store, eller blive store. I stedet, må vælges flere blokke, og et bedre hirakisk design, hvor flere blokke, der måske har en samlet funktion, anvender måske 10 blokke under sig. Alle blokke testes så - både underblokke og dem under dem osv, og de blokke som bruger dem. Og, de testes ikke kun éen gang - men mindst to: Først, testes enhver blok af udvikleren, og han står inde for at han har testet den, og er i sin fulde overbevisning om at den fungerer. Inden, at han går i gang med at udvikle den, så tester han alle de blokke den består af, så han kan stå inde for, at han har forstået hvordan de fungerer, og formår at bruge dem. Er der fejl i, er det hans opgave at opdage, og rapportere disse, og ikke "kun" begynde at bruge dem hovedløs, og med viden om, at det ikke fungerer. I langt de fleste tilfælde, hvor der er fejl i software, ved programmørerne det faktisk godt - for de ved, at de blokke de har brugt er deffekte. Og så burde de måske i stedet have anvendt resoucer på, at få det grundlæggende til at fungere, fremfor at bygge på. Er der fejl i byggeblokkene, skal de helst rettes først - og de skal under alle omstændigheder rettes, inden programmøren der udvikler en blok med disse i, kan "underskrive" at nu virker den nye blok.
Altid gælder, at enhver blok skal være testet - og at programmøren skal dokumentere dette, f.eks. i form af testvektorer. De skal kunne køres af andre, så testen kan reproduceres. Derfor, er nødvendigt, at tests kan udføres ved hjælp af testvektorer, og testprogrammer - en test med en mus og en brugergrænseflade kan umiddelbart ikke bruges. Brugergrænsefladen kommer først til sidst, og for så lidt af programmeringen som muligt - helst med et færdigt værktøj til at udvikle det, som man ved fungerer - da det er besværligt at opskrive testvektorer, og testprogrammer for brugergrænseflader med mindre det er kommandolinie orienteret. Som regel, vil et program derfor indeholde en "indre" kommandolinieorienteret brugergrænseflade, af hensyn til f.eks. reproducerbare tests og beviser. At validere, om udseendet skifter på en brugergrænseflade, er altid svært, og det er nødvendigt, hvis man skal sige den testes - så en "optagelse" af mus og tast kombinationer, er ikke nok for at kunne sige den testes. Skal en grafisk brugergrænseflade reelt testes, skal man have software der "kan se", om den gør som den skal. Derfor, holdes den så simpel som muligt, og bygges ovenpå noget kommando orienteret.
Ialt, skal enhver blok være testet mindst to gange - den grundige test, af selve programmøren, som "ved" hvad der bør testes, og som herefter underskriver at han har testet den, og er ved sin fulde overbevisning om at den fungerer og er uden fejl, og vedlægger de test vektorer som er benyttet, samt dokumentation for, at 100% af alle linier er blevet udført ved testen, samt branches og switches i alle deres retninger. Er der noget, som af gode grunde ikke er testet, skal softwaren skrives så denne del holdes på et absolut minimum, og det skal dokumenteres, og begrundes hvorfor den pågældende del ikke er testet, og ikke kan testes. I de fleste tilfælde, skal man anvende programmeringssystemer, så der ikke opstår dele, der ikke testes.
I den sidste ende, har vi en masse kode, der er testet mindst to gange - er det brugt flere gange, er det også testet flere gange. Og når vi kommer til vores "slut" software, så tester programmøren som udvikler det, og sikrer sig at det fungerer. Han underskriver at han er fuldt overbevist om det fungerer korrekt og er uden fejl, og han vedlægger dokumentation i form af test, samt bevis for at hele koden har været udført, osv. Den sidste del, er kun testet éen gang - nemligt af programmøren. Og derfor, sendes den videre til test-afdelingen, som står for slut testen. Her testes softwaren, så vidt muligt i sine rette omgivelser, og på den måde som brugeren ser det. Når vi kommer til dette stadium, har alle dele været testet før, og programmørerne har været overbeviste om deres funktion. Derfor, bør produktet i det store hele være fejlfrit.
I nogle tilfælde, har man ikke omgivelserne tilrådighed under udviklingen, og så skal man i princippet udvikle modeller for disse, så det kan testes.
Nu begynder vi at sige, at det er testet i hoved og røv. Ikke før.
De fleste, som "praler" af deres software er testet i hoved og røv, har testet det et par timer med musen, og fundet et par fejl, som de tænker nok ikke er deres, men del af java. Og så er deres produkt jo fejlfri... Sandheden er, at det overhovedet ikke er testet. Det er kun afprøvet.
Gøres testene efter alle kunstens regler, så betyder de faktisk noget for produktets korrekthed og stabilitet.
Men - stadigt - er de ikke et "bevis".
