Hannes Lindblom

Vilken form har testautomatisering?

2018-01-17 Blogg Test Läst 914 gånger

Vilken form har vår galax? Vilken form har jorden? Vilken form har de flesta varningsmärkena? Vilken form har godisfigurerna i zoo? Det här är några förslag Google ger på frasen “vilken form har….”. Viktiga frågor allihop förstås, men i min värld är en minst lika relevant fråga: “Vilken form har testautomatisering?” En fråga som har gäckat mig länge. Vid första anblick kan det låta som en absurd frågeställning, vadå form? Det som menas i det här fallet är hur testerna (eller checkarna som många föredrar att kalla det) fördelas över de olika testnivåerna (enhetstest, integrationstest, end-to-end, etc). För några år sedan framhävde jag själv pyramidformen som en bra utgångspunkt för att bygga en stabil och värdefull lösning. Hade jag skrivit om artikeln idag hade jag definitivt tryckt hårdare på pyramiden som en möjlig modell bland flera, mer lämplig i vissa sammanhang än andra. Varför har jag då reviderat min åsikt i frågan? För att förstå bakgrunden bättre föreslår jag att vi backar bandet lite.

I testautomatiseringens tidiga år var entusiasmen hög och målsättningen var klar: att automatisera bort så kallad manuell testning. Typiskt gjordes detta genom att köpa in färdiga verktyg och utan större eftertanke koda ihop ett antal GUI-tester som rakt av försökte replikera de existerande testfall som kördes av testarna. Dessa initiativ kraschlandade ett efter ett på grund av alltför dyrt underhåll och dålig stabilitet. Ur askan från dessa kraschade projekt föddes tankar om att bygga mer balanserade automatiseringslösningar, det var här automatiseringspyramiden etablerades.

Nu skulle man få fason på automatiseringsinsatserna genom att skapa färre end-to-end-tester, lite fler integrationstester och ytterligare fler enhetstester. Speciellt inom den agila världen där teamen ofta själva ägde hela teststacken tog detta fart och stora spelare som Google har sedan dess hängt på tåget.

Automatiseringspyramiden stod dock inte över all kritik. Den fick direkt kritik att den fokuserade på antal tester istället för att täcka risk. Även en del indirekt kritik dök upp för att pyramiden missbrukades till att användas i var och varje situation utan lite eftertanke, eller för att många team blandade ihop end-to-end-tester med GUI-tester och andra testtyper. Helt klart var inte alla överens om pyramidens förträfflighet.  De som sysslade med mobil testning hävdade dessutom att pyramiden såg helt annorlunda ut i deras kontext. Och i ett ytterligare slag mot en enad automatiseringsvärld lades det nyligen upp ett inlägg på Twitters blog där man deklarerade att man framgångsrikt experimenterat med att skippa enhetstester till förmån för tester på feature-nivå.

Så när vi nu gått in i 2018 känns fältet mer splittrat än någonsin. Ska man satsa på enhetstester, integrationstester eller end-to-end-tester? Ska man bygga en pyramid, eller ett timglas, en glasstrut eller kanske någon helt annan form? Alla verkar ju ha sina för- och nackdelar och ingen enighet verkar råda vilka som är bäst. Och däri någonstans tror jag att sanningen ligger. Personligen hoppas jag att 2018 blir året då vi kan enas om att det inte finns en lösning som passar alla, att sammanhanget spelar en stor roll och att det därför inte är klokt att kopiera andras upplägg rakt av, även om det råkar vara ett coolt namn i branschen.

Dela artikeln