Att lyckas med Testautomatisering

Att det kan vara av fördel att automatisera tester tror jag att de flesta är överens om. Det är dock vanligt att denna typ av initiativ misslyckas av en eller annan anledning. Fallgroparna som gör att automatiseringsprojekt misslyckas är många och de är väldigt lätta att falla i, om man inte vet vad man ska undvika.

De vanligaste fallgroparna kan delas in i sex olika kategorier:

  • Engagemang
  • Förberedelser
  • Val av verktyg
  • Tekniska svårigheter
  • Arkitektur och ramverk
  • Testdata

Det som är positivt med dessa fallgropar är att de är möjliga att komma runt bara man är medveten om dem och drar lärdom av sina tidigare erfarenheter.
I den här artikeln redogör vi för några av de vanligaste orsakerna till misslyckande automatiseringssatsningar samt hur man utifrån vår erfarenhet bör gå tillväga för att undvika dem.

Engagemang

Att automatisera tester är inget du bör försöka dig på att göra lite ”vid sidan av” utan det skall ses som vilket utvecklingsprojekt som helst som man måste avdela resurser till. Nyckeln till framgång ligger i att förutom testare även få med ledning, utvecklare, verksamhetspersoner och kravställare på tåget. Det kommer även leda till att man får större acceptans för de krav som testautomatisering ställer på organisationen.

Att utveckla automatiserade tester tar tid och det är vanligt att organisationen tappar intresset och tycker att det är en onödig aktivitet som bara tar tid och resurser i anspråk, resurser som bättre kunde användas till annat. Var därför noga med att marknadsföra dina framsteg och automatiseringens positiva effekter.  Av samma anledning är det också viktigt att med omsorg välja vilka tester som först skall automatiseras. Börja med att plocka ”några lågt hängande frukter” för att på så sätt få en positiv attityd runt satsningen på automatisering. Detta säkerställer även att automatiseringsprojektet inte ses som ett hot utan som en tillgång som hela organisationen kan ha nytta av

Förberedelser

Innan du väljer ramverk och verktyg ska du se till att en förstudie genomförs för att identifiera behoven och utifrån det välja det verktyg som passar bäst. Några av frågorna du bör ställa under en sådan förstudie är:

  • Vad är syftet med att automatisera?
  • Vilka effektmål förväntas uppnås?
  • Vilken typ av tester skall automatiseras?
  • Finns det stöd för automatisering inbyggt i applikationen som skall testas. Om inte, går det att bygga in?
  • Vilken testmetodik lämpar sig bäst för applikationen t.ex. modellbaserat eller nyckelordsdrivet?

Gör även en ordentlig kostnads-intäktsanalys som visar om och när en satsning blir lönsam i reda pengar. Denna kostnads-intäktsanalys presenteras sedan tillsamman med förväntade effekter för ledningen. Eventuellt kommer ni fram till att automatiserade tester inte ger besparingar i någon större utsträckning, men att det finns andra parametrar som absolut kan motivera en sådan satsning. Några exempel på sådana fördelar är:

  • Att kunna fatta väl underbyggda beslut inför en release/produktionssättning.
  • Ge större trygghet till att våga göra större ändringar i koden.
  • Att kunna testa och få återkoppling om resultatet efter varje bygge.
  • Att kunna testa med stor mängd olika testdata för att öka testtäckningen.

 

Val av verktyg

Det finns ett stort utbud av verktyg att välja bland, både kostnadsfria(”Open source”) och kommersiella verktyg. Open source har ju fördelen att de är om inte helt gratis så åtminstone väldigt billiga. Betalverktygen å sin sida kommer i de flesta fall med ett färdigt ramverk samt ger möjlighet till att få väldigt bra support. Utvärdera olika alternativ och hitta det verktyg som lämpar sig bäst för din applikation/produkt och för din organisation.

Innan du beslutar dig för vilket verktyg du vill använda se till att få tillgång till utvärderingslicenser och genomför en ’Proof of concept’ för att säkerställa att verktyget ger tillräckligt stöd för applikationen som skall testas. Ett sådan ”Proof of Concept” kan till exempel vara att man väljer ut ett eller ett par representativa testfall som man provar att automatisera för att säkerställa att verktyget fungerar i praktiken och uppfyller ställda krav.

Försök att välja ett verktyg som stödjer ett vanligt förekommande script-/programmeringsspråk då det ökar möjligheterna att kunna söka på webben efter lösningar på eventuella problem samt att ta in extern hjälp ifall det skulle behövas.

Tekniska svårigheter

