Nya utvecklingsmetoder kräver nya testmetoder

Det är snart 10 år sedan det agila manifestot skrevs och många liter vatten har runnit genom Venedigskanaler och under de senaste åren har jag funderat på hur jag skulle vilja att ’test’ anpassade sig till nya utvecklingsmetodiker. När jag fick chansen att som ensam testare vara med i ett Scrum-projekt ville jag tillämpa testning, som jag tycker att den skall vara i ett Scrum-projekt.

Om man studerar det agila manifestet och de tolv principerna så är det två punkter som jag kommer att trycka på i denna artikel. Dessa två punkter är

  • Leverera fungerande programvara ofta
  • Fungerande programvara är främsta måttet på framgång

Den första punkten om fungerande programvara omfattar, enligt mig, både kravprocessen, utvecklingsprocessen och testprocessen. Hur kan då testningen bedrivas för att scrum-teamet skall kunna leverera en fungerade programvara och leveransen skall ske ofta?

Scrum teamet – vilka roller finns?

Något som är bra med scrum är att det bara finns tre givna roller, produktägare, scrum master och teammedlemar. Det är allt, det finns ingen roll som utvecklare, ingen roll som kravare och ingen roll som testare alla är bara teammedlemmar och skall leverera en fungerade programvara så ofta som möjligt. Detta ställer annolunda krav på teammedlemmarna gentemot ett klassiskt vattenfallsprojekt, alla teammedlemmar måste bidra till teamets framgång som är att leverera en fungerade programvara ofta.

Med detta i sinne är det lätt att förstå att teamet och teammedlemmarna måste känna sig ansvar iga för att leverara en bra produkt. Det går inte att någon kodar, någon testar och någon kravar. För den som kodar kommer inte ta ansvaret för de buggar som test missar och som kommer ut i produktionen. Det är ett teamansvar att leverera kvalité och det är teamet som skall bestämma om produkten har tillräcklig hög kvalité.

Viktigt att bidra till fungerade programvara

Så nu var frågan hur kan jag bidra till att teamet kan leverera en fungeranade produkt ofta, så att vi uppnår en stor framgång. Jag kunde ju ta på mig rollen som testare och vara den som utför funktions- och systemtester, dock skulle jag bryta mot rollerna i Scrum.

Jag anser att i ett scrumteam är det viktigt att alla känner ansvar, och om jag ’testare’  tar på mig rollen som kvalitetskontrollant kommer jag att få bära hundhuvud när någon allvarlig bugg upptäcks ute i produktionen. För att undvika detta är det viktigt att hela teamet är med och testar.

Det som jag gjorde i mitt projekt, när vi byggde en relese kandidat, var att tafram ett antal test charters och körde exploratory testing. Detta var självklart timebox och tiden var en timme. Denna session kallades för DET, Developers Exploratory Testing och kommer att beskrivas mer i detalj i kommande artiklar.

Eftersom hela teamet var med och testade kunde hela teamet ta beslutet om produkten höll tillräcklig hög kvalité för att släppas till produktägaren. – Kan vi vara stolta över den produkt som vi har byggt?

Detta gjorde också att teamet fick stå till svars för buggar som inte hittades i test men i produktionen.

Automatiserade tester – en viktig del i scrum

I teamet som jag var med i skrev utvecklarna de automatiserad integrationstesterna och unittester. Eftersom utvecklarna var med och testade så är jag också tvungen till att bidra till dessa tester. Då jag har ringa kunskap i Junit men stora kunskaper i testning kunde jag bidra genom att öka testcoverage med avseende på olika parameterkombinationer.

Ett naturligt steg blev att komplettera dessa tester och att skriva testscenarios innan den nya story hade på börjats. Den notation som jag använde när jag skrev mina testscenarios används inom BDD, Behaviour Driven Development, och kallas för Gherkin.

Gherkin-notation är skriven på formen Given – When – Then och ger en bra och enkel kontroll på testcoverage på en story. För att få en spårbarhet mellan mina testscenarios som är skrivna i ett textdokument och de automatiserade tester så användes ett verktyg som kallas för SPOCK. När testern var implementerade visste jag att vi har en bra automatiserad grund som täcker de vanligaste fallen och att vi täckte in viktiga krav. Detta gjorde att vi kunde ha ett annat fokus på våra DET sessions.

Den kontinuerliga testning under sprinten

Under själva sprinten sker testning kontinuerligt och varje story testas så fort den är färdig utvecklad. Detta sättet att arbeta kräver att jag som ’testare’ kan bygga och deploya för att vara delaktig i utvecklingen av produkten. Dessa uppgifter brukar vanligtvis vara utvecklaruppgifter, genom att lära sig traditionella utvecklaruppgifter kan vi som team ta ett gemensamt ansvar för att leverera en bra produkt.

Scrum är inte utvecklarcentrerad – Scrum är teamcentrerad

När jag diskuterar agilutveckling med olika testare brukar många testare säga att alla agila processer är utvecklarkoncentrerade [4] att all fokus ligger på hur man utvecklar produkten och ingen fokus på testningen av produkten. I den frågan är jag inte beredd att hålla med kritikerna. En av de tolv punkterna var ju att leverera en fungerande programvara vilket är ett tydlig tecken på att testningen ingår i det agila tänket.

Problemet med test är att vi kör på i våra invanda hjulspår, skriver våra dokument som vi paketerar i ”scrum-processen”, gör precis som vi gjorde innan och vågar inte tänka nytt, vi kräver inte vår plats i rummet. Vi måste vinna utvecklarnas respekt, lära oss nya tekniker, vi måste vara med där det händer. Om utvecklarna inte bjuder in oss, så våldgästar vi dem.

Genom engagemang och ’commitment’ till att vara med och skapa en applikation av högsta kvalité vann jag respekt hos utvecklarna.

About Henrik Andersson

Henrik Andersson
Jayway

Henrik Andersson från Jayway – Test, f.d. Testway, har sedan 1999 engagerat sig inom testning och kvalité. Under de senaste åren har intresset för testningen blivit ännu starkare och då framför allt inom Exploratory Testing och Session Based Test Management, testning inom Agila projekt och teknisk krävande testning.