Testledelse - tip til styring af "tænke-højt"-forsøg

I de følgende afsnit beskrives testlederens rolle og eksempler på, hvordan man kan testlede.

Testlederen er ansvarlig for hele forløbet af testen. Det er testlederen, der er brugerens primære kontaktperson og ham, der bestemmer rammerne for testen. Der kan være andre folk til stede under testen, men de bør indordne sig under testlederens regler. Regler som bygger på, at brugeren skal føle sig hørt og respekteret.

Få brugeren til at føle sig godt tilpas

Hvis en bruger er nervøs, bør man hjælpe ham i starten af testen, så han efterhånden får mod på at arbejde videre med systemet på egen hånd.

Start altid en test med at fortælle brugeren, at det ikke er afgørende, at et bestemt antal opgaver løses eller, at alle dele af systemet undersøges. Det væsentligste er, at brugeren arbejder seriøst og i sit eget tempo.

Overhold sociale konventioner

Naturligvis skal testlederen ikke bryde forstyrrende ind i brugerens tankegang. Men små tilkendegivelser af, at noget brugeren sagde, var interessant, spørgsmål om, hvad brugeren tænker på eller en underfundig bemærkning kan hjælpe med til at signalere, at testlederen er til stede.

Brugeren har altid ret

Lyt og spørg

Generelt skal man være opmærksom på at undgå for mange hvorfor-spørgsmål. Brugeren skal ikke stå til regnskab over for testlederen, og normalt er det meget mere interessant at få at vide - få at se -, hvordan brugeren håndterer en bestemt opgave, hvornår han gør det, og hvad han får ud af det.

Stil åbne spørgsmål

Anvend brugerens egne ord

I en dialogsituation skal man som testleder være opmærksom på at anvende brugerens ord både for at forhindre, at der lægges ord i munden på brugeren, men også for at sikre, at han forstår, hvad der bliver sagt. Som en gylden regel bør enhver form for edb-jargon undgås. Det er fx ikke alle, der ved, at der findes noget, der hedder en scroll bar/rullepanel/elevatorskakt/…. Derfor bør man lytte efter, hvad brugeren selv kalder tingene. Også fordi brugerens terminologi i sidste ende bør afspejles i grænsefladen.

Nedenfor er samlet en række anbefalinger til, hvordan man kan håndtere situationer, der typisk volder problemer for mindre erfarne testledere.

Ledetråden i alle anbefalingerne er, at man skal holde en dialog kørende med brugeren uden at give direkte hjælp. Hvor grænsen går for, hvornår man skal hjælpe brugeren, varierer fra test til test; nogle brugere kan klare selv store problemer uden at føle ubehag ved testsituationen, andre brugere bliver lynhurtigt usikre på deres egen kunnen.

Hvis brugeren går i stå

• Hvis faciliteten faktisk findes i systemet, og brugeren blot ikke har opdaget/genkendt den, kan man fortælle ham dette - uden at afsløre, hvor faciliteten findes. Fx kan man bede brugeren om at gætte på, om faciliteten kan hedde noget andet end det, han selv har foreslået, og opfordre ham til at lede igen. Så snart brugeren har fået vished for, at den ønskede mulighed er til stede i systemet, stiger modet normalt.

  Kan brugeren efter andet forsøg ikke finde faciliteten, er det mest rimeligt at vise ham, hvor han kan finde den. Undersøgelser af virkelige brugssituationer (dvs. ikke test) viser, at brugere, der ikke har fundet svar på deres spørgsmål efter omkring 8 minutter, stort set aldrig formår at løse den opgave, de er i gang med, og er der gået 12-13 minutter er sandsynligheden stort set reduceret til nul. Der er med andre ord ingen grund til at vente med at afbryde en test, fordi man vil se, om brugeren selv finder løsningen - det vil han formentlig ikke gøre, hvis han befandt sig uden for testlokalet.
  

• Hvis den facilitet, brugeren eftersøger, ikke findes i systemet, er det rigtigst at forklare brugeren dette og i stedet opfordre ham til at tænke i andre baner. I den pågældende situation skal man altid forsøge at bekræfte brugeren i, at hans ønske var oplagt, og undskylde at udvikleren desværre har designet systemet anderledes.

Dette gælder primært i starten af testen, hvor det er vigtigt at få brugeren til at falde til. Senere hen kan man godt indgå i en dialog om ønskeligheden af et bestemt forslag fra brugeren. Det kræver dog, at man vurderer, at den pågældende bruger ikke føler sig klemt, hvis han bliver udfordret på sine holdninger. Husk at missionen med en test ikke er at demonstrere, hvordan systemet virker, og forklare hvad der rent teknisk kan lade sig gøre, men derimod at få et indtryk af, hvordan brugeren forventer, at systemet skal fungere. Enhver diskussion bliver lukket, hvis man meddeler brugeren, at noget er teknisk uladsiggørligt. Det er afgørende at få identificeret punkter, hvor brugerne har grundlæggende anderledes forventninger til systemet end det, der reelt tilbydes. I de tilfælde bør man altid acceptere, at systemet har en fejl.

