Krevende å teste mobilitet

Anders Malmberg er system- og testspesialist i Rational Software, som er en del av IBM Software Group. Vi spurte om trender.

- Mobilitet er en av dagens hovedtrender innen it. Det kommer stadig flere app-er, folk vil ha tilgang overalt med sine mobile apparater, mange selskaper tilpasser seg også såkalt Bring Your Own Device (BYOD), og så videre. Det gjør at sikkerhet blir en egen seksjon innen testing. Og på en annen måte enn vi kan være vant til fra noen år tilbake, mener Malmberg.

- Tidligere kunne det gå et halvt år eller kanskje ett år eller mer mellom hver nye versjon av programvare. I dag er hyppigheten av oppdatering av versjoner ofte daglig. Det er mer utfordrende å teste på grunn av mange operativsystemer og plattformer og de hyppige endringene.

- Ser du på generasjonen som er født etter 1992 og senere, så bruker de verktøyene på en annen måte enn generasjonene før. De forventer at all ny teknologi og programvare fungerer og at applikasjoner blir oppdatert nesten daglig.

- Alt dette stiller nye krav til testing. Den må være mer smidig, og vi ser en trend tilbake til mer automatisering av tester. Da ikke bare automatiske tester av applikasjonenes grensesnitt, men også integrasjonstesting – at endringer fungerer i forhold til andre deler av sammensatte løsninger, ytelsestesting og ikke minst testing av sikkerhet.

Mer automatisering

Malmberg sier at det flere som ønsker å automatisere hele løpet fra bygg til utrulling inkludert alle tester. Det er noe det kommer stadig flere forespørsler om, selv om det fortsatt vil være en god del manuelle tester.

Han peker på at dagens systemer er veldig komplekse og krever omfattende testing.

- Men mye av testingen kan vel gjøres ved å teste koden?

- Verktøy for å skanne kode for sikkerhetshull er ikke så vanlige, heller ikke verktøy som tester sikkerhet mot app-enes eller programmenes brukergrensesnitt.

- Vi tror det er nødvendig å endre synet mange har på testing. At det ikke blir fokusert på testfasen, men at det tenkes kvalitet og gjøres kvalitetssikring. Det må tenkes QA, kvalitetssikring, fra dag én.

Malmberg synes det er fint om testere begynner å jobbe fra første dag i et utviklingsprosjekt, men at det er mer som må håndteres og planlegges: Er kravene til den løsningen som skal utvikles testbare? Blir kravene forslått likt av utviklere, testere og forretningssiden? Her er det mange problemstillinger som bør tenkes igjennom og avgjøres. For jo tidligere en feil blir funnet, jo billigere er det å løse den.

Også et kulturspørsmål

- Det må også tas hensyn til kultur og politikk i organisasjonen. Det er mange prosjekter hvor problemer og utfordringer ikke rapporteres tidlig, men at det er «smørsiden» som blir rapportert først. At det blir lagt vekt på å sette i gang med det enkleste først, mens utfordringene blir liggende.

- Dette kan for eksempel skyldes at bestiller blir lovet noen resultater på kort tid. Jeg mener det bør være mer bevissthet på å finne svakheter tidlig i prosjekter. It-bransjen er kanskje den eneste bransjen som har fått holde på som vi har gjort. Hverken biler eller fly blir planlagt, utviklet og produsert uten omfattende kvalitetssikring og testing.

- Men det betyr ikke at det alltid er fornuftig å jobbe ut fra for tette spesifikasjoner. Agile, eller smidig, har modnet og blitt en måte å utvikle på som er anerkjent. Men også her er utgangspunktet krav som er satt ved start.

Han legger vekt på at standarder må være med, og bakes inn tidlig i planleggingen. Hvis du skal utvikle en løsning for bank, for eksempel, må du bygge på bransjestandarder for betlingsformidling og så videre.

Velger kravhåndtering

- Om jeg skulle velge meg bare ett verktøy for å bruke i kvalitetssikring av et prosjekt, ville det være et system for kravhåndtering, såkalt Requirement Management. Gjerne i kombinasjon med et test management system, for å vise sporbarhet fra krav til test og verifisering. I komplekse løsninger, og det er jo svært mange av dem i dag, er dette et viktig verktøy. Du bruker kanskje noe mer tid og ressurser tidlig, men spares inn igjen senere. Alt i utviklingsprosjektet kan spores og du får veldig god kontroll.

- Både testmiljøer og testdata blir mer og mer komplekse. Ikke bare på grunn av at flere systemer og tjenester skal fungere sammen, men du har også flere versjoner internt. Det er en eller flere versjoner i utvikling, andre versjoner i test og en eller flere versjoner i produksjon. Det kan være kundespesifikke tilpassede versjoner eller forskjellige versjon for ulike terminaler, altså mobiler, nettbrett, pc-er og annet.

- Det finnes et rikt utvalg av forskjellig smarte mobiltelefoner, men de kan vel emuleres i programvare og testes uten å anskaffe alle variantene?

- Mye kan gjøres i en emulator, men der får du ikke testet hvordan løsningen funger på en mobil i bruk som skifter mellom nettverk og skal kunne brukes på bussen og t-banen, i butikken og andre scenarioer.

Med alt på nett

- Så har du "Internet of Everything", hvor det er mange maskiner som snakker med hverandre. Nyere biler står for en masse M2M-kommunikasjon, for eksempel. Hvordan tester vi slike systemer? Det er ikke løst og blir en utfordring fremover. Som hvordan du skal teste at en gjenstand bare kommuniserer med det systemet den skal. Det ville være kjedelig om hvem som helst kan ta kontroll over bilen din.

- Det er også utfordringer når det gjelder testdata. De må være realistiske, kanskje reelle data fra for eksempel et pasientregister. Samtidig må de maskeres slik at de ikke kommer ut til noen som ikke skal se dem.

- Mange tenker på testing av brukergrensesnitt som testing, men det er jo en masse i mellom og bak i systemene som skal på plass før det når brukeren. Vi ønsker å få flere målepunkter på at vi lykkes med en test. Det vil være fordelaktig når det gjelder tidsbruk, og bidra til at feil oppdages tidligere. Som sagt: Jo senere feil blir oppdaget, jo dyrere er det å fikse den. Igjen: Det er viktig å gå fra testing til kvalitetssikring, avslutter Malmberg.