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!

Sluta testa...

Sluta testa för att därigenom förbättra kvalitén! På senare år har vi pratat mycket om hur vi ska kunna testa så effektivt som möjligt; testautomatisering, test i självorganiserade team, test- och acceptanstestdriven utveckling, ”crowd testing” o.s.v. Allt detta är bra men det finns andra aspekter, som traditionellt ligger utanför testområdet, och i slutänden har större påverkan på kvalité än vanligt testarbete. Som testledare är det något som vi inte har råd att förbise.

På NFI Testkonferens våren 2014 lät jag ställa frågan ”Vad tar testledarens tid?”. Jag fick 108 svar från de testare och testledare som deltog i konferensen. Alternativet ”Planering av testaktiviteter” fick överlägset mest svar, faktiskt mer än övriga svarsalternativ tillsammans! Vi bör ställa oss frågan om detta är rimligt. Visst, planering är viktigt men de övriga alternativen utgör också viktiga delar av testledararbetet och syftar såväl som input till planen samt att uppfylla planen med operativt testarbete. Den faktiska planeringen är bara ett medel och inte själva målet med vårt arbete.

Svarsalternativ	Antal svar
Planering av testaktiviteter	51
Hjälpa till med testarbetet	7
Testverktyg, -miljö, -data	11
Rapportering	15
Kvalitetscoach	7
Strategiskt arbete	13
Analysera kravbild	4

Jag är konsult och jobbar ute i de mest skilda organisationer. Ofta kommer jag på mig själv med att börja mina testuppdrag genom att skriva en testplan. Ofta kan jag utgå från någon generisk mall, byta ut några systemnamn, anpassa gantt-schemat och jag har ”Carte Blanc” för några dagars debitering. Jag kan känna mig produktiv från allra första timmen, vilket förstås är viktigt för en konsult. Jag har ändå en gnagande känsla av att detta inte är välinvesterad tid. Vad vet jag egentligen om produkten, miljön som produkten används i, organisationskulturen, människorna och nätverken bland utvecklare och användare? Hur kan min ganska generiska testplan vara ett effektivt verktyg i testarbetet? Hur bidrar den till kvalité. Kommer testplanen överhuvudtaget att läsas någon gång?

Tänk om jag istället, inför uppdraget, vetat exakt hur stressade man är i tågdepån i Hagalund, hur komplicerade inköpsekonomernas lagerberäkningar är och hur snabbt man måste ut med förändringar i kampen mellan olika webbutiker. Omständigheter, målsättningar och organisationskultur påverkar leveranskvalité så mycket mer än vad mina testplaner någonsin gör. Hur kan vi som testledare förhålla oss till allt detta som ligger utanför våra testplaner? Lyckligtvis finns det sådana som jobbar med allt detta på daglig basis och som vi kan lära av - management!

Som vi nämnde tidigare har testledarens roll förändrats över tiden och hen har fått behov av nya kompetenser. Att vara mer teknisk eller att vara coachande har oftast diskuterats, men kanske behöver testledaren komplettera med något annat? Jag tror att testledaren ska tänka som en företagsledare och därmed se test som sitt företag.

Test är en business, en business som levererar kvalité. Fördelen är att det finns en massa bra modeller för hur man utvecklar sin business.

Triangelns översta hörn är produkten, alltså det vår business levererar, alltså kvalité. Kvalité av vilken form, färg och smak beror på vad våra kunder vill ha. Ta reda på deras önskemål och leverera enligt detta, annars har din business inget existensberättigande.

Triangelns vänstra hörn är vår testverksamhet. Hur arbetar vi för att leverera kvalité på det sätt och med de egenskaper som kunderna efterfrågar. För att belysa hur arbetssättet påverkar, väljer jag några fokusområden som har stor inverkan på kvalité.

Kvalitetsmål: Att vi vet vilka förväntningar det finns i kvalitetsväg. Att vi vet vilka kvalitetsaspekter som är viktiga i just detta sammanhang och att alla i organisationen förstår vad de kan göra för att nå till detta högre mål. Jag har varit i organisationer där IT är så isolerade att de aldrig sett en slutkund. Där man aldrig besökt den verkliga verksamheten. Där man inte vet mer om affären än vad kravspecifikationen och SLA’erna säger. I sådana sammanhang kan aldrig IT leverera den kvalité som verksamheten förväntar sig.

