Den gode nyhed er, at der er en løsning på problemet. Der er faktisk en måde at sikre, at den nye funktion virker for brugerne. Og det er lige før, at træerne vokser ind i himlen, for løsningen kan faktisk også ende med at spare dig både tid og penge!
Løsningen er nemlig ikke, at du bare skal lave flere testes. Nej, løsningen er, at du skal lave forskellige slags test! Du skal derfor “test smarter – not harder”!
Funktionelle og ikke-funktionelle tests
Grundlægge er der to slags tests: Dem, der tester om funktionen virker, og dem, der tjekker om brugeren kan finde ud af at bruge funktionen.
Funktionelle tests tester om funktionen virker: Når man putter data ind, er resultatet så som forventet? Hvis man med andre ord putter A ind i funktionen, kommer der så B ud som forventet? Eller Å?
Ikke-funktionelle tests er anderledes. Her tester vi nemlig ikke om funktionen virker – det antager vi faktisk, at den gør, da der formentlig er gennemført funktionelle tests. I stedet tester vi, om brugerne kan finde ud af at bruge den nye funktion. Det gør man meget enkelt ved at stille dem en konkret opgave og se, om de kan løse den og hvordan de løser den. Det vigtigste er, at de kan løse opgaven – om de løser den, som du eller udviklerne havde tænkt, er ikke så vigtigt, men det giver værdifuld information om, hvordan brugeren forstår interfacet i systemet.
Det hele starter med en testprotokol…
Når du skal lave enten funktionelle eller ikke-funktionelle tests, starter det hele med en testprotokol. Den beskriver, hvad der skal testes, hvordan og hvad succeskriterierne er.
For en funktionel test kunne det være, at der skal testes et API-endpoint svarer, når det bliver kaldt. Vi tester det ved at kalde det med en række parametre og succeskriteriet er, at vi får det forventede svar retur. Så laver vi et kald med parameter A, forventer vi B og ikke Å. Er resultatet B, er testen derfor gennemført med succes.
For en ikke-funktionel test kunne det være, at en bruger skal udføre en række opgaver. Opgaverne beskriver et resultat, man skal opnå – ikke hvordan man skal opnå det. Det er jo dét, vi gerne vil teste. En opgave kunne derfor være, at brugeren skal printe en bestemt liste i systemet. Kan brugeren finde frem til den liste og printe den, er opgaven løst.
Men er det nu også nødvendigt?
Ja, det er nærliggende at tænke den tanke. For bliver det ikke bare mere og mere test, når vi nu skal lave både funktionelle og ikke-funktionelle tests? Nej, for der er problemer, der er meget nemmere at fange, når man laver bare én ikke-funktionel test – faktisk lader sig kun fange ved ikke-funktionelle tests!
Tænk blot på, hvor meget tid der går med at få den nye funktion ud til brugerne blot for at opdage, at den ikke dur! Brugeren har brugt en masse tid – og er formentlig blevet godt og grundigt frustreret. Der er blevet brugt tid i supporten på at snakke og forstå brugeren. Der er blevet brugt tid på at lave en bug, planlægge buggen ind i et sprint, løse buggen og få bugfix med i et release. Al den tid kunne en ikke-funktionel test formentlig have sparet!
Et eksempel fra den virkelige verden
I efterårsferien var jeg i sommerhus. Min kone, Karen, og jeg holder af at gå ture og så, at der var kommet et par nye naturstier. Dejligt, tænkte vi. Dem prøver vi!
Da vi startede, var der en fin info-stander med en QR-kode til en app. Det lød sjovt, tænkte vi, og hentede den ned. Og den var faktisk ikke helt tosset! Der var nogle sjove små opgaver, man kunne løse, og man kunne endda være med i lodtrækningen om 2 x biografbilletter, hvis man løste alle 10! Så var vi ellers klar til at gå tur!
Men der var bare lige den udfordring, at opgaverne skulle løses på bestemte steder på ruten – faktisk indenfor en 5-10 meter. Og eftersom app’en ikke gav lyd, når man var tæt på en opgave, skulle vi så gå med snuden i skærmen hele turen… Så vi fandt ikke mange opgaver. Faktisk fandt vi kun én… For formålet med turen var jo at nyde den flotte natur.
Bare én ikke-funktionel test er bedre end ingen
Morten Münster siger det meget fint i bogen “Jytte fra marketing er desværre gået for idag“: Bare én ikke-funktionel test er bedre end ingen ikke-funktionel test. Og det har han så sandelig ret i!
For var der bare én person fra projektet med de fine nye naturstier, der havde taget vandreskoene på og gået ruten med mobilen i hånden, ville den fejl være fanget med det samme.
Der var jo ikke som sådan nogen fejl i app’en. Man kan diskutere, hvor god en brugeroplevelse der var designet, men en funktionel test kunne fint køre igennem med succes: Man kommer hen til posten, app’en finder posten og præsenterer den på skærmen. Bom, funktionen virker som ønsket!
Men for brugeren – Karen og jeg – virkede det ikke. For vi vidste ikke, hvor posterne lå og kom altid til at gå for langt eller forkert i forhold til at finde dem. Så den ikke-funktionelle test gik lige i hegnet…
Det er bare at komme igang og øve sig
Den gode nyhed er, at det er ikke raketvidenskab at lave ikke-funktionelle tests. Så det er bare at komme i gang, invitere nogle brugere indenfor og give dem nogle opgaver. Husk på, at bare én lille bitte nybegynderdesignet ikke-funktionel test er bedre end ingenting.
Men når det er sagt, så er det at gennemføre en god ikke-funktionel test et håndværk. Det skal læres og øves – mange gange! Der er masse af faldgrubber: Du kommer til at guide brugeren under testen, opgavens formulering dur ikke, opgaverne giver slet ikke mening for brugerne og så videre.
Lad det ikke afholde dig fra at lave dem! For jo flere du laver, jo bedre og mere brugbart bliver resultatet. Så op på hesten og afsted til den næste ikke-funktionelle test!
Vil du undgå at lave disse 5 fejl?
Inden du sadler hesten og rider afsted, så tag lige en kop kaffe og læs det her indlæg af Charlotte Albrecthsen fra tovejs.dk: “Laver du også disse 5 fejl, når du tester brugeroplevelser?” Så er der 5 fejl, du slipper for at lave.
Har du hørt vores podcast om brugere?
Vi har lavet en hel række af episoder i podcast “Scrum med mere”, hvor teamet er brugere. Vil du høre mere om testprotokol og brugere, så lyt med her.
Du kan også abonnere på “Scum med mere” i iTunes. Så får du nye episoder lige så snart de er klar!