Det är vanligt att man förr eller senare stöter på problem med att automatisera någon eller några funktioner därför att stöd saknas antingen i verktyget alternativt i applikationen som skall automatiseras. Om skälet är att stöd saknas i verktyget beror möjligheten att påverka att stöd byggs in i framtida versioner på hur etablerat verktyget är. Har du valt ett väl etablerat testverktyg ökar dina möjligheter att påverka avsevärt. För att hantera situationer där stöd saknas i applikationen som ska automatiseras behöver du säkerställa att du har goda relationer med utvecklingsavdelningen och berörda beslutsfattare. Se till att bli involverad tidigt i de interna utvecklingsprojekten, redan i kravfasen, då har du störst möjligheter att påverka så att stöd för automatiserade tester implementeras. Det är betydligt enklare för utvecklarna att ta höjd för automatiseringsstöd från första början än det är att införa det i efterhand. Kommer du in sent med denna typ av krav är chansen att du får gehör för dina önskemål väldigt liten.

När du väl har valt vilket verktyg du vill använda, och betalat eventuella licensavgifter, är det lätt att lockas till att omgående försöka automatisera exempelvis samtliga regressionstestfall. Men sannolikheten att man lyckas göra allting rätt ifrån första början är inte så stor. Börja hellre med ett eller ett par pilotprojekt och välj ut en delmängd testfall för att representera merparten av applikationens funktionalitet.

Visar det sig att du har tagit några mindre bra beslut kring ramverket eller de automatiserade testfallens uppbyggnad så är misstagen betydligt enklare att rätta till inom ett pilotprojekt än om du hade automatiserat en stor mängd testfall på en gång.

Arkitektur och ramverk

Förändringar i applikationen gör att de automatiserade testerna med tiden slutar att fungera och i slutändan tar det mer tid att underhålla trasiga testfall än det från början tog att genomföra testerna manuellt.

För att minimera underhållsarbetet är det nödvändigt att skapa ett väl dokumenterat, genomtänkt och underhållsvänligt ramverk för dina tester. Var noga med att separera vad som testas och hur det testas i olika moduler. Vad som testas skall finnas i testfallen och hur det testas blir en del av ramverket som kör testfallen. Skapa robusta och återanvändbara funktioner med inbyggd felhantering som interagerar med din applikation.

Det är även fördelaktigt att lägga information om hur applikationen är uppbyggd och hur man navigerar mellan olika funktioner i en egen modul. På så vis blir det väldigt enkelt att utöka ramverket i takt med att applikationen utvecklas eller förändras utan att för den sakens skull behöva uppdatera samtliga befintliga testfall. Ta även hänsyn till om applikationen skall finnas tillgänglig på flera språk. I så fall kan det vara bra att skapa separata språkfiler som ramverket automatiskt hämtar aktuella textsträngar ifrån. Hör dig för med utvecklarna om vilka befintliga resurser i form av t.ex. lokaliseringsfiler eller liknande som finns att återanvända.

Att separera vad som testas och hur det testas ger även andra fördelar, då det möjliggör att låta testare eller verksamhetspersoner som inte har programmeringskunskaper att skapa automatiserade testfall. De tekniska aspekterna kring hur applikationen skall testas kan man då överlåta på personer med programmeringskunskap. Var dock noga med att vara tydlig med vilka verifieringspunkter ni som testare vill att den som utvecklar den bakomliggande koden skall implementera. Det är även viktigt att lägga mycket fokus på att granska och testa den kod som utvecklas främst för att identifiera testfall som felaktigt ger resultatet OK.

Försök att få med utvecklare i satsningen på automatisering. Det kommer göra att utvecklarnas medvetenhet ökar kring hur deras designbeslut påverkar de automatiserade testerna. Det möjliggör även att de som underhåller scripten kan bli förvarnade i god tid om ändringar som påverkar de automatiserade testerna.

Testdata

Om det är möjligt att skapa testdata dynamiskt och på förhand räkna ut vilket det förväntade resultatet är då testdatat används är det självklart att föredra. Är detta inte möjligt så kan ett alternativ vara att ha en separat testmiljö för de automatiserade testerna vilken man kan återställa till ett känt läge inför varje testomgång. I det senare fallet är det dock rekommenderat att ha versionshanterad testdata samt att ha god spårbarhet mellan testdata och de testfall där det används.

Sammanfattning

Vi på Konsultbolag1 vet att det är möjligt att lyckas med testautomatisering och följer man bara dessa enkla riktlinjer så är man en god bit på väg. Givetvis hänger möjligheterna till framgång till stor del på den applikation som skall automatiseras men finns viljan, engagemanget och kompetensen så finns det oftast även en väg. Om du har byggt upp din automatisering korrekt kan du till och med få hjälp av fler än programmerarna att skapa automatiserade testfall.

Nästa steg

Börja med att analysera vilka effektmål ni önskar uppnå med automatiserade tester. Då blir det enklare att avgöra vilken typ av tester som bör automatiseras samt om det är möjligt rent tekniskt. Det i sin tur möjliggör tydligare kravställning av testverktyget.

About Ted Lundqvist

Ted Lundqvist är konsult på Konsultbolag1 inom fokusområdet Testautomatisering. Han har närmare 15 års erfarenhet av test och kvalitetssäkring inom flera olika branscher. Ted har arbetat med såväl stora affärssystem som små inbäddade system, med allt ifrån test- och testledning till utvärdering och införande av testverktyg samt praktiskt arbete med testautomatisering.