Hantverksskicklighet: Sen finns det organisationer där man tror att utvecklare är fabriksarbetare som står vid löpande band och bygger applikationer på samma sätt som man spikar ihop fågelholkar. Organisationer där man inte förstår att utveckling är ett hantverk där vi alltid bygger allt för första gången. Som inte beaktar vår yrkesskicklighet och inte förstår vikten av utbildning. Systemutveckling är ingen storindustri och kan inte drivas som en fabriksverksamhet. Det är viktigt att bejaka och uppmuntra medarbetarnas hantverksskicklighet och inte förledas att tro att stordrift ger fördelar.

Samlad intelligens: Ensam är inte stark. Flera personer med olika bakgrund, kompetenser och personlighet, som vrider och vänder på ett problem hittar nya infallsvinklar och korsbefruktar varandras idéer. Det leder till större chans att lösa problemet och en mer genomtänkt lösning.

Nätverk: Systemutveckling är information i kristalliserad form. Vi jobbar med informationsteknologi och ju mer vi vet, desto bättre blir lösningen. Informationen behöver flöda fritt i organisationen och det görs bäst i de organiska nätverk som uppstår där behov finns, istället för i t.ex. den struktur som skapats av management. Beakta och uppmuntra detta, låt medarbetarna söka information och bilda sina egna nätverk utan begränsningar.

Ständig förbättring: Återkoppling, analys och handling i en loop som garanterar ständig förbättring. Vi måste alltid kunna lära av våra framgångar och misstag, annars tappar vi vår förankring med verkligheten.

Dessa fem fokusområden och hur vi presterar inom vart och ett av dem påverkas mycket av värderingar, ledarstilar och organisationskulturen. Allt detta påverkas av vårt ledarskap. Ledarskap utgör därför triangelns högra hörn. Här känner jag att det saknas en hel del inom testskrået idag. Det är väldigt sällan som man diskuterar ledarskap och organisationskulturer, och ännu mer sällan som vi som testledare försöker göra något åt det. Det är synd, för företagets kultur har stor inverkan på vår leverans av kvalité. Ta t.ex. följande fem dimensioner i en företagskultur. Det finns ytterligheter inom varje dimension men företag kan också befinna sig mitt på skalan, eller att olika avdelningar placerar sig olika.

Dimension	Skala
Planering:	Självorganiserad	Byråkratisk
Beslutsfattande:	Transparent	Kontroll
Motivera:	Inre drivkrafter	Piska/morot
Definiera mål:	Framväxande	Styrda

Den första dimensionen visar hur toppstyrd resp. självorganiserande en organisation är. Jag personligen trivs bäst i det förstnämnda tillståndet och jag tror att självorganisering ger goda effekter i form av ansvarstagande, effektivitet och distribuerad kontroll. Trots det får man ha respekt för att många organisationer lutar åt det byråkratiska och det kan finnas goda anledningar till detta.

Beslutsfattandet i en organisation kan bygga på transparens eller kontroll. I en transparent organisation finns informationen tillgänglig för alla att ta del av. Medarbetarna strävar också efter att tillgängliggöra information på lämpliga sätt och att informationen ska vara korrekt. Motsatsen är en organisation där informationen kontrolleras och styrs uppifrån. Här är informationen dold och man behöver fråga efter det man vill ta del av. Det blir viktigt med rapporteringsvägar och vad som presenteras i olika delar av organisationen. Vilken information som finns tillgänglig har naturligtvis stor påverkan på hur och på vilken nivå som besluten tas.

Det klassiska sättet att motivera människor är genom piska och morot. Med hot om inställd semester eller möjlighet till lönebonus försöker man styra personer åt rätt håll. Människor har också egna inneboende drivkrafter som i regel är mycket kraftigare än vad man kan uppnå med extern påverkan.

