Før han ble sjef for den norske avdelingen til det tyske selskapet SQS («Software Quality Systems»), hadde Frode Johan Olsen mange års erfaring med kvalitetsrevisjon av IT-systemer, først som ansatt i Telenor, deretter som medarbeider i Validate Technology, et selskap som frontet flere verktøy for kvalitetskontroll. To år seinere ble Validate kjøpt av ærverdige SQS – de har drevet siden 1982 – og Olsen kunne jobbe videre med det han brenner for.
I forrige uke arrangerte SQS Norge «Quality Day» på Aker brygge i Oslo, med et hundretalls deltakere. Det var et fagseminar, med emner som «Smidig testing i et kanban/scrumban prosjekt». Digi.no traff Olsen i en pause i arrangementet.
– SQS teller 20 stykker i Norge, og 100 i Norden, hvor vi jobber på tvers. Vi er verdens største leverandør av testing, kvalitetskontroll og applikasjonsovervåking. Vi har kompetanse på testverktøyene til blant annet HP, IBM, Microsoft og Compuware, og vi oppfatter Sogeti som det nærmeste vi har av konkurranse. Mens Sogeti er nært knyttet til Capgemini, er vi uavhengig av alle som leverer systemer og løsninger som skal testes, kontrolleres og overvåkes.
Olsen mener uavhengigheten er svært viktig.
– Testing er en form for revisjon. Det må være objektivt. Man skal ikke ha andre interesser i prosjektet.
Kundemassen i Norge teller 25 store bedrifter, blant dem store datamiljøer som Telenor, Statoil, Statkraft, DnB Nor og BBS.
– Vi ser en økning innen det offentlige, som Vegvesenet og ulike direktorater. Helse er et vekstområde: Vi har Sykehuspartner som kunde. De har på kort tid est opp til 1500 årsverk, og er først og fremst opptatt av applikasjonsovervåking. Det ligger i kortene at de kan bli en nasjonal leverandør av IT-tjenester innen helse.
Olsen deler SQSs leveranser i tre kategorier: verktøy, metodikk og prosesser. De håndteres innen selskapets verktøyuavhengige rammeverk, kjent som PractiQ, en forkortelse for «practical quality».
– Det er et rammeverk for å levere tjenestene våre, på alle tre feltene ytelsestesting, kvalitetskontroll og applikasjonsovervåking. Til sammen tilbys 35 ulike tjenester. Rammeverket uttrykker vår samlede erfaring, og sikrer at kunder ikke er avhengig av enkeltindivider hos oss. Blir noen borte, kan andre spesialister umiddelbart overta. Alle våre konsulenter blir sertifisert i dette rammeverket.
Rammeverket bidrar til at SQS i stadig større utstrekning selger verktøy kombinert med deres konsulenttjenester. Det ligger også til grunn for leveranser etter SaaS-modellen («software as a service») for dem som ikke vil investere i egne testverktøy.
– Omsetningen vår i dag er fem prosent verktøy, fem prosent kurs, og 90 prosent «managed services».
Et av poengene med «Quality Day» var å markedsføre behovet for IT-kvalitetskontroll også overfor små og mellomstore bedrifter.
– SMB-markedet for testing, kvalitetskontroll og applikasjonsovervåking er praktisk talt urørt. Vi har satt opp løsninger som gjør det mulig å gjennomføre testing til rimelig pris. I SMB er det ofte utviklerne selv som står for testing. De har ikke fokus på ytelse, og ingen løpende overvåking.
En av spesialitetene som SQS kan tilby, er løsninger som lar IT-admin følge løpende med i hvordan brukere opplever en IT-tjeneste. Denne muligheten gjør at man slipper paradoksale situasjoner der tjenestenivåavtaler objektivt sett er oppfylt, samtidig som sluttbrukerne er misfornøyde.
– Det gjelder å øke bevisstheten om hva kvalitet faktisk innebærer. Kvalitetskontroll må legges inn i selve kravene som defineres ved starten av et prosjekt. Er kravene testbare? Der er det mye å hente. Vi kan dokumentere at det er 48 ganger dyrere å rette en feil i det man skal sette noe i produksjon, enn det hadde vært å luke den ut allerede i kravspesifikasjonen. Kravhåndtering er et nytt område for mange utviklere.
Olsen trekker fram et annet område som mange har lite føring med: endringshåndtering.
– Gjør man en endring, skal man ha kontroll over hva slags følger den vil få og hvilke tjenester den påvirker. Dette må logges ordentlig. Vår erfaring er at 80 prosent av alle feil skyldes at noen har gjort en endring.
Situasjoner der IT er fornøyd fordi alle målinger viser at ting fungerer, mens brukerne er sure fordi systemet har lange svartider, skjer gjerne ved sammensatte applikasjoner.
– I slike tilfeller danner tjenestene en egen verdikjede. Prosessen må kartlegges, slik at man vet hvordan klienten faktisk bruker de ulike tjenestene i kjeden. Har man fem funksjoner, og fire er oppe, er egentlig det hele nede. Da er verdikjeden brutt, og en kjede er, som kjent, aldri sterkere enn det svakeste leddet.
Olsens poeng er at testing må skje fra brukerens ståsted.
– Ytelsen må måles slik brukeren opplever den. Derfor må man i forkant simulere det brukeren gjør, og sette opp hensiktsmessige målepunkter på hver applikasjon i kjeden, slik at man kan avdekke hvor feilen forekommer. Måler man kun elementer, vet man ikke brukerens opplevelse. På den andre siden: Måler man bare brukerens opplevelse, vet man ikke hvor feilen er. De fleste nye IT-tjenester er komplekse integrasjoner, som må håndteres fra begge sider.
Et viktig verktøy for å gi innsyn i systemer er «Universal CMDB» («configuration management database») som kartlegger infrastrukturen og oppdager endringer. De som bruker dette verktøyet får ofte noen overraskelser.
– Det er typisk å skylde på nettverket når man opplever et ytelsesproblem. Som oftest stemmer det ikke. Feil skyldes vanligvis at man ikke har testet godt nok konsekvensen av en endring. Man har lagt inn en ny applikasjon, oppdatert en annen, endret en rutingtabell og så videre. Eller man opplever minnelekkasje i en CRM-applikasjon man ikke har testet godt nok før man sendte den i produksjon.
Her trengs begge hester: Testing for å avverge feil før man setter noe i produksjon, og applikasjonsovervåking for å avdekke feil man ikke fanget opp under testing.
Smidig utvikling – «agile development» – stiller spesielle krav til testing og kvalitetskontroll.
– Smidig metode brukes i stadig større utstrekning fordi det blir så mye kjappere å få ting ut til markedet. Faren i forhold til testing, er at man tester i forhold til gamle krav, ikke dem som gjelder i den aktuelle iterasjonen.
Olsen avslutter med følgende budskap:
– Kvalitet må tenkes gjennom hele verdikjeden, helt fra man begynner å snakke om hva man skal lage. Vi ønsker at testere, utviklere og driftere skal lære av hverandre. Målet er enkelt: Levere tjenester med riktig ytelse og funksjonalitet.
