Testautomatisering - på rätt sätt

"Testautomatisering - på rätt sätt" är ett föredrag som tidigare hållits av Maral Biniazan och Örjan Bjermert för kunder till konsultbolaget Omegapoint.

Ofta är intresset för testautomation ett resultat av att systemutvecklingsarbetet har organiserats i agila utvecklingsteam. Det innebär att utveckling och verifiering sker i samma sprint och på samma kodbas, med ett teamgemensamt fokus på utveckling och kvalité. De ofta frekventa releaser som levereras av det agila utvecklingsteamet behöver testas under den begränsade tiden i sprinten. Det blir ofta väldigt många realaser och det är en stor risk att testarna drunknar i en massa regressionstester och kommer i otakt resten av teamet. Det finns massor med spännande testtekniker som vi tagit fram för att stödja utvecklingsnära tester i agila utvecklingsteam och därmed undvika att testarbetet blir en helt egen fas. Vi vill t.ex. arbeta med modellbaserad testning, kontextdriven testning, personas, et.c. För att kunna lägga tid på att genomföra tester med dessa mer spännande och kvalificerade tekniker så behöver vi något som tar hand om löpande regressionstester. Här kommer testautomatiseringen in. Med en automatisering av regressionstesterna så vet vi hela tiden vilken grundläggande kvalité vi har på koden, innan vi kör igång med de mer kvalificerade testerna.

När vi är ute i olika organisationer och företag för att diskutera testautomatisering så är det påfallande ofta som följande frågeställningarna dyker upp …

• Vilka verktyg och ramverk finns det, vad kan vi köpa in och använda?
• Vilka manuella testfall har vi som vi kan automatisera?
• Hur gör vi en automatisering på GUI-nivå för att återskapa de manuella tester som testarna nu gör?
• Vilka tekniska testare finns det med kompetens inom vårt valda ramverk/verktyg?

Vi tror inte att det här är rätt tillvägagångssätt, men hur ska vi isåfall göra?

Vi har båda arbetat som tekniska testare och då haft konsultuppdrag som innefattar testautomatisering. På dessa uppdrag har vi inte, som man kanske föreställer sig, skrivit massa automatiseringskod. Det är ofta en massa andra viktigare saker som först måste komma på plats, och det är här som vi har börjat se ett mönster. För det är ungefär samma nyckelfaktorer som är väldigt viktiga för att ett testautomatiseringsprojekt ska bli framgångsrikt. I den här texten går vi igenom dessa nyckelfaktorer. För att de ska bli mer konkret, så exemplifierar vi resonemanget med erfarenheter från vår verklighet.

Exempelprojekt

Exempel A: En säkerhetsklassad applikation som används av miljontals användare. Teamet består av fem utvecklare, två systemtestare med uppgift att automatisera, två acceptanstestare och en produktägare. Olika konsultbolag ansvarar för utveckling och test men arbetet ska bedrivas agilt. Mitt konsultföretag ansvarade i första hand för test och det är därmed viktig att undvika en kultur där de båda konsultbolagen skyller på varandra och istället verkar för att tillsammans leverera en bra produkt.

Exempel B: En webbutik hos en stor operatör. Jag är testledare för ett några agila utvecklingsteam. Jag arbetade även nära verksamheten, bestående av tre olika verksamhetsområden. Vi arbetade i tvåveckorssprintar med leverans till produktionsmiljö och alla kunder i slutet av sprinten. Två veckor är ungefär sålänge som en stressad produktägare kan vänta när de ser hur andra operatörer gör reklam för sina produkter i tunnelbana påväg till jobbet. En annan aspekt är att telekomprodukter är ganska komplicerade att sälja. Det behövs en hel del logik för att sätta ihop fungerande abonnemangspaket och migrera in kunder.

Målsättning

Precis som alla andra typer av IT-projekt, behöver ett testautomatiseringprojekt behöver en målsättning. Det är vanligt att man missar detta. Ofta utrycks mål i önskningar att öka kvalité eller att spara pengar. Många ser framför sig att avveckla manuella tester genom att införa testautomatisering. Är dessa mål specifika nog och är de nåbara? Mål ska vara relevanta för den produkt som utvecklas och tidsaspekten ska finnas med. Har man inte specifika mål så är det svårt att veta ifall något har uppnåtts. SMART-metodiken är en bra utgångspunkt (Specific, Measurable, Achievable, Realistic, Timely).

Exempel A: När jag började mitt uppdrag så var det tydlig att de inte hade några mål med sin automatisering. Många gånger fick jag frågan om hur många testfall vi hade och hur många av dessa som var automatiserade. Varje gång undrade jag, varför är det så viktigt? Antalet testfall är inget bra mål och säger ingenting om progress i automatiseringsprojektet. Vi omdefinierade därför till målsättningen att kunna release snabbare. Från att ta en månad i anspråk så satte vi målet till fem dagar. Det är ett mål som man kan mäta och utvärdera. Till slut lyckade vi genomföra releaser på bara två dagar med dryga fyra miljoner användare. Detta säger mycket mer än antalet testfall, om vår framgång. Vi har nu en backlog med alla våra testaktiviteter. Produktägaren får tycka till om vad som är viktigast och vad vi ska fokusera på i vår automatisering, precis som prioriteringsprocessen för resten av projektet.