Mål kan vara av typen, ”Vi ska öka omsättningen med 10 %” eller ”Vi ska anställa åtta personer”. Detta är styrda mål. Mål kan också vara framväxande och en del av organisationens DNA, ”Ingen minns en fegis”, ”Att försöka är förlorarsnack” är slagord som en känd teleoperatör har målat upp på sina kontorsväggar för att förvalta sitt arv som uppstickare och entreprenör.

På en undersökning på NFI Testforum våren 2014 gjorde 108 testare och testledare följande skattningar av företagskulturen i sina organisationer.

Dimension	Skala
Planering:	Självorganiserad (52 %)	Byråkratisk (48 %)
Beslutsfattande:	Transparent (48 %)	Kontroll (52 %)
Motivera:	Inre drivkrafter (67 %)	Piska/morot (33 %)
Definiera mål:	Framväxande (36 %)	Styrda (64 %)

Det upp till oss testledare att avgöra ifall vi i våra organisationer har en lämplig organisationskultur och arbetssätt i vår testverksamhet för att säkerställa god kvalité i vår testbusiness. Att vi reflekterar över detta är minst lika viktigt som våra traditionella test och testledaraktiviteter och något som vi alla borde lägga mer tid på. Det är vad jag menar med ”sluta testa för att förbättra kvalitén”.

Talar på NFI Testforum

Maral och jag talar på NFI Testforum 9 april Hilton Slussen....

Sluta testa och förbättra kvalitén

Dagens integrerade IT-lösningar utgör ett helt ekosystem som fungerar och interagerar på ett ofta oförutsägbart sätt. Testledaren har själv inte möjlighet att leda och kontrollera alla testaktiviteter i komplexa utvecklingsorganisationer och därför måste QA-ansvaret fördelas. Istället för direktstyrning av testarbetet blir då testledarens uppgift att inspirera ALLA att ta ansvar och bidra till de övergripande kvalitetsmålen.

Maral Biniazan är testledare på Omegapoint i Stockholm och brinner för testledaren roll inom modern IT-utveckling. Maral har en bakgrund som testare i agila team och har främst arbetat inom medicinteknik.

Örjan Bjermert jobbar som testare/testledare på konsultföretaget Omegapoint i Stockholm. Han föredrar agil utveckling och kontextdrivna testtekniker eftersom han gillar att jobba nära utvecklare och känner att han då kan bidra så mycket mer än med traditionell testning.

Testledning 3.0 - Att leda självorganiserade testeam i en komplex miljö

Följande artikel är skriven av mig och Maral Biniazan och finns med i Testzonen-boken "Fel fel fel", http://www.felfelfel.se/ .

Testledning 3.0 - Att leda självorganiserade testteam i en komplex miljö

Maral Biniazan & Örjan Bjermert, Omegapoint

Våra IT-system står under ständig utveckling och interagerar med varandra på ett svåröverskådligt sätt. Testarbetet blir allt mer utmanande och en effekt av detta är att våra testmetoder och testtekniker utvecklas hela tiden. Vår förmåga att leda testarbetet har inte utvecklats i samma takt vilket leder till att vi med traditionell testledning saknar metoder att leda effektivt i denna vår komplexa verklighet. Management 3.0 av Jurgen Apello är en etablerad modell för att leda självorganiserade utvecklingsteam. Management 3.0 visar hur det traditionella ledarskapet behöver utvecklas i transformativ och situationsanpassad riktning. På liknande sätt behöver testledaren ändra sitt ledarskap och därför vill vi skapa Testledning 3.0.

Traditionell testledning lägger stor vikt vid planering, styrning, kontroll, uppföljning och rapportering. Testarbetet sker enligt en förutbestäm plan, inspirerad av standarder eller vedertagna “sanningar”. Genom att delegera uppgifter och inhämta resultat enligt denna förutbestämda plan utövar testledaren ett traditionellt ledarskap, vilket vi väljer att kalla Testledning 1.0.

