Väldigt många organisationer har ökad automation bland sina strategiska mål. En av de saker som gärna automatiseras är testgenomförandet.
Efter att ha jobbat med testautomation i flera tjog projekt går det att se ett mönster på vilka typer av testautomatiseringsinitiativ som närmast ofelbart kommer att misslyckas.
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.
Ibland träffar man på 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 man då försöker använda ett testautomatiseringsverktyg som implementerar testfall på ett teknologiberoende sätt kommer man att få problem inom några år när den externa partnern genomför ett tekniksprång.
Testautomation bygger på att man beskriver testförfarandet så noga att till och med en dator kan utföra testerna. Även med abstraktionshjälpmedel som specification-by-example och liknande behöver man (ännu så länge, heja AI) under huven beskriva 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 man ska känna att man får igen sina ansträngningar. 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 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.
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 man tar fram en testautomation 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 workshoppa fram en lösning tillsammans ä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.
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. Den prioriteringen får också till följd 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.
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 och man fortsätter 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.