Embedded Files
Tænke-højt-testen
Tænke-højt-testen
Det er meget svært at forestille sig alle de måder som et IT-system kan bruges på og derfor må vi teste det på nogle almindelige mennesker, som ikke kender til systemet i forvejen. Til det bruger vi tænke-højt-testen.
De tre faser i tænke-højt-testen:
De tre faser i tænke-højt-testen:
FASE 1
FASE 1
I denne fase udformer i opgaverne som brugeren skal løse i jeres app/it-system.
Det er vigtigt at opgaverne IKKE guider brugeren. Der må ikke være tale om en brugerguide. Man må ikke fortælle brugeren hvad de skal trykke på og hvad de skal gøre! Hvis vore design er godt, så kan brugeren selv finde ud af at bruge det.
Hvis man bliver nødt til at fortælle brugeren hvad de skal gøre, så er ens design ikke godt nok.
En opgave til brugeren er typisk et mål, som brugeren skal opnå i appen. F.eks.:
”Opret en profil og login”
”Køb en vare og betal”
”Book en rejse til Odense st.”
FASE 2
FASE 2
Vi bruger den mest almindelige test som er ”Tænke-højt testen”.
Brugeren sættes foran appen/IT-systemet og får opgaverne på et stykke papir.
Én fra gruppen er ”Testleder” og skal sørge for to ting:
1) At brugeren har forstået opgaven.
2) At brugeren hele tiden siger hvad de tænker.
Testleder må IKKE:
- Hjælpe eller guide brugeren.
- Tale til brugeren om irrelevante ting.
De andre medlemmer af gruppen filmer testen og tager noter.
FASE 3
FASE 3
Efter testen kvitterer gruppen med en flaske vin til testpersonen.
Derefter gennemgår gruppen materialerne fra testen (film, noter, lydoptagelser, røntgenbilleder etc.).
Ud fra materialerne finder gruppen eventuelle problemer med appen og udformer en liste over problemerne, hvor problemerne vurderes fra K1 til K3.
K1 er kosmetiske problemer (problemer der kun kortvarigt forvirrer brugeren).
K2 er alvorlige problemer (problemer der i længere tid forhindrer brugeren i at løse opgaven).
K3 er kritiske problemer (problemer der helt stopper brugeren i at løse opgaven og tvinger brugeren til at give op).
Opsamling på brugertest med problemliste:
Opsamling på brugertest med problemliste:
Efter at have lavet en brugertest som “tænke-højt-testen”, kigger man sine noter igennem, eller video, hvis man har optaget testen.
På baggrund af de informationer man har samlet fra testen laver man en problemliste over de problemer som brugeren havde med it-systemet (se længere nede for et eksempel).
Når man har lavet problemlisten vurderer man problemernes omfang.
Til det skal man bruge den samme skala, som anvendes til at vurdere problemer med huse. Skalaen går fra K1 til K3, hvor K1 er det mest overfladiske og K3 det mest kritiske.
Definition af K1 til K3:
K1 (kosmetisk problem): Et overfladisk problem som har med it-systemets udseende at gøre og kun er minimalt irriterende for brugeren.
- Eksempel: Indkøbskurven på en shopping-side er sat i et andet hjørne end brugeren regner med. Dette forvirrer brugeren kort.
K2 (alvorligt problem): Et problem som handler om mere end blot udseende og som besværliggør brugerens løsning af en opgave. F.eks. ved at det tager lang tid, at brugeren bliver forvirret eller irriteret eller lignende. Det kan være at brugeren ligefrem må finde en anden måde at løse opgaven på (work-around).
- Eksempel: Tilbageknappen mangler i en app og brugeren er derfor nødt til at lukke appen og starte forfra, for at ændre en fejl.
K3 (kritisk problem): Et problem der er så omfattende, at brugeren er ude af stand til at løse opgaven.
- Eksempel: Betalingsfunktionen på en shopping-side virker ikke og brugeren kan derfor ikke færdiggøre sit køb.
Det er vigtigt at huske at brugere er forskellige. Det vil sige at det der er et kosmetisk problem for nogle brugere kan være kritisk for andre.
Se længere nede for et eksempel på en problemliste fra en ikke-udgivet app kaldet MoveApp.
Vi lavede en brugertest, men fandt ikke rigtig nogle fejl!?
Vi lavede en brugertest, men fandt ikke rigtig nogle fejl!?
I informatik kan man godt komme ud for at udvikle en app som ikke er særlig omfattende og derfor er der måske ikke så meget brugeren kan foretage sig i den og derfor heller ikke særlig mange fejl de kan lave.
Uanset om man finder fejl eller ej er det en god ide også at skrive ting på problemlisten som:
Forbedringer appen ville skulle have i fremtiden.
Problemer som skulle rettes hvis appen skulle gøres helt færdig.
Page updated
Report abuse