Vid ledning av mer komplexa testuppdrag inser testledaren att förutbestämda planer och processer inte fungerar rakt av. Strategin måste anpassas och planer måste förändras allteftersom. Testledaren inser behov av ständig förbättring och jobbar gärna med förbättringsmodeller. Testledaren inser behovet av effektiva verktyg, iterativ utveckling, tekniska tester under utvecklingsfasen och därmed en utvidgning av testbegreppet. Denna förbättring kan ses som en övergång till Testledning 2.0. Nackdelen är att förändringen allt som oftast fokuseras på tekniska aspekter. Testledaren missar att människor och team är organisationens viktigaste redskap och lägger därmed lite vikt vid att förändra sitt eget ledarskap. När ingen enskild individ kan tillgodogöra sig all den kunskap som behövs för att hantera komplexiteten inom modern IT-utveckling så måste kontrollen delegeras. Självorganiserade team kan ta sig an utmaningen. Testledaren måste därför lära sig att leda självorganiserade team, oavsett om testarbetet utförs av testare i en separat testorganisation eller i agila tvärfunktionella utvecklingsteam. Testledning av självorganiserade team kallar vi för Testledning 3.0 och representerar, enligt oss, nästa steg i testledarrollens utveckling.

Management 3.0 av Jurgen Apello beskriver en etablerad modell för att leda självorganiserade utvecklingsteam, men de underliggande teorierna beskrivs även i andra sammanhang[1]. I den här artikeln vill vi skapa Testledning 3.0 genom att tillämpa Management 3.0 på testledarrollen. Varje steg i Testledning 3.0 bygger på teorier tagna från Management 3.0, men anpassade till testledarens verklighet. Det finns många böcker skrivna om agil testning och förbättringsprocesser för test. Det finns oändligt med verktyg, ramverk och tekniker som kan hjälpa oss. Man tar upp de tekniska svårigheterna som den nya testledaren måste hantera men ingenting nämns om de kulturella svårigheterna. Testning oursourcas och crowdsourcas, ibland finns en etablerad testorganisation ibland inga testare, vissa arbetar testdrivet andra efter en traditionell teststrategi. Ibland påstås att “testledaren är död” och kommer att ersättas av en strateg, coach eller testarkitekt. För att testledaren ska överleva, och leda effektivt kvalitetsarbete i framtiden, måste denne veta hur man leder test i komplexa miljöer med hjälp av självorganiserade team. Testledning 3.0 är ingen enkel anpassning eller översyn. För att klara av framtidens krav tror vi att testledarrollen behöver omarbetas, rivas ner och byggas upp på nytt.

Att motivera människor (Management 3.0, Energize People)

Organisationer kan ses som komplexa adaptiva system^[2]. I ett sådant system är människor de aktiva utförarna. Metoder, mallar, verktyg och processer är statiska artefakter och därmed av underordnad betydelse. Trots detta tenderar testförbättringsprocesser att förbise den mänskliga aspekten^[3]. Människor reagerar, agerar och anpassar sig dynamiskt och har därmed förmågan att kontrollera komplexa system. Därför är “att motivera människor” det första området i modellen.

Innovation är nyckeln till överlevnad i varje konkurrensutsatt miljö. En testledares uppgift är att lägga grunden för en innovativ miljö. Information, motivation, kultur, mångfald, kunskap och kreativitet är viktiga byggstenar som alla hänger ihop för att skapa rätt förutsättningar. Ett team tar in information, reagerar på denna och skapar innovation. Om testledaren förbättrar informationsflödet och uppmuntrar informationssökandet, leder detta till ökad innovation. Ett otillräckligt informationsflöde kan leda till låg motivation då testarna inte inser vikten av sitt arbete. Dålig balans mellan ordning och kaos, och i förlängningen en dålig arbetsmiljö, kan vara ytterligare en orsak till låg motivation. En strävan efter mer tekniska tester kan leda till en homogen kultur, minskar mångfalden och ger för snäva perspektiv. Lösningen är att testledaren skapar förutsättningarna för teamet att söka samt sprida kunskap, och därigenom få en mer mångfacetterad bild av verkligheten.

Många testare har inte en tillräckligt kreativ arbetsmiljö. Kreativitet hålls tillbaka genom hårt styrda testprocesser. Genom att vara medveten om dessa byggstenar kan testledaren göra mycket för att skapa en mer kreativt miljö och uppmuntra testarna.

