Partestning - hur och varför?

den 4 oktober 2013

Testgruppen på Creuna har vid flera tillfällen det senaste året använt partestning som metod i olika typer av projekt. Efter ett antal sessioner med efterföljande utvärdering har vi funnit ett koncept som är effektivt för projektet samtidigt som det är utvecklande och inspirerande för testarna.

Partestning går ut på att man är två till tre personer som sitter tillsammans och testar ett system. Utöver detta finns det egentligen inga exakta regler för hur arbetet ska läggas upp, vilket lämnar det öppet för testarna att själva prova sig fram till en metod som passar dem och de aktuella projekten.

Hur har vi gjort?

Innan vi har satt igång med själva testerna har vi kört en kortare genomgång av lösningen, oftast med en utvecklare. Allra bäst har det varit när vi haft genomgången någon dag innan vi ska testa då det också gett möjlighet att stämma av att vi har åtkomst till alla aktuella miljöer. Därefter har vi gjort en planering och “timeboxning” av testerna. Där listas de funktioner eller delar av lösningen som ska testas och sedan fördelas tiden mellan dem i relation till deras bedömda komplexitet. Under själva testfasen håller man hela tiden koll på tiden och när den dedikerade tiden är slut är det dags att gå vidare till nästa del. På så sätt undviker man att fastna i en specifik funktion och endast hinna testa delar av lösningen. Vid några tillfällen har vi i slutet av sessionen gått tillbaka till speciellt komplicerade, eller buggtäta, funktioner och fortsatt utforska dem. Det är därför en bra strategi att lämna lite tid i slutet för att ha möjlighet att göra just detta. Totalt brukar vi avsätta 3-4 timmar för att utföra testerna, vilket vi upplever som en lagom nivå för att kunna jobba effektivt.

När det gäller buggrapportering tycker vi att det som fungerat bäst är att en person direkt skriver ner felen eller frågorna som hittas. Detta minskar efterarbetet och risken att saker glöms bort. Vår erfarenhet är dock att man inte bör vara alltför noggrann i det här skedet då man i så fall riskerar att tappa farten och flytet i testningen. Ofta krävs ändå att någon av testarna lägger en stund efter sessionens slut för att bifoga bilder, diskutera med utvecklare eller tydliggöra buggrapporterna.

En viktig del i att kunna förbättra och effektivisera partestningen är enligt vår erfarenhet att efter varje tillfälle ha en kort utvärdering och dokumentera vad som gick bra respektive dåligt, förslag till förbättringar och lärdomar att ta med sig. Dessa läser vi igenom inför nästa partestningssession för att successivt förbättra metoden.

Vi har kört partester på både tidigare helt otestade lösningar och lösningar som delvis testats, men även på lösningar som redan testats i stor utsträckning. De två förstnämnda har givetvis en självklar plats, men faktum är att även lösningar som i stort sett är färdigtestade kan vara lämpliga att applicera arbetssättet på. Även testare kan bli hemmablinda och behöva få ytterligare perspektiv på lösningen.

Vid ett flertal tillfällen har det funnits önskemål från projektet att sessionen ska innehålla test i olika browsers eller olika mobila enheter. Detta har vi valt att inte genomföra, då poängen med testsessionen är att öka den kreativa höjden snarare än att sitta tillsammans och beta av testfall. Tanken med sessionerna är att uppnå en “1+1=3”-effekt vilket vi anser vara förbehållet de mer utmanande delarna av testningen.

Win-win, men inte alltid...

De största fördelarna med partestning som vi ser är att det är givande både för projektet och för testarna. Vi upplever att vi hittar fler buggar under en partestningssession jämfört med vad som skulle hittats under samma antal timmar om man testat ensam. Samtidigt är det ett utmärkt sätt att vidga sina vyer och lära sig av kollegors metoder och angreppssätt.

Men om denna metod nu är så bra, varför inte bara använda sig av den? För oss är svaret att partestning är ett bra sätt att komma långt på kort tid, men det ersätter för den delen inte ett långsiktigt engagemang i projektet. Skulle man enbart arbeta med partestning som metod skulle man gå miste om mycket av helhetsbilden av lösningen samt det kontinuerliga kvalitetsarbetet i teamet. I det normala testarbetet är kunskap om kundens och projektets behov en viktig input som bland annat påverkar hur testfall och buggar prioriteras och bedöms. Dessa delar är svårare att känna till och använda sig av under en partestningsession där man bara gör en punktinsats i projektet.