Agile, Scrum, KanBan, XP, Lean är några nya förkortningar vi har börjat vänja oss vid de senaste åren. Agil utveckling har fått starkt fotfäste i Sverige och vi är i högsta graden delaktiga i vidareutvecklingen av detta.
Med de agila vindarna så följer även ett förändrat arbetssätt för oss testare. Vi kan inte sitta och vänta på att en komplett kravspecifikation ska godkännas och låsas och därefter påbörja ett långt förberedande arbete med att skriva detaljerade testfall för att sen, precis innan release av produkten, gå in i en test exekveringsfas och till sist avsluta med en gedigen testrapport.
Vi har helt enkelt inte tid till allt detta nu när vi börjar jobba i korta iterationer, använder oss av högnivåkrav i form av "user stories" och snabb återkoppling. Men till vad ska vi förändra oss för att passa in tillsammans med den agila andan?
Börjar man kika runt lite kring agil testning så stöter man snabbt på ett gäng nya förkortningar så som bland andra TDD (Test Driven Development) och ATDD (Acceptance Test Driven Development). Olyckligtvis finns ordet "test" med i många av dessa metoder och det är lätt att tro att detta är den nya agila testningen som är lösningen. Tyvärr är så inte fallet, det är till och med så att detta har väldigt lite med testning att göra.
Dessa metoder kan ofta vara väldigt värdefulla och tillföra många positiva effekter. Dock är metodernas främsta syfte att skapa enkel design, underhållsbar och förståelig kod. De hjälper utvecklarna att ha kontroll på sin kod och för att dom ska veta när dom ska sluta koda. Vad man gör är att man bygger upp ett bibliotek med automatiska checkar som syftar till att ge snabb återkoppling till utvecklaren hurvida koden fortfarande är intakt på samma sätt som den var innan man la på ny kod. På detta sätt får utvecklarna förtroende för kodmassan och man kan göra kontrollerade förändringar eller tillägg.
Men som sagt, man testar inte koden utan får endast en bekräftelse att läget är status quo. En check syftar till att bekräfta att det jag visste om produkten innan jag förändrade den fortfarande är sant. En check har ett binärt resultat "pass/fail". En check går alltid att automatisera. Checking är viktigt, det skapar ett fundament som möjliggör fantastisk testning [1].
Så när ni letar efter testare till era agila team så gå inte i fällan att tro att det är en person som är en fena på testautomation ni behöver. Denna kompetensen har ni redan hos era utvecklare.
Om vi nu har konstaterat att vi inte kan testa som tidigare och vi som testare inte ska fokusera på dessa agila testmetoder som finns. Vad är det då vi ska göra?
Testning, till skillnad mot checkning, är ett detektivarbete som inte är förutsebart. Testning söker upp tidigare okänd information om produkten. Detta gör vi genom utforskning, upptäckt, undersökning och lärande. Testning kräver en människas komplexitet, kognition, observationsförmåga, tankeprocess och slutledningsförmåga. Testningens uppgift är att ta fram och leverera information till intressenter som en del i grunden till de beslut som behöver fattas. Testarens ansvar är att se till att denna information tas fram vid rätt tid, är lämplig, relevant och värdefull för våra intressenter.
För att vara värdefulla i en agil kontext måste vi gå ifrån våra gamla beteenden. Vi kan inte förlita oss på dokumentation utan behöver vara delaktiga i diskussion och problemlösning. Vi kan inte in i minsta detalj specificera testfall utan måste lära oss att jobba med "test idéer" [2], "heuristics" [3], "test framing" [4], "oracles" [5]. Vi kan inte påbörja vår testning när all funktionalitet är färdigutvecklad utan börjar testar små delar av funktionalitet tidigt för att ge snabb återkoppling till utvecklingen.
Vårt resultat från testningen är inte antal körda testfall eller ett pass/fail förhållande eller antal funna buggar. Vi levererar istället information som knyter an till affärsrisker, tekniska risker och användarnas förväntningar. Vi kommer närmare och förstår alla delar av produktutvecklingen för att veta vad vi ska testa. Vi kan inte förvänta oss att någon ska ge oss en färdig karta över produkten utan vår uppgift är att ta fram och förse våra intressenter med denna karta.
Detta sätter helt nya krav på testaren som nu sätts i förarsätet och dennes kunskap, erfarenhet och skicklighet är avgörande för hur lyckat resultatet blir. Testare kan inte längre gömma sig bakom tvivelaktiga processer kallade "best practises", gamla färdigskrivna testfall som körs om och om igen, skylla på att man inte kan börja testa för att kravenspecen inte är färdig eller rapportera testresultat i ett test management verktyg istället för direkt kommunikation med berörda parter. Det är en stor omställning som inte kommer ske av sig själv men som är tvungen att ske om man på alvar vill lyckas nå en agil kultur. Vi kallar detta angreppsätt till för Exploratory test [6] eller Utforskande test. Som är en del av Kontext Driven Testning [7].
//Henrik Andersson, House of Test i samarbete med Nohau
[1] http://blog.houseoftest.se/2012/03/26/checking-as-an-enabler-for-testing/
[2] http://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf
[3] http://www.developsense.com/blog/2012/04/heuristics-for-understanding-heuristics/
[4] http://www.developsense.com/blog/2010/09/test-framing/
[5] http://www.softwarequalitymethods.com/Papers/STQE%20Heuristic.pdf
[6] http://www.satisfice.com/articles/et-article.pdf
[7] http://context-driven-testing.com/