Exempel B: Vi har testreleaser med ny funktionalitet från sprintens första dag och ända till slutet. Vi behöver ha en möjlighet att kunna verifiera alla dessa releaser allt eftersom utvecklingen evolverar. För att vi som testare ska kunna känna en initial säkerhet behöver varje ny release uppnå någon sort hygiennivå så att vi kan koncentrera oss på de nya funktionerna. Vår målsättning är att det ska finnas automatisering för alla befintliga ”vägar” som kunderna kan ta genom webbutiken.

Kompetens

Tekniska testare är väldigt efterfrågade idag. Vi tror det beror på att vi i denna roll ser någon som kan lösa alla problem. Någon som förstår test, som förstår kod, som förstår krav och kan automatisera. Därför anställer vi gärna tekniska testare och räknar med att allt ska fungera perfekt.

Exempel A: För projektet anlitades två tekniska testare och de gav sig i kast med en backlog av manuella tester som skulle automatiseras. Dessa gjorde ett fantastiskt jobb och automatiserade de tester som fanns, men detta sänkte inte releasetiden. Vi insåg att automatisering av manuella testfall inte var problemet och att vi behövde göra något annat. Vi behövde någon som kunde se över helheten. Därför kom jag in och ersatte en av de tekniska testarna, tog tag i målsättning och hur vi borde jobba. Jag lät en utvecklare bygga testramverket och jag som testare fungerade som produktägare till testramverket. När sen ramverket var klart ersatte vi både mig och utvecklaren med en lite annan profil med god kunskap i produkten och som kunde skripta i testramverket. Vi har sen dess fortsatt att byta ut kompetenser under projektets gång allt utifrån de behov som finns för tillfället.

Exempel B: Vi gjorde det klassiska misstaget och plockade in en konsult utifrån. Hennes kompetens låg någonstans i gränslandet mellan test och utveckling. Planen var att sätta några manuella testfall i näven på henne, för att låta henne sitta och automatisera. Vi märkte snart att arbetet gick långsamt och frustrationen ökade ifrån hörnet där hon satt. Hon använde Selenium för att koda ner våra manuella tester, samtidigt som vårt grafiska gränssnitt var under utveckling och förändrades frekvent. Det var inte rätt metod och det var inte rätt att låta henne sitta med manuella tester och replikera dessa utan kunskap om domänen. Istället kom vi fram till att vi faktiskt redan hade kompetensen inom teamet. Utvecklarna jobbade mycket med unittestning. Vi testare kunde lära av dem, hur de använde sitt ramverk och skala upp detta för systemtester. En följd av detta blev att utvecklare och testare kom närmare varandra. Testarna började förstå mer av den tekniska domänen, utvecklarna började förstå mer ab vad testarna höll på med och vi kunde dela på verktyg och kompetens. Att låta en utvecklare och en testare ta sig an automatiseringsutmaningen från respektive horisont är bra sätt att börja, istället för att leta efter alla kompetenser i samma person.

Krav

Vi har nämnt att det är vanligt att organisationer önskar automatisera sina manuella tester. En utmaning är, att vid en automatisering, så blir det väldigt viktigt hur produkten kravställts. T.ex. ifall ett nytt dialogfönster ska öppnas, så kan en mänsklig testare bedöma ifall det tagit för lång tid. Vid en automatisering måste vi däremot veta exakt hur systemet bör bete sig då vi inte kan bedöma rimligheten samtidigt som testet körs.

Exempel A: Våra krav var i dokumentform och vi behövde skriva om dessa så att de blev unika, testbara och passa för vår automatisering. Vi fick formulera om och bearbeta. Att testerna går fel kan bero på att kraven inte är riktigt korrekta. Vi passade även på att lägga till ”varför”, för att ytterligare förklara de olika kraven.

Exempel B: Mycket av komplexiteten i webbutiken handlade om orderflödet. Hela systemet kan beskrivas som en stor tillståndsmaskin och det är svårt att utrycka en sådan i löptext. Vi kom på att vi faktiskt hade en funktion som byggts för kundtjänsten, så att de kunde spåra köpordrar i orderflödet. Vi baserade helt enkelt vår testautomatisering på denna funktion. Det fungerar nästan som ett försteg till modellbaserad testning och gjorde att vår automatisering upplevdes lite mer intelligent.

Testbarhet

Den gängse bilden av mjukvarutestning är en manuell testare som testar ett system som en black-box, leverat av ett utvecklingsteam. Det är därför kanske inte konstigt att vi med automatisering ofta försöker härma detta arbetssätt. Ibland är inte heller applikationen byggd för att vara testbar och det kan därför vara svårt att jacka in en automatisering. Detta brukar resultera i en kanske inte helt optimal inspelning och repetering av de ”klick” som en manuell testare gör i användargränssnittet.

