Gör dig av med dina manuella tester

En av de viktigaste principerna i Scrum är att systemet byggs i små, inkrementella leveranser, där systemet vid varje sprint avslut kan driftsättas om kunden vill det. I agila projekt är därför testningen inte indelad i en separat fas som körs i slutet av leveransen, utan testningen sker kontinuerligt i varje sprint.

Team som förlitar sig på manuella tester inser snart att det är svårt att köra korta sprintar där det krävs omfattande manuella tester i varje sprint. Teamet kommer också att inse att om man inte tar tag i problemet lär situationen bli värre i nästa sprint, och i nästa…

Mike Cohn skriver om detta i sin blog och kallar det för projektets ”Manaul Test Technical Debt”.  Projektet har en sk teknisk skuld, d.v.s det finns en kostnad relaterad till att inte göra sig av med de manuella testerna. Lösningen är att automatisera testerna, men detta kan vara en minst sagt omfattande uppgift om man sedan länge har kört manuella tester.

Team i denna situation kan enligt Mike Cohn hantera problemet i tre steg:

1. Stop bleeding
2. Stay current
3. Catch up

Det första steget går ut på att få kontroll över situationen och se till att man kan behålla sprintlängden och samtidigt genomföra testerna inom sprinten. Börja med att identifiera de tester som tar längst tid och är lättast att automatisera. Fundera även på om det finns andra testaktiviteter som tar lång tid och går att automatisera, till exempel installation i testmiljö eller konfigurering av testdata.

I denna fas bör teamet även definiera en teststrategi om det inte redan finns en sådan. Syftet med en teststrategi är att göra ett antal antaganden om vilken typ av tester man ska ha och hur man ska exekvera dem. Målet är att säkerställa en önskad kvalitetsnivå i systemet och samtidigt minimera den tid det tar att testa systemet.

När teamet har effektiviserat de manuella testerna och börjat automatisera vissa enkla tester, är det dax att gå vidare till nästa steg. För närvarande inför vi nya manuella tester i varje sprint, men vi klarar av att köra dessa inom sprinten eftersom vi har effektiviserat testprocessen och automatiserat de tester som tar längst tid. Nästa steg är att skriva automatiserade tester för all ny funktionalitet som levereras i sprinten. När man gör detta ökar inte den tekniska skulden längre, men den minskar inte heller.

Till slut kan teamet gå in i den sista fasen och det är att börja automatisera de återstående testerna. Börja att automatisera de tester som ger störst nytta i förhållande till den tid det tar. Följande bild speglar omfattningen av att automatisera olika typer av tester.

Källa: Acceptance test engineering guide

Enhetstester syftar till att verifiera en begränsad och isolerad kodlogik, där testet ersätter ”externa” beroenden som till exempel SharePoint eller en databas. Enhetstester skrivs av utvecklare och körs i ett testramverk, som till exempel Microsoft Visual Studio Team System eller NUnit. Men det krävs en hel del att införa enhetstester i ett befintligt system, och det beror dels på systemets arkitektur men även den kompetens och motivation som finns inom teamet.

Integrationstester är programmatiska tester som skrivs av utvecklare eller testare, men som till skillnad från enhetstester inte körs isolerade. Syftet med integrationstester är att verifiera att integrationen mellan olika lager och komponenter fungerar. Jämfört med enhetstester är omfattningen något mindre men och andra sidan ökar komplexiteten i testerna eftersom vi måste återställa tillståndet i applikationen efter varje test.

Acceptanstester (även systemtester) representerar ett realistiskt användarscenario i applikationen som helhet. Dessa tester verifierar att applikationen fungerar enligt användarens krav och går ut på att testa systemets användbarhet och funktionalitet. Acceptanstesterna kan automatiseras genom att programmatiskt simulera ett användarscenario. Det finns en uppsjö av verktyg för att göra detta, till exempel Microsoft Visual Studio Team System Webtest eller open-source verktyget Selenium.

I ett befintligt system är det sannolikt enklast att automatisera systemtesterna. Integrationstester och enhetstester kräver båda att systemet följer designmönster som gör det enkelt att skriva programmatiska tester. En viktig princip är att affärslogiken är separerad från UI och infrastrukturrelaterat kod och att man använder standardiserade UI-komponenter och ramverksbaserade lösningar för persistens (OR-mapper), chachning, loggning, validering etc. Teamet kan då fokusera på att skriva tester för en begränsad del av applikationen, och den mest väsentliga delen, nämligen hjärtat i systemet, affärslagret.

Men du bör inte enbart förlita dig till systemtester eftersom det är svårt att skriva tester för alla möjliga scenarier på denna nivå. Det kräver att varje metod och komponent testas var för sig. Enhetstester i kombination med integrationstester, är i längden det mest kostnadseffektiva sättet att verifiera systemet och identifiera eventuella buggar.