Stärka teamen (Management 3.0, Empower Teams)

Ett annat karaktäristiskt drag hos ett adaptivt komplext system är självorganisering och anpassning till en föränderlig miljö. Detta görs utan hänsyn till central administration och en testledare måste inse att man aldrig har fullständig kontroll. Beslut tas ständigt utan ledarens kännedom och den informationsmängd som krävs för att fatta riktiga beslut är helt enkelt för stor för en ensam individ att hantera. Möjlighet till självständigt agerande måste därför distribueras till organisationens alla delar. Ledaren måste hitta nya sätt att leda de självorganiserade teamen mot givna mål.

Självorganiserade team är testledarens nya stora utmaning, oavsett om test utförs inom korsfunktionella scrumteam eller i dedikerade testteam. Testledare måste kunna hantera de självorganiserade teamen och leda testningen åt rätt håll. Ju mer komplex en miljö är, desto mer information behövs för att förstå vad som egentligen pågår. Att samla information via möten är vanligt men i en komplex miljö blir antalet möten och antalet berörda fort ohanterligt. Traditionell testledning tenderar att bromsa teamet då mycket av teammedlemmarnas energi går åt till att rapportera till testledaren. Som testledare kan man förstås samla information på andra sätt men det betyder att ledaren själv måste behärska ett stort antal kanaler. För att undvika att bli en flaskhals måste testledaren våga lätta på kontrollen och ge teamen makten att bestämma själva. Teams mognadsgrad avgör vilken ledarstil som kan användas. En ledande (tell, sell, consult) eller coachande (agree, advice, inquire, delegate).

Definiera mål (Management 3.0, Align Constraints)

Vad är testledarens roll i denna självorganiserade verklighet? Testledaren kan ofta känna sig vilsen i en växande kunskapsintensiv och mångfacetterad testorganisation. Självorganiserade team ska kunna fatta egna beslut, men det är fortfarande ledarens ansvar att definiera gränser och kommunicera mål till de självorganiserade teamen. Kvalitetsmålen skiljer sig mycket mellan olika verksamheter och är beroende av kontext. Det är viktigt att testledaren harmoniserar målsättningen med testarbete och systemkvalitet med de övergripande verksamhetsmålen.

Att förbättra testorganisationen utan hänsyn till företagets övergripliga mål, slutar nästan alltid med suboptimering som inte gynnar hela organisationen. Ifall målet är hitta så många buggar som möjligt, så kanske teamet lägger all tid på detta istället för att avskriva bristfälliga leveranser. I det fall test tar för långt tid kan det bero på svårtolkade krav och då måste detta adresseras innan man optimerar testprocessen. På motsvarande sätt händer det att hela testförbättringsprojekt läggs ner då målen och nyttan med dem inte kommuniceras ut tillräckligt väl och övriga företaget inte förstår värdet.

Förutom att sätta mål ska testledarens skydda från yttre påverkan, exempelvis intressenter som har olika, motstridiga eller orimliga krav. En miljö där det råder balans mellan ordning och kaos ger bäst förutsättningar för innovation. I en helt kaotisk miljö tvingas teamet hela tiden att reagera på oförutsägbara kritiska händelser, släcka bränder och hålla näsan över vattenytan. I en helt styrd och välordnad miljö stryps alla kreativa idéer och nyskapande infall.

Utveckla kompetens (Management 3.0, Develop Competence)

Det är ledningens ansvar att se till att människor innehar den kompetens som behövs för att göra sitt jobb. Ett ganska vanligt exempel där det kan gå fel är företag som går över till agil utveckling i hopp om att minska på testresurser. För att skapa tvärfunktionella team splittrar man ofta testteamen, och ofta till följden av sämre testresultat, då test inom ett utvecklingsteam kräver kompetens som inte utvecklingsteamet har. Människor har olika förutsättningar och det är testledarens uppgift att se till att kompetensutveckling sker på rätt nivå. En del kanske köper egna böcker och börja läsa självständigt. Andra behöver lite mer coaching för att komma igång. Vissa vill gå på kurs och certifiera sig för att visa att det lärt sig grunderna.

Beroende på kunskapsnivå kan teamet förhålla sig till regler på olika sätt (t.ex. följa givna regler slaviskt eller utmana regler efter behov). Som ledare är du ansvarig för att se till att teamet förstår de övergripande målen. Om dina regler är sämre än teamets regler kommer dina att stötas bort.

I en komplex miljö kan man inte förutsätta att en viss påverkan alltid leder till liknande resultat. Det är därför omöjligt att sätta regler eller införa “best practices” som funkar för alla. Lösningen är istället att låta teamen skapa sina egna regler utifrån gällande mål och gränser. Se till att självorganiserade team skapar och justerar sina egna regler. För att teamen ska vara kapabla till detta måste det ha rätt förutsättningar och rätt kompetens.

Skapa struktur (Management 3.0, Grow Structure)

Den optimala organisationsstrukturen varierar beroende på produkt, människor, miljö och det finns därför ingen gyllene regel för hur organisationen bör se ut. Däremot bör man tänka på att organisationens struktur påverkar hur kommunikationen flödar och att god kommunikation är nödvändigt för effektivt samarbete. I en organisation finns det alltid grupperingar, formella eller informella. Informella ledare är utspridda i hela organisationen och testledaren bör identifiera dessa för att underlätta sitt arbete.

En testorganisation bör struktureras efter hur kommunikationen flödar. Människor hanterar information på olika sätt. Det finns människor som gärna sprider information. Det finns också människor med tillgång till dessa informationsspridare. Som testledare är det viktigt att kartlägga detta och skapa en struktur därefter. Det är också viktigt att inte låta människor begränsas av strukturerna. Eftersträva "vida jobbtitlar" (t.ex. att inte dela upp folk i testare och utvecklare) så att människor får möjlighet att utveckla hela sin kompetens istället för att låsas fast i roller. Underlätta för människor att utveckla tvärvetenskaplig kompetens istället för att specialisera sig inom enbart ett område, men respektera att många behöver känna trygghet i en specialistkompetens innan de är redo för utmaningar på andra områden.

Förbättra allt (Management 3.0, Improve Everything)

Människor, team och organisationer behöver alltid förbättra sig för att bli mer effektiva. Detta är speciellt viktigt i komplexa miljöer där ständig förändring är nyckeln till att dra nytta av lärdomar och anpassa sig efter nya omständigheter. Utan förändring ingen utveckling, vilket leder till stagnation och degenerering. Det finns ingen heltäckande modell för förändring och förbättring i en komplex miljö men däremot flera metoder som kan användas i olika sammanhang och ibland överlappar varandra.

IT-systemen blir allt mer komplicerade, med fler integrationer på diversifierade plattformar. Gårdagens teststrategier kommer inte att fungera imorgon. Allteftersom testbördan växer måste vi därför testa mer effektivt. Tyvärr har testorganisationer tendenser att vara statiska och reagera långsamt på förändring. En anledning till detta är att förändring inte alltid leder till omedelbar förbättring. Man är rädd att nya arbetssätt kan försämra testarbetet initialt och därmed riskera kvalité. Ett vanligt tillvägagångssätt är att följa dokumenterade förbättringsmodeller då man ser detta som en mer säker förändringsstrategi. Dock är etablerade förbättringsmodeller inom testområdet dåligt anpassade till komplexa adaptiva system och vi har tidigare tagit upp hur flera av dem saknar den viktiga mänskliga aspekten. Det finns ingen process, strategi, verktyg eller “silver bullet” som fixar allt. Skapa din egen verktygslåda!

---

[1] Complexity and organizational reality - Ralph Stacey, Complexity a guided tour - Melanie Mitchell, Chaos making new science - James Gleich, The Fifth discipline - Peter Senge, Systems thinking - Donella Meadows, Drive - Daniel Pink, What matters now - Gary Hamel, Leading change - Kotter

^[2] En organisation består av delar (människor) i ett system (team), vilket visar komplext beteende genom anpassning till en föränderlig miljö.

^[3] TPI och TMM fokuserar t.ex. på dokumentation, planering, mätetal o.s.v.