Flödesschema för testautomatisering

2022-04-21

Ofta får jag frågan om när det är värt att sätta i gång med testautomatisering. Jag har gjort några tjog olika utvärderingar för att hjälpa team eller hela organisationer identifiera testautomatiseringsapproach eller om de är redo för testautomatisering. I ett försök att vara pedagogisk producerade jag ett Flödesschema för att hjälpa organisationer identifiera testautomatiseringskandidater.

En påminnelse: Detta är en modell. Alla modeller är per definition en förenkling av verkligheten. Detta måste verkligen understrykas här. Det kan finnas mängder av randfall där testautomatisering ändå kan vara relevant. Mer om detta under själva Flödesschemat.

Under något decennium har jag underhållit och byggt på en Checklista för testautomatiseringsinförande. Den har dock varit svår att förmedla till andra eftersom den i mångt och mycket bygger på att jag vet vad som döljer sig bakom varje delpunkt. Nedanstående schema är ett försök att visualisera några av huvudpunkterna i denna checklista (som också existerar som mer formell Excel med ROI-beräkningar).

Flödesschema för när testautomatisering är relevant att komma igång med.
Flödesschema för när det är relevant att initiera testautomatisering

Värt att notera är att det kan finnas speciella förutsättningar för flera av dessa flöden, och att det då kan bli aktuellt att införa testautomatisering även om detta schema skulle påvisa annat. Detta schema är blott att se som en ledstång för den osäkre. Den erfarne och rutinerade kan se bortom detta.

Några väntade invändningar

Detta måste väl bara gälla tester ovanför enhetstestnivån?

Nej.

Men de olika delstegen underlättas såklart av att man har mindre kod att testa, och mindre miljöberoenden, för varje testfall.

Det finns ju skriptfria testautomatiseringsverktyg!

Det är lätt att invända att det ju finns skriptfria testautomatiseringsverktyg, och det stämmer. Trots leverantörernas yrkanden på att vem som helst då kan skapa testautomatisering är min erfarenhet att det måste det vara väldigt speciella omständigheter för att få till fungerande testautomatisering.
Oavsett så behöver man tänka som en programmerare när man automatiserar tester, i procedurer, variabler och tillstånd. Det är också en stor fördel om den som ansvarar för att ta fram och förvalta en testautomatisering är tekniskt bevandrad.

Varför just releaser en gång i veckan? Och vilken typ av releaser?

Nja, där klämde jag bara till med en tidsrymd. Det viktiga är att tänka på hur ofta man tänker sig få värde av att exekvera sina tester. Jag möter ibland team som vill automatisera tester för inköpta system som kommer med nya relaser en gång i halvåret. Det kommer förmodligen att vara ändringar i den releasen, men man kan inte få detaljinformation om dessa ändringar i förväg så att man kan uppdatera testerna innan själva testexekveringen, så första gången efter ny release så exekverar man testerna för att se hur testautomatiseringen behöver uppdateras. Därefter exekverar man många gånger medan man uppdaterar testerna - för att se så att uppdateringarna blir rätt. Det konsumerar mycket testdata och blir väldigt tidsödande. Ju oftare man tänker sig exekvera testerna, desto mindre underhåll är det varje gång.

Men API-tester då?

Detsamma gäller dessa, men vissa saker - som t.ex. underhållet, blir väldigt mycket enklare.

Ett litet undantag är att det faktiskt finns en del tillgängliga verktyg där man inte behöver ha programmeringskunnande för att testautomatisera API-tester, som t.ex. ReadyAPI eller Postman. Det hjälper såklart om man är någorlunda teknisk så att man förstår vad alla konfigurationsmöjligheter gör.

Testautomatisering är en sådan specialistkunskap så vi har en central organisationsfunktion för det

Det fungerar inte.

Ingen blir nöjd. Feedback-looparna blir enormt långa och testautomatiseringen väldigt reaktiv.
Verktygen blir stora och otympliga Enterprise-verktyg eftersom det bara är de som kan hantera alla möjliga typer av tekniska miljöer. Dessa verktyg kräver ännu mycket mer av sina användare, och användarna kommer längre ifrån systemen de ska testa - vilket i sin tur gör testdatasituationen krångligare. Den mesta tiden kommer att gå åt till väntan på externa parter för behörigheter, tillrättaläggande av testdata, svar på frågor om tolkning av testfall o.s.v.

Mer läsning om testautomatisering

Är du mer intresserad av att sätta dig in i testautomatisering rekommenderas följande länkar:

The test automation landscape
Kursmaterial för testautomatisering och teknisk testare
Laborationer för att lära sig testautomatisering
Checklista för testautomatiseringsinförande