Fallgropar med testautomatisering
Automatisering, tunt skivad
Det går inte att förneka att testautomatisering har revolutionerat programvarutestning. Och precis i rätt tid dessutom! I dagens värld av ultradistribuerade, containerbaserade tjänster som uppdateras kontinuerligt skulle meningsfull programvarutestning vara omöjlig utan den.
Vi har turen att ha så många sofistikerade verktyg för automatiserad testning till vårt förfogande. Och, vill jag tillägga, välutbildade QA-ingenjörer som kan använda dem till allas fördel i utvecklingsarbetet.
Av någon anledning ligger det dock i vår branschs natur att vanemässigt reducera sådana betydande kapacitetsökningar till trender, och dessa trender till meningslösa ordsallader och slagord som robotaktigt upprepas av högre chefer, förståsigpåare och konsulter som bara vill ha en ursäkt för att slippa tänka på problemet. Eller för att tjäna snabba pengar.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Så är det också med genombrotten inom testautomatisering, som snabbt har fångats in i den förenklade berättelsen: ”vi behöver bara automatisera all vår testning! Nu! Och alla våra testproblem kommer att vara lösta!”
Det är inte bara en fruktansvärd idé, även om den skulle föreslås av personer som försöker ta problemet på allvar och inte bara undvika det. Den är också skadlig eftersom det är en berättelse som, genom att stänga möjligheten att tänka djupt kring hur automatisering ska integreras i testinsatserna, säkerställer att den misslyckas. Det är orättvist mot alla människor (inklusive kunder) som är beroende av att den lyckas.
I detta avseende ärver testautomatisering helt enkelt ett särskilt fall av den allmänna inställning till SQA som förekommer hos dem som inte förstår det, och inte heller vill förstå det. Den behandlas som en massvara, inte som en komplex expertis. Det är därför personer inom QA fortsätter att höra från högre ledning: ”vi behöver bara mer QA!”, som om det någonstans fanns en programvarudelikatess där man kunde beställa det per kilo, tunt skivat.
Det är därför mantrat nu är: ”vi behöver bara mer automatisering!”, utan någon tanke på vad det faktiskt skulle innebära i samband med ert programvaruutvecklingsarbete. På så sätt göder denna diskurs organisationens dysfunktioner. Den löser dem inte.
Att försöka stå emot dessa trendiga tendenser direkt är som att försöka hindra solen från att gå upp. Eller, i det här fallet, gå ner. Det bästa motståndet är helt enkelt att nicka och le mot vicepresidenterna och konsulterna, gå tillbaka till era arbetsplatser och lista ut det rätta sättet att arbeta med automatisering, och sedan presentera idéerna som de briljanta resultaten av era chefers fantasi. Men ni har förmodligen redan lärt er den läxan i andra frågor.
Så låt oss göra det. Här är min lista över fallgroparna med att införa testautomatisering, och sätt att minska dem, så att automatiseringen kan uppfylla sitt betydande löfte i era egna testinsatser.
Automatiseringens omfattning
Den viktigaste frågan att besvara i början är var automatiserad testning ger bäst valuta för pengarna i era testinsatser. Om ni tar er tid att göra detta sparar det er många, många huvudvärksproblem längre fram.
Att besvara denna fråga handlar i grunden om hur mycket av testningen som behöver automatiseras och hur mycket som behöver förbli manuell. Det kan vara förvånande att höra för er som ständigt bombarderas av budskapet ”automatisera all testning!”. Men bry er inte om det nonsenset – de här personerna har ingen aning om vad de talar om.
Att automatisera all testning – förutsatt att det ens är möjligt – skulle vara ett fruktansvärt beslut som bara skulle kunna leda till katastrof för era testinsatser.
Det finns fantastiska saker som automatisering kan göra, men som manuell testning inte kan göra, eller åtminstone inte lika snabbt och upprepade gånger. Men det omvända gäller också. Det finns saker som endast manuell testning kan göra bra, och som automatisering inte kan göra. Vilka är dessa saker i respektive fall?
Där manuell testning utmärker sig framför automatiserad testning är helt enkelt den mänskliga faktorn. Fördelen med att ha en verklig människa som tålmodigt utför djupgående explorativ testning kan helt enkelt inte återskapas genom automatisering. Och jag talar inte bara om att upptäcka buggar.
Vem som helst kan hitta buggar. Kunder gör det gratis hela tiden. Värdet som en professionell QA-person tillför är den intuitiva känslan för hur man kan få en programvarudel att gå sönder, särskilt när det gäller att avgöra hur programvaran kan användas av kunder på sätt som den aldrig var utformad för att användas på, men ändå – ofta med katastrofala följder – kan användas på.
En annan fördel med manuell testning är att en manuell testare, efter att ha hittat en bugg, omedelbart kan börja fastställa dess omfattning och allvarlighetsgrad. Det vill säga, ringa in de testkontexter (operativsystem, arbetsflöden, interaktioner mellan tjänster och beroenden) där den specifikt uppstår, och de där den inte gör det.
Automatiserade testskript kan inte göra detta särskilt bra alls och ur en programvaruingenjörs perspektiv är detta verkligen den avgörande information som behövs för att diagnostisera och åtgärda en bugg. En buggrapport som helt enkelt säger ”jag gjorde det här och den här dåliga saken hände” är oanvändbar för dem.
Manuell testning är faktiskt mycket mer tidseffektiv när det gäller att tillhandahålla denna information och, eftersom den till sin natur är interaktiv och sker i stunden tillsammans med utvecklarna, ger den betydligt mer informationsrik återkoppling och analys av grundorsaken.
Ja, Virginia, manuell testning är inte alltid det minst effektiva och mest tidskrävande sättet att hitta, diagnostisera och åtgärda buggar samt validera (eller inte validera) deras korrigeringar.
Där automatisering däremot har en uppenbar fördel är vid kontinuerlig testning av drifttid och stabilitet—särskilt för distribuerade system. Detta är betydligt mer centralt nu med tanke på vår nuvarande utvecklingskontext med kontinuerlig integrering och distribution till distribuerade miljöer i realtid.
Automatisering är också effektivare vid det man skulle kunna kalla ”masstestning”, där man har en enorm matris med tusentals systemförhållanden och deras variabler som måste täckas för att se om någon av dem är helt trasig eller kommer att få systemet att krascha.
Den tumregel du bör använda för att vägleda dina beslut om var manuell respektive automatiserad testning ska prioriteras är denna:
Manuell testning föredras vanligtvis vid den inledande testningen av nya funktioner och möjligheter. Automatiserad testning är tydligt bäst för kontinuerlig generell regressionstestning samt för belastnings- och prestandatestning.
Under en produkts eller tjänsts livscykel bör testningen av samma funktion utvecklas från manuell till automatiserad. Det är ett kontinuum för funktionens livscykel. Det är inte en kinesisk mur som aldrig får överskridas, där ingen av sidorna behöver känna till vad som händer på den andra. Utgångspunkten bör vara att det som testas manuellt i dag med tiden ska övergå till automatiserad testning.
Kvalifikationer för automationsingenjörer
Det är kanske oundvikligt att de viktigaste kvalifikationerna man efterfrågar vid anställning av ingenjörer inom automatiserad testning är kandidaternas kompetensnivå inom (a) de automatiseringsverktyg som de förväntas använda och (b) de testspråk som används av dessa verktyg.
Men om det här är de enda kvalifikationerna du fokuserar på gör du ett stort misstag. De är nödvändiga, men knappast tillräckliga kvalifikationer för rollen som automationsingenjör.
Varför? Av den enkla anledningen att kunskap om hur man använder ett automatiseringsverktyg och hur man skapar skript i dess skriptspråk säger exakt ingenting om deras förståelse av kvalitetssäkring i sig.
Tyvärr ser jag nästan aldrig automationsingenjörer som har denna utbildning eller bakgrund. De anställs helt enkelt för att de är trollkarlar på skript, inte för att de har någon förmåga att utforma ett effektivt och diagnostiskt test.
Dessa kvalifikationer är faktiskt viktigare än erfarenhet av de automatiseringsverktyg och språk de kommer att använda. De kan enkelt lära sig detta vid behov. Men det tar mycket lång tid och kräver stora ansträngningar att utbilda någon i hur man utformar tester och tolkar deras resultat.
Det vore faktiskt bättre att ta en erfaren analytiker som du redan har och utbilda personen i de nödvändiga automatiseringsverktygen. Dessa automatiseringskunskaper är trots allt numera en handelsvara. Den intuition och insikt som en erfaren testare har är det däremot inte.
Att automatisera okunskap ger dig bara okunskap snabbare och mer konsekvent, och undergräver den effektivitet du förväntade dig av automatiserad testning.
Standarder för automationsdesign
Det är självklart att du, om du påbörjar ett storskaligt arbete med testautomatisering, först måste definiera allmänna standarder som all automatisering måste följa för att godkännas för användning i testning. Ändå verkar det, liksom med många självklarheter, finnas färre kloka huvuden än man kunde förvänta sig.
Här är vad dessa standarder bör omfatta.
Begriplighet
Ett av de frustrerande mysterierna inom programvaruutveckling är hur hantverksmässig den visar sig vara. Det är tyvärr inte alls ovanligt att en programvaruingenjör säger att hen inte kan åtgärda ett fel eftersom hen inte skrev koden där felet förekommer. Det är som om kod som skrivits av en annan ingenjör vore på ett främmande språk som hen inte förstår.
Detta är också, sorgligt nog, lika vanligt inom testautomatisering. Jag kan inte säga hur många gånger en QA-ingenjör har sagt till mig att hen inte vet hur man uppdaterar en del av testautomatiseringen för en större produktuppgradering eftersom hen inte skrev den och därför inte förstår, och inte kan förstå, den. Och ingenjören som skrev den lämnade företaget för två månader sedan.
Detta är ännu mindre acceptabelt när det gäller automatiserade testskript än när det gäller ny programkod som implementerar designlogik och inte bara får vissa steg att utföras. Ändå är det häpnadsväckande vanligt.
Detta innebär att du, innan du anställer ett dussin QA-ingenjörer och låter dem glatt producera hundratals automatiserade testskript, måste se till att du först har definierat och utbildat dem i allmänna begriplighetsstandarder.
Det måste vara ett krav att alla testskript är ömsesidigt begripliga för alla dina QA-ingenjörer, så att du inte till slut blir beroende av en enda, ofta tillfällig, resurs för att underhålla dem.
Definiera och tillämpa en gransknings- och godkännandeprocess för alla kandidater till automatiserade skript mot dessa standarder innan de får distribueras för testning.
Underhållbarhet
Underhållbarhet är nära kopplad till problemet med begriplighet, men de två är logiskt och operationellt separata. Ett testskript kan lätt förstås av testingenjörer som inte skrev det och ändå vara strukturerat på ett sådant sätt att det blir ett monster att uppdatera eller ändra.
Här är ett verkligt exempel.
Hos en av mina arbetsgivare förberedde vi testinsatsen för en uppgradering på mellannivå av deras flaggskeppsprodukt. Den var planerad för en lanseringscykel på fyra veckor, vilket faktiskt var rimligt i det här fallet.
När jag planerade den testinsats som krävdes insåg jag att vi också skulle behöva uppdatera det huvudsakliga automatiserade regressionstest-skriptet. När jag frågade den ledande QA-ingenjören hur lång tid uppdateringen skulle ta svarade han ”åtta veckor”. Dubbelt så lång tid som hela lanseringen! Även med hänsyn tagen till ingenjörssynden att överdriva uppskattningar var detta extremt.
Jag bad några andra testingenjörer att granska skriptet och uppskattningen. De var alla överens om att skriptet var skrivet på ett så klumpigt och ineffektivt sätt att det skulle krävas många veckors mödosamt omskrivningsarbete av hela skriptet för att uppdatera det inför nästa lansering, trots att uppdateringarna i sig inte innebar några grundläggande omskrivningar av produkten.
Den situationen var ett klassiskt exempel på en synd inom programvaruutveckling som teleporterats in i testutvecklingen. Det är dags att få slut på vansinnet.
Mitt råd här är identiskt med det jag gav ovan i frågan om begriplighet. Låt under inga omständigheter era QA-ingenjörer gömma sig i sina testutvecklingsgrottor och dyka upp en eller två veckor senare med något som kanske fungerar som ett test, men som kommer att vara en mardröm av meningslöst lidande att uppdatera i tid.
Inför standarder för möjligheten att uppdatera i tid och skapa en gransknings- och godkännandeprocess för att säkerställa att de följs. Detta kan enkelt integreras i samma arbete för att säkerställa begriplighet, så att allt kan ingå i samma granskningsprocess.
Era QA-ingenjörer är inte renässansmålare, och ni ber dem inte att måla om Sixtinska kapellet. Det borde inte ta en livstid.
Testroller och testautomatisering
Ett av de ineffektivitetsmönster som hindrar en smidig och fruktbar integrering av automatisering i hela er testinsats är det felaktiga antagandet att varje steg i den automatiserade testprocessen måste utföras inom själva automatiseringsgruppen.
Detta är ännu ett misstag. Även om det i det här fallet inte är helt uppenbart.
Automatiseringsingenjörer kommer förmodligen att vara de bäst betalda resurserna i ert team, så deras tid är dyrbar. Dessutom kommer mängden testskript som den gruppen måste skapa och kontinuerligt uppdatera bara att växa med tiden, medan er grupp av testingenjörer inte kommer att kunna växa i närheten av tillräckligt snabbt för att hålla jämna steg. Inte ens om ni arbetar för Google.
Det är därför operativt klokt att införa en arbetsfördelning mellan automatiseringsteamet och resten av teamet. Mer specifikt en uppdelning mellan de resurser som skapar och underhåller automatiserade skript och verktyg, och de som faktiskt kör de automatiserade testerna.
Det är uppenbart att de förstnämnda ansvarsområdena endast kan utföras av automatiseringsteamet självt. Det är trots allt därför de anställdes från början. Men detta gäller inte de sistnämnda.
Det finns ingen anledning till att analytiker inte också skulle kunna köra automatiserade tester på egen hand och tolka resultaten.
Mycket få människor tänker i dessa termer, men denna arbetsfördelning är helt logisk. För det första frigör den betydande mängder tid, så att automatiseringsingenjörerna kan fokusera på att skapa ny automatisering.
För det andra förstärker den kravet på begriplighet som definierades ovan. Om automatisering är central i er testinsats måste det vara lika centralt att alla i ert testteam, oavsett om de är automatiseringsingenjörer eller inte, ska kunna förstå och använda era automatiserade tester. Även manuella testare.
Ett sådant system för rollfördelning kommer kraftigt att öka flexibiliteten när det gäller resurser i hela ert QA-team och därför också skapa tids- och schemaläggningseffektivitet som annars inte skulle finnas.
Avslutande tankar
Att utveckla en robust kapacitet för automatiserade tester, enligt definitionen ovan, är helt enkelt en nödvändighet i dag. Man kan inte tala om professionell och effektiv QA utan den.
Ändå börjar många lysande äventyr med entusiasm och glädje, för att sedan sluta i nederlag när resan är över. Jag ser detta hända inom QA när det gäller testautomatisering i väldigt, väldigt många fall.
Problemet är att det är relativt lätt att kasta sig in i automatiserade tester. Det är dyrt, men åtminstone lätt att låtsas att man gör en insats. Automatiserade tester kan dock också vara en klippa där man, likt Wile E. Coyote i tecknade filmerna om Hjulben, tanklöst springer ut över kanten och faller så fort man besvärar sig med att titta ner.
Det måste förstås från början att testautomatisering har en livscykel. Varje testskript har en livscykel på månader, om inte år.
Det handlar inte bara om att skriva en mängd automatiserade testskript som uppfyller alla era behov för produkten så som den för närvarande befinner sig i sin utveckling. Det handlar om hur ni kommer att kunna utveckla all denna automatisering sömlöst i takt med att produkten utvecklas under sin egen livscykel.
Om du ignorerar problemen med automatiseringens omfattning, QA-ingenjörernas kvalifikationer, begriplighet, underhållbarhet och rollfördelning kommer du med tiden att upptäcka att hela automatiseringsinsatsen har blivit en vit elefant och ett ekonomiskt slukhål som är omöjligt att förstå eller underhålla.
Och alla pengar du har lagt på den kommer att ha gått till spillo. Något som dina chefers chefer inte kommer att undgå att lägga märke till.
Om du å andra sidan följer råden jag ger ovan, naturligtvis anpassade efter de specifika utmaningarna och förutsättningarna i din egen situation, kommer du i stor utsträckning att undvika denna föråldringskris och kunna dra nytta av produktiv testautomatisering i många år framöver.
Som alltid, lycka till.
Relaterad läsning:
- 10 BÄSTA VERKTYGEN FÖR ÖVERVAKNING AV WEBBSERVRAR
- BÄSTA METODERNA FÖR AUTOMATISERING VID DIGITAL TRANSFORMATION
Värt att kolla in: VAD ÄR MABL? ÖVERSIKT OCH GENOMGÅNG AV FUNKTIONERNA