Hvis det er en papirprototype, der testes, er det oplagt at udnytte muligheden for at lade brugeren skitsere sit forslag - eller skitsere det på hans vegne - i de situationer, hvor systemet ikke lever op til hans forventninger. Arbejder man med en elektronisk prototype, kan man overveje at lave et screen dump af det skærmbillede, der volder problemer, og tegne brugerens forslag ind på en udskrift.

Hvis brugeren beder om hjælp

Når brugeren har behov for hjælp, er det frem for alt testlederens opgave at understrege, at det er systemet, der er problemer med, ikke brugeren der er dum. Bekræft brugeren i, at det ikke er helt intuitivt at løse opgaven - uanset om dette er tilfældet eller ej. Samtidig kan man gentage over for brugeren, at det er utroligt lærerigt at se, hvad han vil gøre i en tvivlssituation - når systemet bliver frigivet, vil der ikke sidde en testleder ved siden af og give hjælp, og derfor er det vigtigt at vide, hvilke problemer der skal tages højde for.

Hvis brugeren spørger, hvad et bestemt ord betyder, kan man prøve at undgå at give svaret straks, men først bede brugeren om at gætte. Gætter brugeren ikke rigtigt, bør man forklare, hvordan systemudvikleren har benyttet ordet, da almindelige sociale kodekser foreskriver, at man svarer på de spørgsmål, man får stillet. Det er ydermere uetisk at lade brugeren fortsætte, hvis man kan høre på hans forklaring, at han har misforstået ordet. Når han selv har bedt om hjælp, bør man give ham den i sidste ende.

Nedenfor er eksempler på sætninger, testlederen kan anvende, hvis brugeren beder om hjælp:

• Vi får en masse at vide om, hvad der skal forbedres i systemet ved at se dig løse opgaverne selv …
• Prøv at se, hvad der sker, hvis du løser opgaverne på din egen måde …
• Kast dig ud i det … det er udvikleren, der sidder og sveder lige nu!
• Har du tænkt på, at du også kunne …

Hvis brugeren ikke siger noget, imens han arbejder

Hvis brugeren er helt tavs, imens han arbejder, kan man som testleder prøve at få samtalen i gang ved hjælp af helt simple spørgsmål. Fx kan man spørge, hvad brugeren synes om det skærmbillede, han har foran sig, eller bede ham om at beskrive sin opgaveløsningsstrategi. En anden mulighed er at kommentere brugerens gestik eller ansigtsudtryk ved fx at sige "du ser tænksom ud".

Det gælder om at formulere sine spørgsmål, så brugeren ikke kan nøjes med at svare "ja" eller "nej". Hvis brugeren er meget fåmælt, kan det nogle gange hjælpe, at man som testleder selv fortæller, hvad man synes om et givent skærmbillede for simpelthen at give brugeren et eksempel på, hvordan man kan kommentere systemet.

Nedenfor er et par eksempler på sætninger, som testlederen kan bruge med det formål at få brugeren til at tale uden, at testlederen påvirker brugerens udsagn alt for meget:

• Hvad tænker du på lige nu?
• Forstår du teksten på skærmen?
• Hvad leder du efter nu?
• Hvordan vil du gerne kunne løse den opgave, du sidder med nu?
• Hvordan regnede du ud, hvordan du skulle gøre det?
• Prøv at fortælle, hvad det er, du er ved at gøre nu?
• Hvad tror du, der ville ske, hvis du klikkede lige der?
• Kan du sige noget om dit første indtryk af skærmbilledet?

Hvis brugeren "laver fejl" eller giver udtryk for noget, der lyder som misforståelser

Hvis brugeren ikke når frem til det ønskede resultat ved at følge sin alternative løsningsstrategi, skal han ofte hjælpes til at tænke i helt andre baner - hvis han er overbevist om, at han skal xx, før han kan yy, kan det være meget svært at gætte, at systemet lægger op til, at han går direkte til yy. Det må testlederen ofte antyde for at hjælpe brugeren i gang. Dette kan gøres, uden at man forklarer direkte, hvordan man gør yy.

I forbindelse med "tænke-højt"-forsøg viser det sig ofte, at brugeren har misforstået et koncept i systemet. Selvom det kan virke groft, at man ikke vejleder brugeren straks, når man opdager misforståelsen, er det vigtigt at konstatere, om brugeren selv finder ud af at justere sin opfattelse, eller om han ender med at køre helt fast i systemet.

Først når man har en fornemmelse af, at brugeren ikke af sig selv vil opdage den "rette" fortolkning af konceptet, bør man intervenere og tage en diskussion om, hvordan brugeren har forstået konceptet kontra systemets implementering af det. Fx kan man på et passende tidspunkt anføre, at man havde forventet, at han ville bruge en anden del af systemet, end det han er inde i og antyde, at dette måske er udtryk for et problem med systemet. Det er normalt et godt udgangspunkt for en diskussion.

Man bør aldrig lade en bruger fortsætte for længe ud ad en uhensigtsmæssig tangent, simpelthen fordi det er ubehageligt for både testleder og bruger, når det bagefter skal forklares, at systemet fungerer helt anderledes, end brugeren havde forventet.