Agila proaktiv testning och traditionell testexpertis

För en testare i ett agilt team, upptagen med ett oändligt antal testaktiviteter, finns det alltid en risk att bli alltför utvecklingsorienterad. Trots att man blir avbruten med nya testreleaser varje dag så är det fortfarande viktigt att fokusera på helheten, testtäckning och kravuppfyllnad. Mitt upp i det hela, när man frågar sig hur en funktion verkligen ska fungera, så är det förförande enkelt att ta till sig utvecklarens uppfattning. Resultatet blir att en oerfaren testare börjar fokusera på ”vad som finns” när ”vad som saknas” förstås är lika viktigt. Det är nödvändigt att den agila testaren ibland tar några steg tillbaka och tänker på testaktiviteterna utifrån testtäckning, testscenarier och testidéer. Att kombinera teknisk proaktiv testning med kravbaserade traditionella tester, utan att låta någon av dessa stå tillbaka, är en riktig utmaning för den agile testaren.

Det första som sker när ett agilt team startar en ny utvecklingscykel är att den aktuella kravmassan bryts ner till underuppgifter inför utveckling. Det är väldigt viktigt att testarna är med på dessa aktiviteter. Att bryta ner krav till utvecklingsuppgifter hjälper testaren att förstå funktionerna och låter testaren bidra med kunskap om testbarhet, användbarhet och allmän systemkunskap. Vissa krav kan resultera i rena testaktiviteter. Exempel är icke-funktionella tester (såsom prestanda, säkerhet, användbarhet, förvaltningsbarhet et.c.) eller rena testaktiveter (t.ex. hantera testmiljöer och arbeta med regressionstester). Testuppgifterna utförs och följs upp precis som vanliga utvecklingsaktivteter. Kom bara ihåg att uppmärksamma tidsaspekten så att testarna har tillräckligt med tid att utföra dessa uppgifter och samtidigt kunna genomföra ordinarie testaktiviteter. Det är viktigt att införliva testaktiviteterna i mängden av uppgifter i utvecklingscykeln, likväl som rena utvecklingsaktiviteter.

I ett agilt team är det oftast fråga om ett par dagar innan utvecklarna har funktioner implementerade och klara för test. Än kan man inte förvänta sig att alla funktioner har grafiskt gränssnitt eller är fullständigt integrerade. Till en början får man som testare oftast nöja sig med databasscheman, fristående funktionslogik och liknande. Med lite teknisk systemkunskap bör det inte vara något större problem att testa småbitar av funktioner såsom de levereras. Ibland kan det vara en bra idé att låta testare och utvecklare arbeta i par och nyttja varandras kunskaper för testning och utveckling. När det inte finns några nya funktioner att testa finns det fortfarande mycket att göra. Testare kan arbeta på nya testscenarier eller testidéer utifrån krav och annan tillgänglig information. Testmiljöer, testdata och testverktyg behöver sättas upp. Kanske finns det testautomatisering som behöver utföras eller nya testmetoder och verktyg som är intressanta och behöver utvärderas? Det är viktigt att testarna kan bidra med allt detta och samtidigt fokusera på proaktiv testning.

En vanlig missuppfattning är att samtliga i ett agilt team ska jobba med utveckling och göra ungefär samma saker. Det är förstås inte sant. Alla har ett gemensamt ansvar för utveckling och kvalité men man kan bidra till det övergripande målet utifrån olika roller. Ifall det finns någon i teamet med ansvar för testplanering, testrapportering, testmiljöer/-verktyg/-data (formellt eller informellt), så är det förmodligen en testledare. Testledaren hör hemma i det agila teamet men eftersom det knappast finns uppgifter för en testledare på heltid så funkar det jättebra att komplettera med vanligt testarbete . Det behövs någon som har övergripande kontroll över vilka tester som görs, systemets kvalité och vidareutvecklar testarbetet. Ytterst är det testledarens ansvar att testarbetet skrider framåt. Det är också viktigt att testningen sker så effektivt som möjligt och alltid sträva efter förbättringar, antingen i testprocessen eller med hjälp av förbättrat tekniskt stöd.

Med alla utvecklingsaktiviteter levererade och alla delfunktioner individuellt testade, finns det en skaplig chans att också den kompletta levererade funktionen kommer att fungera väl. Det är nu som testaren måste byta fokus och verkligen verifiera funktionen utifrån krav, användarfall, systemets kontext eller annan tillgänglig information. Ett bra sätt att göra detta är att utgå från skrivna testscenarier eller checklistor. Testscenarier behöver inte vara särskilt detaljerade så länge som de hjälper testaren att se helheten och jämföra med vad som levererats. Nu testas hela användarfall snarare än enskilda små funktioner. Väl beprövade traditionella testtekniker är viktiga i vad som liknar ett traditionell systemtest, fast i kondenserad form.

Utvecklingscykeln avslutas vanligen med en sprintdemo, ”go/no go”-möte eller liknande. Där beslutas det om implementerade funktioner är tillräckligt bra för release. Testarna demonstrerar de viktigaste funktionerna och kravställarna uppmuntras att pröva egna testidéer. Testarna delar med sig av sin syn på systemets kvalité och det bestäms ifall systemet är tillräckligt bra för en release. En release kan sen göras till acceptanstestmiljö, för ytterligare tester utanför teamet, eller direkt till produktion.

1. Six development activities are being developed.	2. Four of them are finished and some successfully tested.
3. The rest of them are finished and some more successfully tested.	4. When all of them are finished and individually tested, chances are that the whole test case will be successful even though it has not been run in its full extent before.