Regressionstestning

När jag håller agil test utbildningar så diskuterar vi mycket runt regressionstest och den problematik som finns runt det ständigt växande regressionstestberget som uppstår i iterativ utveckling. Testautomatisering är det naturliga angreppssättet för att lösa denna problematik och någonting som jag naturlig förespråkar och brinner för (Jag ansvarar ju för Konsultbolag1s Testautomatiserings team) . Men det räcker ju inte med automatisering, en hel del måste ändå testas manuellt.

Eftersom jag oftast inte använder mig av detaljerade testfall när jag testar i ett Scrum-team, definierar jag INTE manuell regressionstestning som en omexekvering av testfall för redan befintlig funktionalitet. Utan som en omverifiering och omvalidering av redan befintlig funktionalitet.

Jag brukar förutspråka att dessa utforskande tester görs parvis. Detta för att det gör verifieringen mer objektivt och därmed ökar förtroendet för utfallet av testerna. De parvisa testerna främjar dessutom kunskapsöverföring och är ett utmärkt sätt att ”lära upp” nya teammedlemmar på systemet. För att göra testningen mera varierad och för att öka möjligheten till kunskapsspridningen så tycker jag paren bör varieras så ofta som möjligt.

Regressionstestet fortsätter tills paret har slut på testidéer OCH är nöjda med testtäckningen. Om paret får slut på testidéer innan de är nöjda med testtäckningen så delar de på sig och parar ihop sig med andra teammedlemmar för att få nya friska idéer. Naturligtvis kan inte 100% täckning uppnås, och det finns inget stensäkert sätt att visa hur heltäckande testerna egentligen är. Men detta tillvägagångssätt skapar  mer kreativitet och variation än skriptad regressionstestning.