Dette er en test

KRONIKK: Alt for ofte har man testet på genererte data, skriver Ahlert Hysing.

Publisert Sist oppdatert

Air Shuttle Luton kom det på fakturaen fra Master Card. Ikke kjørt Air Shuttle. Aldri vært i Luton. Air Shuttle medførte nitidig etterforskning sammen med kortutstederen for å finne ut av hva det betydde.

For det er komplett uforståelig at Air Shuttle betyr kjøp av mat om bord på Norwegian.

Kundene burde nekte å betale fordi Air Shuttle Luton heller ikke er registrert på den dagen kjøpet på Norwegians fly ble foretatt. Kjøpet er registrert den dagen dataene fra betalingsterminalen er lastet inn i et it-system som sendte dataene videre.

Påkostning ved innlevering av leasingbil skriver Møller Bil i en uventet faktura. Alle må forstå at det betyr ødelagt aluminiumsfelg på en innbyttebil.

For hverdagseksemplene er mange på dårlig kvalitet. Det virker ikke som utviklingsansvarlige forstår hva testing betyr. Pc-valget i 1993. Det endte i en katastrofe på grunn av for dårlig testing. Altinn gjennom flere år. Systemene svikter fordi de ikke har blitt testet grundig nok.

Innen it forbindes testing først og fremst med måling. Det er kvaliteten som skal sikres. Men siden viktig programvare hele tiden må oppgraderes, er det lett å undre seg over hva som menes med testing. Er det kontinuerlig utprøving og feiling som medfører behovet for oppgradering?

For alle it-systemer inneholder feil. Det er nærmest umulig å lage programvare som er lytefri. Det oppstår alltid en problemstilling som ingen har tenkt på, som medfører feil, til dels betydelige feil.

Kurs om hvordan sikre feilfri kode vil alltid være teoretiske. Men opplæring i hvordan oppnå mest mulig feilfri kode er spennende. Det handler om å lære seg å finne svakheter.

For vi har en tendens til å se og tenke for snevert. Mindre enn ti prosent av feilene i en it-tjeneste skyldes programvarens kode. Og det er koden vi først og fremst måler ved å teste.

For mange oppfattes test som utprøving, ytelsesmåling, opplæring og feilfinning. Utfordringen er hvor man skal søke etter feil. Alt for mange overlates til utprøvingen.

Det kan være en bra strategi så fremt alle er inneforstått med at testingen er for å prøve ut bruksmåte, prøve ut muligheter, avdekke svakheter. Da gjelder det å komme med raske tilbakemeldinger, med raske forbedringer som kan prøves ut på nytt.

Produksjonssetting flere ganger i uken med virkelige data vil kunne oppleves som både spennende og frustrerende. Da gjelder det å ta raskt tak i frustrasjonene. Forutsetningen er at utviklingen kan skje med virkelige data.

Utforming av it-tjenester har ofte glemt å ta hensyn til driftssituasjonen. Realiseringen av en tjeneste blir mye bedre ved å foreta nøye planlegging med driftsfagfolkene. Det kan avdekke behov for oppgradering av den tekniske utrustningen. Det kan bidra til en smidigere driftssituasjon.

Som forbrukere forbinder vi test med utprøving. Vi skal lære, vi skal bli overbevist, vi skal bruke testingen som grunnlag for valg. I forbindelse med it må vi også lære. De fleste feilene oppstår ikke under koding. De oppstår i planleggingsfasen.

Ifølge National Institute of Standards skjer 70 prosent av feilene i planlegging og designfasen, 20 prosent i realiseringsfasen og ti prosent under integrasjon og akseptanse.

I hvilken grad tallene er gyldige for smidige prosjekter er usikkert, men tallene understreker nødvendigheten av å etterprøve planleggingen. Derfor er all modellering og kvalitetssikring av de innledende fasene vesentlig for å redusere feil.

For testing av it har konsentrert seg om realiseringsfasen; kodingen, modultesting, applikasjonstesting, integreringstesting, systemtest og akseptansetest.

Alt for ofte har man testet på genererte data. Sjelden har noen testet to systemer i parallell, det gamle og det nye for å se at resultatene er identiske. Alt for ofte har brukerne kommet for sent inn i testarbeidet.

Brukerne skal helst gjøre uventede arbeidsoppgaver for å se hvordan tjenesten reagerer. Derfor er testdrevet utvikling vesentlig for å oppnå bedre kvalitet.

Derfor må ikke bare ansvarlige sitte sammen med utviklerne i et smidig prosjekt. Det må også brukere.

App-er på smarttelefoner er en ny utfordring, ikke bare må de være robuste. De må sikres. Penetrasjonstest blir nødvendig.