Mange tenker at testing handler om én ting: å finne feil. Men god testing handler først og fremst om å skape trygghet. Trygghet for at systemet fungerer som det skal, og trygghet for at det faktisk kan brukes i virkeligheten – av mennesker, under press, med høy belastning, og gjerne på tvers av systemer.
For å komme dit, må vi skille mellom to sider av testarbeidet: funksjonell testing og ikke-funksjonell testing. Det er et skille som kanskje kan virke teknisk, men som har stor praktisk betydning – særlig for deg som bestiller eller eier et prosjekt.
To sider av samme sak
Funksjonell testing: Gjøres det riktige?
Dette er den delen av testarbeidet som de fleste kjenner igjen. Her sjekker vi at systemet faktisk gjør det vi har beskrevet i kravene. Det handler om funksjoner – alt fra at en bruker kan logge inn, til at en faktura blir generert og sendt til riktig mottaker.
Kort fortalt: Virker funksjonene som de skal?
Typiske eksempler:
- Fungerer innloggingen?
- Kommer kvitteringen opp etter betaling?
- Regnes rabatten riktig i handlekurven?
Dette er «det synlige laget» av test. Det er konkret, målbart og som regel godt dokumentert.
Ikke-funksjonell testing: Gjøres det riktig?
Mens funksjonell testing ser på hva systemet gjør, handler ikke-funksjonell testing om hvordan det gjøres. Det er her vi vurderer egenskaper som:
- Ytelse (går det raskt nok?)
- Stabilitet (kan det kjøres over tid uten problemer?)
- Brukervennlighet (gir det mening for dem som skal bruke det?)
- Sikkerhet (er data trygge og tilgang styrt?)
- Skalerbarhet (tåler systemet vekst?)
Denne delen av testarbeidet er ofte usynlig for den som ikke vet hva man skal se etter. Men det er akkurat her mange prosjekter går på en smell – fordi «alt virker», men det oppleves ikke som om det virker.
Et praktisk eksempel
Du skal lansere et nytt intranett. Alt virker – på papiret. De ansatte kan logge inn, finne dokumenter og sende inn skjemaer.
Men så begynner klagene:
- Det tar 7 sekunder å laste startsiden.
- Navigasjonen er ulogisk – ingen finner frem.
- Systemet låser seg hver gang du åpner flere faner.
Her er det ingenting galt med funksjonene. Problemet er at det som skal fungere, fungerer dårlig i praksis.
Hvorfor bør du som bestiller bry deg?
Fordi dette ikke er noe du bør overlate til tekniske ressurser alene. Når du bestiller eller leder et prosjekt, er det du som setter premissene. Du har kanskje ikke ansvar for teststrategien – men du har ansvar for kvaliteten på det som skal leveres.
Hvis du kun etterspør «test» uten å vite hva det innebærer, er det lett å tro at alt er i orden – så lenge ingenting krasjer. Men du kan fortsatt få en løsning som skaper irritasjon, ineffektivitet og tillitsbrudd.
Det er her bevissthet om funksjonell og ikke-funksjonell testing gjør deg til en bedre bestiller.
Hva bør du gjøre i praksis?
- Etterspør teststrategien tidlig. Hva skal testes? Hva er de viktigste risikoområdene?
- Be om både funksjonelle og ikke-funksjonelle krav. Ikke alt trenger å spesifiseres i detalj, men det bør være bevissthet rundt ytelse, brukervennlighet og robusthet.
- Involver testleder tidlig. Det gir bedre struktur og riktigere prioriteringer i prosjektet.
Til slutt: En løsning kan virke, uten å fungere
Forskjellen mellom funksjonell og ikke-funksjonell testing er egentlig enkel: Det handler om at noe virker – og hvordan det virker. Begge deler må være på plass hvis prosjektet ditt skal gi verdi.
I Aspira jobber vi med testledelse som en integrert del av prosjektgjennomføringen. Vi hjelper kundene våre med å sikre at løsninger ikke bare blir levert – men også brukt, forstått og verdsatt.