Ny blog: Alle it-systemer indeholder fejl

Softwaretester Anne Mette Hass sætter i ny blog fokus på, hvordan man minutiøst forbedrer it-systemer.

Det er ikke et spørgsmål om der findes fejl, men hvornår de findes i ethvert softwaresystem. Hvilke problemer, de giver, er helt afhængige af, om der har været foretaget ordentlig softwaretest.

Det er udgangspunktet for Anne Mette Hass' nye blog på Version2, hvor hun går i dybden med alle aspekter af test indenfor software. Hun er teknologichef og konsulent inden for test og krav hos Devoteam og har mere end 30 års erfaring inden for it-branchen.

I sit første indlæg stiller Anne Mette Hass skarpt på, hvad definitionen på test egentlig er med udgangspunkt i den kommende ISO 29119 Standard for Software Testing, der formentlig kommer til at være formuleret som de aktiviteter, der skal til for at sammenligne, hvad man har fået med det, de fremtidige brugere forventer.

»1) test er mere end bare afvikling af testcases (det kan vi tale om ved en senere lejlighed); og 2) uden beskrivelse af, hvad "de fremtidige brugere" forventer, kan vi ikke teste!,« skriver Anne Mette Hass.

Definitionen på, hvad der skal testes, er vigtig, for ellers risikerer man simpelthen at tale forbi hinanden i processen, og her skal man virkelig sørge for at afstemme forventningerne.

»Der er stadig mange, der arbejder ud fra den ide, at testerne på en eller anden måde kan tilføje kvalitet. Det kan vi ikke! Vi kan i princippet kun udtale os om, i hvilken grad forventningerne er opfyldt,« mener hun.

Anne Mette Hass er uddannet civilingeniør og fik mere og mere it-erfaring, efterhånden som hendes jobs krævede det.

»Jeg var akademiker med ét kursus i databehandling. Det der med it lærte jeg hen af vejen. Kodning kom først, dernæst fornemmelsen for krav. Der gik næsten seks år, inden jeg rigtig hørte om test for første gang. Jeg havde lagt en rettelse ud i drift, og min chef ringede hjem fra et kundebesøg og spurgte, om jeg havde testet rettelsen, inden jeg lagde den ud. Testet? Det var der ingen, der havde spurgt om før. Meget pinligt,« siger Anne Mette Hass

Siden har hun ikke set sig tilbage, og har i dag en solid erfaring med test af alverdens softwaresystemer.

Gå til Anne Mettes blog

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

"Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence."

-- Edsger Dijkstra. ACM Turing Lecture 1972.

Det er en regel, enhver tester bør have i baghovedet. Den eneste sikre måde at påvise fejlfrihed er ret kompliceret og ressourcekrævende:

  1. Hav en komplet formel specifikation af, hvad programmet skal gøre.
  2. Lav et computerverificeret bevis for, at programmet opfylder specifikationen.

Det sværeste i den forbindelse er ikke at lave beviset, men at lave en formel specifikation, der stemmer overens med forventningerne -- det nytter ikke meget at bevise korrekthed overfor en specifikation, der ikke specificerer den ønskede opførsel.

Som Knuth en gang skrev: Beware of bugs in the above code; I have only proved it correct, not tried it."

  • 3
  • 0
Thomas Petersen

En måde at komme dette til livs på er gennem continued deployment. Men det kræver naturligvis en kulturændring i det offentliges måde at tilgå it projekter på. En ændring vi nok ikke vil se før næste generation of udviklere besætter de offentlige poster.

Og sådanne må det måske også bare være.

  • 0
  • 0
Peter Tilsted

Hvordan mener du at "continous deployment" kan påvise manglen af fejl ?

Jeg er med på at succesrig "continous deployment" strategi i et projekt, kan mindske antallet af fejl betydeligt, men påvise at der ikke er fejl er jeg lidt usikker på hvordan det skulle sikre

  • 0
  • 0
Thomas Petersen

Den kan ikke påvise manglen af fejl

Den viser fejlene efterhånden som de opstår fordi man jo løbende deployer. Derved opnår man en mere inkremental udvikling hvor man løbende kan monitorere fejl som de opstår. Faktiske fejl, ikke kun de fejl som man kan tænke sig til der skal testes for.

  • 0
  • 0
Log ind eller Opret konto for at kommentere