I vår bransch är Quality Assurance viktigt och vi har särskilda QA-personer i projekten. Men vilka är det egentligen som har ansvar för kvalitet i mjukvara? Ulrika Malmgren ger en testares syn på QA.
“Quality Assurance”. Alla använder uttrycket: utvecklare, management, scrum masters, testare, med flera. Begreppet finns i många branscher och enligt Wikipedia började hantverksgillen med Quality Assurance redan under medeltiden för att sätta en standard på sina medlemmar. Men det var förmodligen först under industrirevolutionen som det tog fart ordentligt. Det var då särskilda personer som fick i uppdrag att säkerställa att en annan persons arbete hade ett godkänt resultat.
I vår bransch anses det viktigt att arbeta med QA. Vi budgeterar tid och pengar för QA, anställer speciella personer och ser till att ha QA-tasks med i sprintplaneringen. Men vad betyder det egentligen?
Tänk på hur det blir när vi byter ut akronomet “QA” mot det fullständiga uttrycket “Quality Assurance” i några vanliga påståenden:
- “Vi har en Quality Assurance i vårt team”
- “När du har kodat klart så får Quality Assurance-specialisten titta på det där”
- “Någon Quality Assurance-person borde Quality Assurance-a den buggfixen”
- “Quality Assurance-arbetet gör vi i slutet på sprinten”
Visst låter det konstigt? Vad är det egentligen vi säger? Menar vi verkligen att kvalitet är något som en person har ansvaret för? Menar vi verkligen att kvalitet arbetar vi med i slutet av sprinten? Kan man verkligen säkerställa kvalitet? Om det går, vill vi ens göra det?
System är i grunden så komplexa att det är praktiskt taget omöjligt att faktiskt säkerställa att ett program är fritt från buggar. Det gäller till och med de enklaste små program och är ännu tydligare i större. Detta gör att det faktiskt är omöjligt för någon, hur specialiserade på “Quality Assurance” de än är, att kvalitetssäkra ett program.
Men det borde egentligen inte handla om kvalitetssäkring, det borde handla om testning. Testning är processen att sammanställa information om ett system med syftet att använda informationen till något (Gerald M. Weinberg. “Perfect Software and Other Illusions about Testing”). Vi ställer ett antal utvalda frågor genom våra tester och utvärderar svaren vi får från dem. Det vill säga, vi tar reda på hur systemet beter sig givet en viss inmatning och funderar på om beteendet känns rimligt och önskvärt. Ibland kan vi inte själva avgöra det och tar hjälp av produktägaren som äger rätten att besluta om systemet uppfyller dennes önskemål.
Vår förmåga och fallenhet för att ställa frågor gör testare värdefulla i tidiga skeden av utvecklingsarbeteet. Vi är till exempel med på planeringen och bidrar med frågor om hur specialfall ska hanteras, hur systemet ska bete sig när uppkopplingen går ner, om andra delar av applikationen påverkas, och så vidare. Ibland ställer vi dumma frågor bara för att hålla igång samtalet för vi vet att det är redan på planeringen som allvarliga fel såsom missuppfattning och grova feltänk uppträder och ju längre vi diskuterar desto större är chansen att vi upptäcker dem. Vi vet att vi redan där kan bidra med att se till att kvalitet är någonting som är närvarande i utvecklingen.
Men för att verkligen lyckas måste hela teamet och hela organisationen ta sitt ansvar och tänka på kvalitet. Det bör genomsyra tankar och agerande hos programmerare, produktägare, linjechefer och scrum masters.
Vi borde alltså inte kallas Quality Assurance-personer eller Quality Assurance-specialister och vi varken kan eller bör kvalitetssäkra något. Vi ställer frågor och utvärderar svaren. Vi heter testare.
