Sådan tester man low cost a la Steve Krug:
- Erkend at det kræver iterationer af småtester at få afdækket de
vigtigste ting, efterhånden som systemet bliver udviklet.
- Start med at teste fra det øjeblik, hvor de første streger er
sat på servietten. Revider så, test igen, revider, test, revider…
og fortsæt på den måde, så længe der kodes.
- Byg testene op omkring opgaver/scenarier.
- I debriefingen fokuseres på de problemer, som testen viste;
ikke på konkrete løsninger af dem. Succeser skal også noteres.
Man skal generelt ikke:
- Stille et større testapparat på benene, end der er ressourcer
til at følge op på data fra.
- Konkludere på ikke-åbenlyse fejl før efter at de har vist sig i
to eller tre tests.
- Skrive kæmpe, lange rapporter. De er dyre at lave, og de bliver
ikke læst. Listerne af forbedringer "gemmes" til version 2 af
softwaren, hvor halvdelen er forældede, og hvor den nye version
introducerer andre fejl.
- Bruge nævneværdige ressourcer på at finde subject matter
experts at teste på. Det er nemlig sjældent i subject
matter-materien, at brugsproblemerne ligger. Formuler dog et
minimalkrav i forhold til testbrugerens viden om emnet, f.eks.
"bilejer", "potentiel huskøber", "allergiker" eller lignende.
- Lade sig forblænde af, at man finder en sværm af lavthængende
frugter; det ser effektivt ud, og de skal fikses, men det er
sjældent her de store afsporinger i brugsoplevelsen ligger
gemt.
Krug syntes, at det komplicerede det hele, at skulle tænke dén
model ind i en agile arbejdsgang. Jeg kan overhovedet ikke se, på
hvilken måde den her tilgang til brugertest ikke passer perfekt til
f.eks. scrum.
Tags:
