I august overtok veteranen Per-Otto Lie – kjent blant annet som medgründer i Cinet og fra lederstillinger i Microsoft, Compaq og Webcenter Unique – jobben som administrerende direktør i Mercury Norge. Det raskt voksende selskapet for testing og tuning av infrastruktur og applikasjoner har langt på vei erobret landets tunge IT-miljøer siden norgesetableringen i 2000. Nå er testverktøyene kommet på et nivå der det er mulig – og nødvendig – for forretningsfolkene selv å teste sine kritiske applikasjoner, mener Lie.
Les også:
- [19.09.2005] Mercury satser på trådløs testing
- [03.11.2004] IT-bransjen deles opp i klare kongeriker
- [24.08.2004] Verktøy for kvalitetssikring i sterk vekst
- [19.08.2004] Mercury får ny norgessjef
- [30.03.2004] Mercury-pakke forebygger applikasjonsproblemer
- [17.02.2004] Oppgradert Mercury-verktøy for å styre IT-prosjekter
– Vi har hatt en solid og bra vekst i Norge, men også her er det de store kundene som dominerer kundekretsen får, sier Lie til digi.no. – Globalt sett har vi en markedsandel på 55 prosent i vårt marked. De nærmeste konkurrentene har henholdsvis 20 prosent og 9 prosent.
Mercurys aktuelle årlige vekstrate er 20 prosent. Lie mener markedet er underpenetrert.
– Vi har sett på forskjellige studier. Ifølge Yankee Group er 90 prosent av kritisk viktige forretningsprosesser automatisert gjennom applikasjoner. På den andre siden peker Gartner på at 80 prosent av applikasjonene er enten ikke testet eller kun manuelt testet før de settes i produksjon. Følgen er mye kostbar nedtid.
Lie mener flyselskapet Norwegian kom i en typisk situasjon.
– De kjørte en fantastisk markedskampanje, og kundene strømmet til. Systemet tålte ikke belastningen. Hva tapte de på det? I dag opplever Norwegian problemer. Det dårlige førsteinntrykket kundene fikk er medvirkende til det. Det er et stort sprik mellom de millionene man bruker på markedsføring og de hundretusenene man tror man sparer på ikke å teste IT-systemene grundig.
I høst satser Mercury på et konsept det kaller «Business Process Testing» som innfører et nytt prinsipp for å teste applikasjoner: Det er ikke lenger bare teknikken som skal testes, men selve det forretningsmessige.
– Det vi gjør er å legge et overbygg over det tekniske testmiljøet. Det skal gjøre det mulig for ikke teknisk-kyndige å teste ut hvordan applikasjonen står seg, forretningsmessig, forklarer systemingeniør Espen Thilesen.
Denne omdefineringen av hvem som skal teste det man satser forretningen på, kan delvis føres tilbake til krav fra kundene.
– Vi har lenge hørt at terskelen for å automatisere testingen er for stor. Det hele blir for teknisk preget, og det er for lite gjenbruk av ressursene som legges ned i testingen.
«Business Process Testing» skiller seg fra vanlig skripttesting på flere viktige punkter, ifølge Thilesen: Testingen deles i små komponenter som gjør det mulig å teste én ting om gangen. Mercury samarbeider med leverandører som Oracle, PeopleSoft, SAP og Siebel for å utvikle tilpassede testkomponenter. Disse komponentene settes sammen av de som står bak forretningsprosessene, gjennom enkle «drag and drop» operasjoner.
Fordelene er dels at det er forretningsutviklerne og ikke IT-ekspertene som står for testingen, dels at tid og kostnader til testing reduseres drastisk.
Thilesen demonstrerer Mercurys webbaserte testverktøy Quality Center Tester. Applikasjonen som skal testes, er fordelt på forretningsobjekter – «business components» – som svarer til typiske brukerhandlinger: legg inn ordre, få en rapport, logge seg på og så videre.
– Mangler det en komponent kan forretningsanalytikeren starte å bygge den, ved å beskrive hva den skal gjøre, hva den er avhengig av, hvilke skjermbilder den skal omfatte, hvilke avhengigheter den selv skal ha når den er ferdig, hva slags inn- og utdata den skal bruke, med mer.
Gjennom parallellverktøyet Quick Test Professional går denne komponenten til den tekniske personen som skal realisere selve skriptet. Dette verktøyet har et tilpasset grensesnitt, med blant annet innebygget regneark og et lager av alle skjermbilder man arbeider mot. Det åpner applikasjonen som skal testes, gjør opptak av brukersituasjonen og genererer dokumentasjon. Siste trinn er tilpasning av inndata til automatiserte sekvenser som hentes inn i stedet for at noen skal sitte ved et tastatur.
Løsningen ivaretar all varsling mellom roller. Når skriptet er ferdig, er komponenten klar til bruk for forretningsanalytikeren gjennom Quality Center, der det settes opp en testplan. En typisk test vil samle flere komponenter, gjerne fra flere applikasjoner, i tråd med hvordan brukere kan forventes å oppføre seg. Testene skal sjekke hele verdikjeden i en forretningsprosess.
– Man kan for eksempel brenne en test til en CD, og la testen kjøre om natten. Skjermbildene vil blafre forbi for å vise hva som skjer. Om morgenen kan man forholde seg til resultatet: «passed» eller «failed». Har noe sviktet vil rapporten fortelle nøyaktig hva som skjedde og hvor.
Denne løsningen effektiviserer den funksjonelle testingen av en applikasjon. Mercury minner om at det også er nødvendig å kjøre en belastningstesting av applikasjonen, for å få et fullverdig inntrykk av hvordan det hele fungerer fra brukersiden.
– Det vi ser i belastningstester er at det gjøres begrenset for å spare tid. Det er gjerne den siste uken før applikasjonen skal settes i produksjon, som brukes til ytelsestesting. Da kopler man av ting og reduserer antallet man tester for, eller kanskje bare tester i eget testmiljø og ikke i et produksjonsmiljø.
Thilesen mener to ting gjør at denne formen for belastningstesting feiler.
– Ofte er ikke testmiljøet tilstrekkelig likt produksjonsmiljøet. En annen feil er at scenariene i testmiljøet ikke er realistiske. Mange tester med for få samtidige brukere, og så opplever de at det smeller med bare 15 prosent flere enn i testen. Du må teste for opptil 2,5 ganger forventet belastning. Ofte er det svært enkle ting i infrastrukturen som gjør at det plutselig sier stopp.
Man må passe på synsvinkelen, mener Thilesen.
– Alle har intens overvåkning av de interne systemene. Likevel er det problemer i 80 prosent av tilfellene. Man ser det hele fra IT-siden, ikke fra brukersiden. IT opplever at alle indikatorer lyser grønt. Men brukeren opplever responstid på 20 sekunder. Det nytter ikke å løse dette ved å hive inn mer maskinvare. Men med Mercury-verktøy lar det seg vanligvis fort gjøre å redusere responstiden til 2 sekunder, uten å hive på med verken minne eller server. Stort sett går det på å justere tallet på tråder i programvaren.
Testingen skal avsløre slikt før applikasjonen settes i produksjon.
– Vi har svaret på mange av problemene som oppstår. Vi ønsker å komme inn i forkant, understreker Thilesen.
