Mange tenker at testing handler om én ting: å finne feil. Men god testing handler om å skape trygghet. Trygghet for at systemet gjør det 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 kan virke teknisk, men som har stor praktisk betydning, særlig for deg som bestiller eller eier et prosjekt.
Funksjonell testing: gjøres det riktige?
Funksjonell testing sjekker 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 genereres og sendes til riktig mottaker.
Kjernen er enkel: virker funksjonene som de skal? Et typisk eksempel fra bank: kunden logger inn, overfører penger, og mottar kvittering. Hvert steg verifiseres mot kravspesifikasjonen. Fungerer stegene? Da er funksjonell test bestått for den flyten.
Dette er «det synlige laget» av testing. Det er konkret, målbart og som regel godt dokumentert i testplanen.
Ikke-funksjonell testing: gjøres det godt nok?
Mens funksjonell testing ser på hva systemet gjør, handler ikke-funksjonell testing om hvordan det gjøres. Her vurderes egenskaper som ytelse, stabilitet, brukervennlighet, sikkerhet og skalerbarhet.
Et system kan bestå alle funksjonelle tester og likevel feile i praksis. Startsiden tar syv sekunder å laste. Navigasjonen er ulogisk. Systemet låser seg under høy belastning. Funksjonene virker – men opplevelsen er uakseptabel.
Ikke-funksjonell testing er det som avdekker denne typen problemer før de møter brukerne.
Sammenligning: funksjonell vs. ikke-funksjonell testing
| Funksjonell testing | Ikke-funksjonell testing | |
|---|---|---|
| Spørsmål | Gjør systemet det riktige? | Gjør systemet det godt nok? |
| Fokus | Funksjoner og krav | Ytelse, sikkerhet, brukervennlighet |
| Eksempler | Innlogging, betaling, søk | Lastetid, belastningstesting, sikkerhetstest |
| Synlighet | Lett å verifisere | Krever dedikert planlegging |
| Tidspunkt | Løpende gjennom prosjektet | Typisk når systemet er mer komplett |
Begge er nødvendige. Den ene erstatter ikke den andre.
Et praktisk eksempel
Du lanserer et nytt intranett. Alt virker på papiret. Ansatte kan logge inn, finne dokumenter og sende inn skjemaer.
Så begynner klagene. Startsiden tar syv sekunder å laste. Navigasjonen er ulogisk – ingen finner frem. Systemet låser seg når man åpner flere faner samtidig.
Ingenting er galt med funksjonene. Problemet er at det som skal fungere, fungerer dårlig i praksis. Dette er et klassisk eksempel på manglende ikke-funksjonell testing.
Med nesten 30 år i bransjen og prosjekter i bank, offentlig forvaltning og telekom ser vi dette mønsteret igjen og igjen. Funksjonell test er på plass. Ytelse og brukervennlighet er glemt. Lanseringen møter motstand fra dag én.
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, setter du premissene for hva som testes. 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 ende opp med en løsning som skaper irritasjon, ineffektivitet og tillitsbrudd hos brukerne. En god teststrategi dekker begge dimensjonene eksplisitt og tidlig.
Hva bør du gjøre i praksis?
Etterspør teststrategien tidlig. Hva skal testes? Hvilke risikoer er størst? Finn ut om strategien dekker både funksjonell og ikke-funksjonell testing.
Be om at ikke-funksjonelle krav spesifiseres konkret. Ikke «systemet skal være raskt», men «startsiden skal laste på under to sekunder for 95% av brukerne». Vage krav gir vag testing.
Involver en testleder tidlig. Det gir bedre struktur og riktigere prioriteringer gjennom hele prosjektløpet. Du kan lese mer om beste praksis for testledelse i komplekse IT-prosjekter og hva som skiller prosjektene som lykkes fra dem som ikke gjør det.
Sørg for at ytelsestesting gjennomføres med realistisk belastning. En test med ti samtidige brukere sier lite om systemet tåler tusen.
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 reell verdi.
Hos Aspiria jobber vi med testledelse som en integrert del av prosjektgjennomføringen. Vi hjelper kundene våre med å sikre at løsninger lever opp til kravene, fungerer under reell bruk og skaper det de var ment å skape. Ta kontakt med oss for en uforpliktende prat.
Ofte stilte spørsmål om funksjonell og ikke-funksjonell testing
Hva er funksjonell testing?
Funksjonell testing verifiserer at systemet gjør det det er spesifisert til å gjøre. Konkrete funksjoner som innlogging, søk og betaling testes mot kravene. Målet er å avdekke avvik mellom forventet og faktisk oppførsel.
Hva er ikke-funksjonell testing?
Ikke-funksjonell testing måler egenskaper som ytelse, sikkerhet, skalerbarhet og brukervennlighet. Det handler om hvor godt systemet gjør det det gjør – for eksempel om det er raskt nok under belastning eller trygt nok mot angrep.
Hva er forskjellen mellom funksjonell og ikke-funksjonell testing?
Funksjonell testing svarer på «gjør systemet det riktige?», mens ikke-funksjonell testing svarer på «gjør systemet det godt nok?». Et system kan bestå alle funksjonelle tester og likevel feile i praksis på grunn av dårlig ytelse eller lav brukervennlighet.
Når bør funksjonell og ikke-funksjonell testing gjennomføres?
Funksjonell testing gjennomføres løpende gjennom prosjektet fra første leveranse. Ikke-funksjonell testing bør planlegges tidlig, men gjennomføres typisk når systemet er mer komplett. En erfaren testleder sørger for at begge typer er med i teststrategien fra starten.
Hva er eksempler på ikke-funksjonell testing?
Typiske eksempler er ytelsestesting (tåler systemet forventet belastning?), sikkerhetstesting (er data og tilganger sikret?), brukervennlighetstesting (opplever brukerne systemet som intuitivt?) og regresjonstesting (fungerer eksisterende funksjonalitet fortsatt etter endringer?). Du finner mer om testrelatert risiko og prioritering av testarbeid i vår guide.