Ytelse og funksjonelle egenskaper er ofte veldig viktige for sluttbrukeren. 

Har du noen gang fundert på samspillet og timingen mellom funksjonell test og test av ytelse?
Jeg vil påstå at det å se sammenhenger ikke alltid så enkelt. Læring skjer i ulike settinger; gjennom å gjøre feil eller få en "aha-opplevelse". Ved å observere andre eller å tenke selv.Derfor ønsker jeg å forsøke å beskrive hvordan funksjonell test samspiller med ytelsestest.

Funksjonell testing ("over teppet")
Hva er viktig å tenke på ved funksjonell testing ? Jo, man bryter opp systemet i nødvendige biter slik at det er mulig å konkludere om en eller en serie av hendelser gir ønsket utfall.

Testscenarioer kan lages ut i fra brukerkrav eller krav utredet fra en beskrevet/tenkt prosess. Målet gjennom testing er å dekke mest mulig av transaksjonene, gjerne prioritert mot en risikomatrise.

En del av disse funksjonelle testene bør være ende-til-ende tester. Det betyr at man bør teste i et produksjonslikt miljø hvor man kan simulere visse parametere (båndbredde, last etc.) eller uten simulering hvis det ikke er nødvendig.

Så hva gjør funksjonell test da oppsummert, jo:
1) Sørger for forventet kvalitet på applikasjonen i sin helhet.
2) Testingen bør gjenspeile faktisk bruk av systemet, og spesielt da ha fokus på de kritiske områdene/funksjonene.

Ytelses testing ("under teppet")Kvalitetsegenskap - Ytelse
Hva er ytelsetest? Jo, å teste systemets responstid på et bestemt tidspunkt med en bestemt last/belastning. Gjennom å teste systemets generelle ytelse av spesifiserte transaksjoner får man svar på hvordan responstid er for hver enkelt funksjon. Men det er også viktig å simulere reell bruk av systemet (ikke alltid like lett å estimere). Det er ønskelig å finne flaskehalser gjennom å simulere riktig antall brukere som samtidig vil utføre samme transaksjon(er).

Så hva gjør ytelsestest da oppsummert, jo:
1) Hindrer at brukerne forlater systemet (gir opp eller blir utålmodig)
2) Hjelper til med å forstå hvordan løsningen oppfører seg i en reell situasjon (live)
3) Bidrar til å forstå hvordan brukeren kommer til å oppleve systemet
4) Kan sørge for at kundene for tillit til løsningen (forutsigbarhet og tillit)

Hvordan kan da disse 2 egenskapene sammen gi bedre kunde opplevelse?
Hovedpoenget mitt i denne artikkelen er at jeg ofte erfarer at det først tenkes på funksjonelle kvalitetskrav og så har ikke-funksjonelle krav en tendens til å komme i etterkant. Jeg tenker årsaken kan være kompetanse eller organisatoriske årsaker. Funksjonelle og ikke-funksjonell krav kan, etter det jeg har erfart, ha en tendens til å håndteres hver for seg. Med litt eller mye forskyvning i tid. Jeg sier ikke at det alltid er slik, men at det kan være slik. Funksjonell krav har også en tendens til å bli prioritert først, kanskje fordi disse synes lettere å definere.

Så hvorfor ikke gjøre funksjonell test og ytelsestest samtidig? Du kan oppnå fordeler som:
1) Du får testet viktige funksjoner i løsningen med en kjent belastning, og vil kunne måle reell responstid.
2) Du kan ha bedre grunnlag for å vite om systemet er skalert og tunet riktig, og kan håndtere vekst
3) Du kan få bedre innsikt i hvordan infrastruktur bør skaleres opp hvis/når antall brukere økes.
4) Du sparer masse tid og kostnader ved å oppdage ytelsesproblemer tidlig, i stedet for å oppleve det i produksjon (problem med ytelse i produksjon kan være ekstremt ødeleggende)
5) Brukerne vil få tillitt til løsningen fra starten av. Det er vanskelig å rette opp brutt tillit.
6) Ytelsesproblemer kan være utfordrende å løse, det kan det lang tid å finne årsaken.

Håper du her fikk en del tips og argumenter om hvorfor du bør gjøre ytelsestest og funksjonell test i parallell. Jeg skjønner det kan være vanskelig å få til i praksis. Men da bør du spørre deg hvorfor det er vanskelig, og gjøre noe med det. Et siste viktig budskap er å gjøre referansemålinger, de bør gjøres kontinuerlig også under test og utvikling. Da kan du fange opp tidlig når systemets ytelse har endret seg, og lettere knytte dette til hva som endret seg på dette tidspunktet. Det er sent og ødeleggende å få ytelses problemer i produksjonsmiljøet. Det er også kostbart å skalere løsningen opp i størrelse og dra på unødvendige kostnader. Bare for å sikre seg. Det er heller ikke sikkert det hjelper så mye.