Fem typer av testautomatiseringslösningar som är dömda att misslyckas

Väldigt många organisationer har ökad automation bland sina strategiska mål. Och en av de saker som gärna automatiseras är testgenomförandet. Efter att ha jobbat med testautomation i ett stort antal projekt går det att se ett mönster på vilka typer av testautomatiseringsinitiativ som närmast ofelbart kommer att misslyckas. Jörgen Damberg - en av Sveriges mest erfarna experter inom testautomatisering och kursledare för Zington Academy har listat fem typer av testautomation som på förhand kommer att misslyckas.

1. Fel testautomatiseringsverktyg + lågt system-mandat

En testautomation är på sätt och vis ett separat system med massor av beroenden till systemet under test. Antalet beroenden är enormt om automationen inkluderar handgrepp i GUI, men även på API:er som brukar ha åtskilliga end-points. En förutsättning för en uppskattad testautomation är att den är snabbt anpassad till förändringar - och allra helst inte reaktivt utan proaktivt.

Det finns organisationer som har tredjeparts-produkter, system utvecklade/förvaltade av outsourcing-partners eller liknande. De tycker att dessa ingår i så viktiga verksamhetsflöden att de vill automatisera tester på dem. Ibland kan detta faktiskt vara en bra idé, men om ett testautomatiseringsverktyg används som implementerar testfall på ett teknologiberoende sätt kommer det skapa problem inom några år när den externa partnern genomför ett tekniksprång.

2. System med låg uppdateringsfrekvens

Testautomation bygger på att testförfarandet beskrivs så noga att till och med en dator kan utföra testerna. Även med abstraktionshjälpmedel som specification-by-example och liknande behövs (ännu så länge, heja AI) det beskrivas exakt vad som ska hända i ett testfall på ett sätt som inte behövs för människor. Människor klarar att ta sig fram även i fragmentariska och förlegade testinstruktioner på ett sätt som datorer inte klarar.

Om testerna körs sällan blir anpassningarna för förändringar stora i förhållande till värdet av testautomatiseringen, och det ska mycket till för att känslan av att få igen sina ansträngningar ska uppstå. Det är ju testgenomförandet som är automatiserat. Om testgenomförandet är en väldigt liten del av testarbetet kan det vara mycket mer värdefullt att fokusera på andra förbättringsområden. Kanske gör dessa andra förbättringar att testautomatisering blir aktuellt i ett senare läge.

En av de allra största fördelarna med Continuous Integration är att det blir ett naturligt fokus på snabb feedback och ofta kommer det med ett uttalat team-ansvar. Dessutom blir det då naturligt att lägga in testautomation som Definition-of-Done-kriteria, vilket tydliggör både utvecklings- och underhållsfrågan.

3. Testautomation som inte förankras med testintressenterna

Det är inte ovanligt att en testautomatisering tas fram av personer med ganska fria tyglar, för att sedan förvaltas av helt andra människor. Det är inte nödvändigtvis ett fel upplägg, tvärt om så kan det vara ett bra sätt att få med sig erfarenhet nog för att undvika vanliga fallgropar. Det blir problematiskt först om en testautomation tas fram som inte tar hänsyn till arbetssätt och kompetens hos de som förväntas förvalta denna.

En annan besläktad fallgrop är om det är högnivåtester (systemtester eller liknande) som rapporterar testutfall på ett tekniskt sätt så att testledare, projektledare, systemägare och andra intressenter inte kan ta till sig denna. I värsta fall innebär detta dessutom dubbelarbete i form av att det ändå testas manuellt.

Att ta fram en lösning tillsammans genom workshop är en start på förankring, men det gäller även att se till att inte fel personer behöver drabbas av information av typen NullPointerException, men att rätt personer istället får denna information så fort som möjligt.

4. Juniora utvecklare som automatiserar

Det är inte sällsynt att se att utvecklingen av testautomatiseringen har lägre prioritet än utvecklingen av själva systemet under test. Det är ofta sunt att ifrågasätta den prioriteringen. En följd av prioriteringen är att det är de mer juniora utvecklarna som hamnar med testautomatiseringen. En gemensam nämnare för samtliga testautomatiseringar som överges är att det är för att underhållet av dem överstiger det upplevda värdet av dem, och det enda sättet att hålla nere underhållet är välstrukturerade och välgenomtänkta tester.

En testautomatiserare är nästan alltid sin egen arkitekt. Kraven på god lösningsarkitektur är enorma, eftersom minsta felsteg bygger underhållsbehov som gör testautomationen värdelös. Dessutom är det en av de mest kommunikationskrävande mjukvaruutvecklingsprojekt som finns. Det bygger på alla testnivåer över enhetstestnivå, på att man kommunicerar med verksamhet, utvecklare, testledare, systemägare och styrgrupper.

Att sätta en junior person på detta är dömt att bli så sub-optimalt att testautomatiseringen överges och dessutom till en kostnad som avskräcker för nya automationsförsök.

5. One-man-show-automatisering

Ett av de största problemen med testautomatisering är nog att det är så vansinnigt givande och kul. De första testfallen kommer lätt på plats det fortsätts ivrigt vidare. Trots alla ansträngningar att kontinuerligt refaktorera koden för underhållbarhet blir den med tiden allt mer komplex och personberoende. Så fort en testautomation blir personberoende är den i fara. Det räcker att den personen blir sjuk så kan det bli tufft att komma ikapp med underhållet av testautomatiseringen, och en testautomatisering med eftersatt underhåll litar ingen på. Om personen skulle sluta kan det rycka undan mattan helt, eftersom ingen hand-over till en ersättare kan få med den omhuldande attityden som kommer av att något har värkt fram under lång tid.

Zington håller kurser i praktiskt hållbar testautomation. Är du intresserad av att veta mer, och att lära dig att bygga klok testautomatisering, kontakta gärna Zington.