Test innan implementation

den 20 januari 2015

För att få ut så mycket som möjligt av en testare är det viktigt att personen är med från början i sprintarna och att man tidigt kan komma igång med sina tester. Det är också viktigt att ha en bra övergripande förståelse för lösningen och förstå användarna och redaktörerna på bästa sätt.

Vi funderade på hur vi skulle kunna göra för att hitta kvalitetsbrister så tidigt som möjligt i projekten och på i vilket/vilka steg som test kunde komma in och påverka och bidra med något annat än ”ren testning”. En viktig del av vårt arbete är att ställa frågor om lösningen som ingen annan har tänkt på. Vi pratade ihop oss med en interaktionsdesigner och kom fram till att börja testa redan från skisser.

Detta är såklart en utmaning då man inte kan interagera med lösningen på samma sätt som när den är implementerad. Det är här ifrågasättandet kommer in och man får som testare sätta sig in i olika roller och ställer frågor utifrån dessa. Man gör alltså samma sak som när man testar på utvecklade funktioner men redan på skisserna.

Vi började att provköra detta i ett projekt som skulle ta fram en inköpslista utifrån recept. Mötet började med att interaktionsdesignern gav oss en kort brief av skissen utan att ge för mycket information om respektive funktion. Det är viktigt att interaktionsdesignern inte avslöjar för mycket om skissen då det kan hämma det kreativa tankeförloppet. Efter detta började vi testa genom att ifrågasätta funktion för funktion.
Frågor som uppstod under mötet kunde vara: ”Vad händer om jag ska använda 3 ägg i ett recept, kommer jag få förslag på att köpa ett paket med 6 ägg, ett paket med 12 ägg eller ägg i lösvikt?” ”Hur ska inköpslistan sorteras, efter bokstavsordning eller hur butiker är organiserade inredningsmässigt?”.

Det är även viktigt att ställa frågor av det simplare slaget så som: ”Vilken sida ska jag hamna på om jag klickar här?” ”Vad händer när jag tar bort ett recept, försvinner varorna i inköpslistan?”. Efter mötet tar interaktionsdesignern med sig vår feedback och skissar vidare.

Med hjälp av den här metoden kunde vi redan innan skisserna var klara hitta kritiska saker, alltså innan implementationen ens startat. Den stora fördelen med detta är att man slår två flugor i en smäll. Interaktionsdesignern får tips och kan fånga upp saker tidigare, test får en bättre koll på lösningen innan testningen tar fart. I vissa projekt kanske inte budget eller tid finns men det räcker med korta avstämningar någon gång i månaden.

En till fördel med att interaktionsdesignern och testaren jobbar tillsammans redan i början av projektet är att båda ”sitter på” samma information. På så sätt blir projektet inte lika sårbart om någon är borta eller sjuk. Ytterligare en positiv effekt som detta medförde var att sprintplaneringen inte tog lika lång tid då en del av de frågor som annars dyker upp på sprintplaneringen redan var ställda. Fokus kunde istället läggas på att detaljera och estimera funktionerna av den faktiska lösningen. Detta blir alltså i längden både tidssparande och kvalitetshöjande.

Vi tycker att detta har fungerat väldigt bra då vi kunde ge interaktionsdesignern flera bra idéer och synpunkter att fundera vidare på. Att vi hittade det redan innan någon ens hade börjat bygga på funktionen, och inte när den var utvecklad och redo för test, sparade både utvecklings- och administrationstid.

För att ta detta vidare har vi en idé om att man kan inkludera hela teamet genom att tilldela roller till olika personer. Exempelvis kan en utvecklare bli tilldelad rollen som en datorovan äldre användare och man måste tänka och fråga utifrån sin roll som man blev tilldelad. Detta skulle vara bra då man tillsammans jobbar fram en lösning utifrån många perspektiv och alla har samma information om lösningen.