Exempel A: Vår applikation var ganska svår att testa och utvecklarna fick bygga funktioner så att vi kom åt att testa på ett effektivt sätt. Vår applikation körs i webbläsaren i ”secure desktop”-läge och man kommer inte åt gränsnittet utanför denna sandlåda. Det fick vi lösa med automatisering inifrån applikationen och det fanns det inga färdiga verktyg för. Ett annat sätt att komma vidare är med semiautomatiska tester. Allt behöver faktiskt inte var helt automatiserat. Ibland tar det lång tid att skapa relevant testdata. Ifall denna process automatiseras så har man vunnit mycket utan att automatisera de kompletta testerna. Vi jobbar med regelbunden scenarioframtagning, inklusive vilken nivå vi vill lägga testerna på. En del kan testas på unit-nivå, annat lämpar sig för acceptanstesterna.

Exempel B: Vi försökte fruktlöst att automatisera vårt grafiska gränssnitt men hade, på den tiden, ingen riktigt bra teknik för Ajax och responsiv design. Istället jackade vi in testautomatiseringen mot back-end och det soap-gränssnitt som låg exponerat mot front-end. För en testare som är van med grafiska användargrässnitt så ser soap kanske komplicerat ut. För en maskin så är det rena drömmen och det är väldigt tydlig vad vi vill ha och vad vi ska leta efter. Vi använder SoapUI som verktyg för att bygga sekvenser över hur olika soap-anrop ska triggas i tur och ordning.

Verktyg

De flesta brukar börja sin automatiseringsresa med att välja automatiseringsverktyg. Det är inte ett helt bra tillvägagångssätt. Att sitta fast med fel verktyg är lite som att gå omkring i för stora eller för små kläder. Det är svårt att hitta verktyg som passar hela organisationen, alla kompetenser, samt såväl noviser som automatiseringsproffs. Vi väljer verktyg utifrån miljön, produkten och människorna. Ett verktyg måste vara rätt utifrån dessa tre fakturor.

Exempel A: Det var svårt för oss att hitta ett verktyg som passade just den kunden. Istället blev det ett hopplock av open source verktyg med anpassningar och kompletterat med egenutvecklade funktioner. Allt eftersom lade vi till olika pusselbitar för att komplettera vår verktygskedja.

Exempel B: Vi hade som strategi att bygga vidare på den kompetens vi hade inom teamet. Det resulterade i tekniknära verktyg, såsom SoapUI och återanvändande av ramverket för unittester i Java. Med en kombination av dessa lyckades vi täcka in med bra tester, också på systemtestnivå, i vår build-deploy process. Utvecklarna kunde hjälpa oss testare och vi kunde hjälpa dem. Som en bieffekt fick vi ett mer sammansvetsat team.

Visualisering

Visualisering är en viktig del av automatiseringen då själva testkörningarna oftast inte syns. Att min projektledare tidigare frågade efter testfall, det är ju en reaktion på att hon tappat kontrollen och vill veta hur det går och vad vi gör. Jag har varit med om just detta flera gånger och skulle kunna jobba heltid med att rapportera till projektledare. Att tänka på hur vi visualiserar det vi gör är därför väldigt viktigt.

Exempel A: För att veta exakt vilka krav vi hade testat så överförde vi kraven till ett testhanteringssystem och kopplade alla testfall mot krav i detta system. Då kunde projektledningen själva se vilka krav som testades manuellt, vilka som testades automatiskt, vad testfallet gick ut på och hur det hade gått. De hade redan den senaste information och vi behövde inte längre rapportera. De visste redan om testresultatet vad grönt eller rött.

Exempel B: En annan aspekt på visualisering är att eftersom det är en automatisering, så är det väldigt viktigt att den körs automatiskt. Vi vill inte hamna i en situation att någon måste trycka på startknappen med jämna mellanrum för att köra automatiseringen. Detta kanske låter som en självklarhet, men det är inte alla som tänker så långt när de bygger automatisering i sin build-deploy pipleline. Det händer väldigt lätt att automatiseringen blir inaktuell då den inte körs. Koden utvecklas, något testfall kanske inte går att köra, vilket snabbt resulterar i fler okörbara testfall, och ett litet helsike att ta hand om. Koppla en signallampa eller brandalarm till deployburken om det behövs, för om bygget inte går att testa, och testfallen inte fungerar, så ska det tas hand om direkt. Risken är stor att det annars eskalerar. I ett team som jag jobbat i närheten av, hade vissa som vana att koppla bort automatiseringen för att den var trasig på olika sätt. De kopplade på automatiseringen igen när nya koden var körd. Det är taskigt mot de andra som utvecklar mot koden och medför även en ökad risk att något går fel i produktion senare. Visualisera, ju tydligare destå bättre!