Utforskande test – Framgång och fallgropar

Denna artikel publicerades ursprungligen av Konsultbolag1. Sedan 2020 har verksamheten gått ihop med inUse (part of AFRY). Vi har sedan dess kunnat erbjuda ett spännande urval av kurser inom de samspelande områdena kravhantering, test, design och effektkartläggning under inUse Academy.

Vad är Utforskande testning?

Med utforskande test försöker testarna hela tiden anpassa sina tester utifrån hur mjukvaran reagerar under testerna istället för att utgå ifrån redan fördefinierade testfall. Med denna metod blir testningen mycket mer dynamisk än vid användningen av testfall.

Det går att likna testningen med tennis. När två personer spelar en tennismatch försöker ingen av dem i förväg planera i detalj hur de ska agera längre fram i spelet. Istället har de endast en lös idé om hur spelet skall spelas. Det är motståndarens agerande som till viss del får styra hur de själva lägger upp sitt spel. Detsamma gäller vid utforskande test. Endast en lös idé om hur testningen skall gå till skapas innan själva testsessionen. Sen är det mjukvarans agerande som får styra hur testaren vill lägga upp den resterande testningen. Fördelarna med utforskande test är många, både för organisationer och för de testare som utövar det, exempelvis är testtäckningen en av de största fördelarna utforskande test kan tillföra. En annan fördel är att utforskande test även ger en roligare arbetssituation för testaren, som får mer frihet i sitt arbete. Dessutom är det så att för det mesta skiljer sig både antalet fel och typen av fel markant åt i jämföresle med när endast scriptade testfall används. De, inte alltid så uppenbara, felen som slutanvändarna brukar hitta när de använt produkten ett tag, har ofta en större chans att dyka upp vid utforskande test. Detta kommer sig av att testarna har mycket mer slutanvändarfokus och försöker tänka och agera som en av systemets användare.

Det är dock inte sagt att utforskande test inte kan medföra utmaningar eller problem. Det har aldrig riktigt pratats om några av utmaningarna med utforskande test, förutom ett par små parenteser såsom att det kräver sin testare och, på senare tid, kanske inte passar in i samtliga situationer och organisationer.

De utmaningar den enskilde testaren kan tänkas ställas inför är dock inte så obefintliga som det ibland verkar framstå. De problem som kan uppstå vid utforskande test som jag kommer att ta upp i den här artikeln är egentligen inte ett problem med själva tekniken utforskande test, utan snarare hur man använder tekniken inom många organisationer. Det är inte heller sagt att just dessa problem uppstår i alla situationer. Vilka utmaningar som stöts på vid utforskande test kan, precis som med vilken metod som helst, variera från företag till företag. De grundar sig ofta i vilken mognadsgrad som finns inom organisationen samt hur pass seriöst de väljer att satsa på utforskande test. Jag anser att det är viktigt att inte ge upp utforskande test om organisationen stöter på problem eller inte direkt får ut önskat resultat. Utforskande test är något som man måste ge en chans. I och med att det är ett sådant annorlunda arbetssätt än vad många är vana vid kan det ibland ta lite tid att få allt på plats. Klarar teamet bara av att identifiera vilka problem som uppstått samt starta en diskussion kring hur dessa kan lösas är chansen stor att testningen kommer att bli mer effektiv och framgångsrik.

Utmaningar och fallgropar

En av de större utmaningarna jag har upplevt är bristen på uppmärksamhet ifrån organisationen man sitter i samt att man lätt kan känna sig bortglömd ibland.

En mer traditionell testare gör ofta minst fyra saker: 1) granska kravspecifikationer för att 2) utifrån dessa skriva testfall, 3) exekvera testfall och 4) skriva felrapporter.

En testare som arbetar med utforskande test skriver och exekverar som bekant inga i förväg definierade testfall. Istället utför testaren tester samtidigt som denne hela tiden försöker tänka ut vad som bör testas i nästa steg samt hur detta skall testas. Därför finns det inte heller ett enkelt och översiktligt sätt för organisationen att få en snabb överblick av vad testaren gör. Det enda som blir synligt i detta fall är felrapporterna. Hittas inga fel skrivs således inga felrapporter.

Brist på feedback/debriefing

Utforskande test saknar dock inte dokumentation, även om den kan se väldigt annorlunda ut än inom scriptad testning. För att öka spårbarhet och visa på vad testaren har testat bör det alltid skrivas en testrapport. Rapporten skall innehålla information om vad som var tänkt att testas samt själva syftet med testsessionen. Information om vad som hittades under testet samt vad som inte testades av i den ursprungliga testidén samt varför detta inte testades skall också ingå. Ifall testaren kommer på en idé som bör testas av i framtiden skrivs även detta ner i testrapporten, så att inte testidén glöms bort.

Det är även här ett av de största problemen med utforskande test kommer in. Väldigt få inom ett givet företag har vare sig tid eller lust att läsa en testrapport där inte uppenbara fel presenteras. Det är ju i så fall mycket enklare att ta fram statistik på antal skrivna felrapporter för att få veta kvalitén. Rätt eller fel - det är på detta sätt många arbetar. Ifall testrapporterna inte läses gör detta lätt att testaren ibland kan känna sig bortglömd.

Att få beröm för att man exekverat alla sina tilldelade testfall innan deadline utan att hitta speciellt många fel är inte helt ovanligt. Däremot är det inte lika förekommande att få höra uppskattning för att man har utfört utforskande tester i flera dagar utan att hitta speciellt många fel. Trots att utforskande test ofta anses vara en väldigt rolig metod att arbeta med jämfört med till exempel scriptad testning riskerar även utforskande test att bli långtråkigt efter ett tag, om man inte arbetar med en väldigt föränderlig mjukvara. Efter att ha lärt sig systemet och testat igenom de flesta delarna tenderar arbetet att bli långtråkigt ifall inte helt ny funktionalitet tillkommer och då inga detaljerade tester finns förberedda kan det vara svårt att säkerställa att tester faktiskt utförs.

Missförstånd om hur utforskande test används

Inom många organisationer tror man sig även arbeta med utforskande test när man egentligen endast använt sig av mer eller mindre planlös ad-hoc testning eller så kallad ”happy testing”. Det vill säga testning utan någon större styrning eller uppföljning. Även om dessa typer av testning kan anses vara en form av utforskande test är den stora skillnaden just avsaknaden av planering, styrning, dokumentation samt framför allt uppföljning. Det jag menar med utforskande test utgår från att det finns en plan och tanke för hur systemet ska testas och vad en session ska innefatta, redan innan de faktiska testerna påbörjas. När dokumentation och uppföljning blir minimal tenderar själva testningen i slutändan att bli ganska godtycklig. Därför kan det lätt skapas en avsmak för utforskande test både från organisationen samt testarens sida, trots att man i egentlig mening inte arbetat med riktig utforskande test. På grund av detta är det inte ovanligt att höra små syrliga kommentarer angående utforskande test just för att den personen tror sig ha arbetat med utforskande test och misslyckats.

Organisationen kan ha för hög förväntan på utforskande test

Ett annat problem kan i vissa organisationer vara att man har för höga förväntningar på resultatet och effekten utav utforskande test, då metoden har haussats upp en hel del de senaste åren och från vissa håll påståtts vara den ultimata lösningen på alla testrelaterade problem ett företag kan tänkas ha. Organisationer med till exempel dåligt definierade krav, avsaknad av funktionsöverskridande testning samt oklara ansvarsområden för de olika test- och utvecklingsteamen kan ibland ta in utforskande test för att öka kvalitén på sin produkt istället för att gå till grunden med vad deras största problemområden är. Gjort på rätt sätt och med rätt blandning av utforskande test och traditionell testning kan självklart utforskande test lösa vissa av dessa problem.

En annan förväntning företag kan ha gällande utforskande test är uppstartstiden. Även om det ofta går fortare att starta upp ett helt nytt utforskande test-team från grunden än att köra igång med ett traditionellt test-team betyder det inte att utforskande test-teamet kommer lösa företagets alla problem och hitta samtliga buggar redan första veckan. Även en testare som arbetar med utforskande test måste få tid på sig att lära känna mjukvaran och förstå produkten. Självklart hittas sannolikt fel under denna uppstartstid men lite beroende på hur van testaren är kan det ta ett tag att få upp effektiviteten på testningen.

Sammanställning av identifierade problem

En kort sammanfattning av vilka problem en utforskande testare kan tänkas stöta på blir då

Organisationen har lågt förtroende för utforskande test
Testrapporter blir inte lästa
Debriefing hinns inte med
För högt ställda krav på utforskande test
Liknande tester tenderar att bli långtråkigt
Ointresse samt ingen uppskattning från organisationen

Förslag på lösningar till de genomgångna problemen

För att komma runt ovan nämnda problem finns det diverse aktiviter både organisationen och den enskilde testaren kan företa sig. Tyvärr finns det ju sällan någon universallösning som fungerar i alla lägen utan vissa lösningar går hem hos vissa personer medan andra inte alls gillar dem.

Personas

Ett ganska klassiskt sätt att göra utforskande test roligare men även effektivare är att använda sig utav personas.

Du kan som testare skapa upp ett antal fiktiva användare och sen försöka sätta dig in i hur de skulle använda sig av systemet. Detta tenderar dels att göra testningen mer effektiv då du ofta kommer på nya infallsvinklar du inte har tänkt på tidigare när du endast har testat ”som dig själv” och dels kan det bli lite roligare att både skriva personas och sen testa utifrån dem. För att skapa personas som skall användas vid utforskande test (eller i något annat sammanhang) är det vettigt att ta hjälp av andra inom din grupp, dels för att inte få allt för likformiga personas och dels för att det ofta är lättare att komma fram till ett vettigt resultat när man är fler. Du kan med fördel ta med verksamheten i skapandet av dina personas för att göra dem mer realistiska.

I många fall kan det vara svårt för en ensam person att veta exakt hur slutkunderna faktiskt använder företagets produkter, exemepelvis för produkter som inte riktar sig mot konsumentmarknaden utan mot mer specialinriktade branscher där det krävs mer specialkunskap för att få en förståelse för hur kunderna arbetar, så att få tillgång till information om hur användarna interagerar och jobbar med produkten skapar ofta mycket mer verklighetstrogna personas. Därför gäller det att dels förklara vad personas är samt hur de fungerar ifall det inte redan är känt. Det är viktigt att klargöra att en persona inte kommer bli lika bra ifall den hittas på utifrån tomma intet. En möjlig väg att gå för att få mer input till eventuella personas är att försöka få med sig kravavdelningen. De har förhoppningsvis en uppfattning om slutanvändarna samt kan i vissa fall även ha en del kontakter ute hos slutanvändarna som skulle kunna användas. Detta kommer garanterat ge bättre input till testaren vid skapandet samt användningen av dem.

Jag har arbetat i utforskande test-team där vi med framgång skapat en rad olika personas som användes i det dagliga testarbetet. Dessa personas var relativt simpla men underlättade testarbetet. Det visade sig lättare att hitta flöden genom mjukvaran att testa i och med att vi lättare kunde sätta oss in i hur samt vilka delar av mjukvaran olika kunder använde sig av samt i vilka sammanhang.

Definiera mål

Ett annat sätt att angripa de identifierade problemen är att sätta upp och definiera mål för resultatet av testningen då ett av problemen med utforskande test vanligen är just avsaknaden av klara och uppenbara mål. Det kan helt enkelt vara svårt att riktigt veta när man har testat klart alla gånger, förutom den uppenbara delen att tiden för ens testsession gått ut. Att sätta upp egna mål kan därför vara ett sätt att motivera sig själv. Ett mål kan exempelvis vara att försöka hitta X antal fel eller vissa typer av fel och sen verkligen koncentrera sig på att hitta just dessa typer av fel.

Här är det dock viktigt att inte snöa in sig på en enda typ av fel utan att hela tiden försöka hitta olika typer av fel vid varje testsession. Det är dessutom inte med nödvändighet någon bra idé att som organisation sätta upp mål gällande antal fel som ska hittas och andra liknande aspekter. Bara för att man inte hittar några fel vid en utforskande test-session behöver det inte betyda att testaren har gjort ett dåligt arbete – att inte hitta några fel alls är ju även det ett resultat, även om det inom utforskande test ofta lätt kan ses som ett litet misslyckande. Däremot är det ju inget som hindrar en från att ha små tävlingar med sina medarbetare ifall de andra finner det roligt och motiverande.

Feedback/debreifing

Att få veta att någon är intresserad av att höra vad man gjort höjer nästan alltid ens motivation och tyvärr blir det i många projekt endast felrapporterna som är intressanta för organisationen att ta del av. Därför kan det vara en mycket bra idé att ha Scrum-liknande debreifingmöten där enbart testarna är med, om inte varje dag så åtminstone några gånger i veckan, där varje testare precis som vid dagliga scrum-möten går igenom lite kort vad som gjorts – vad som är testat och vad som inte är testat – samt vilka fel som hittats och så vidare. På detta sätt får både testledaren och de andra testarna en bra uppfattning om vad som testats av och vad som fortfarande är kvar att testa. Det kan även ge uppslag till nya områden för dig att testa eller hur något ska testas då en annan testare kan besitta kunskap om något som du själv jobbat med.

Specialtester/hotfixes

Ett område som utforskande test ofta glänser på är när det kommer till att snabbt testa av ”panikfixar” eller väldigt sent integrerad funktionalitet. Här gäller det att få organisationen att förstå att det är de utforskande testarna som troligen är bäst lämpade för att snabbt lusa av mjukvaran och hårdtesta den. I och med att inga testfall skrivs vid utforskande test är det ofta en användbar teknik när funktionalitet tillkommit sent eller om systemet fått en uppdatering som behöver verifiras då det ofta är bråttom att testa av buggrättningar som skall lösa ett kritiskt fel dagarna innan (eller efter) produktionssättning. Problemet med att ingen högre upp i organisationen direkt bryr sig om vad man sysslar med brukar också lösa sig själv när uppgifter av detta slag kommer. Ofta står cheferna och leveransansvariga mer eller mindre och hänger över axeln på testaren när mjukvaran testas i en sådan här situation. Försök därför alltid vara noga med att förklara och visa att utforskande test är det bästa sättet att testa av systemet i en sådan situation då de trots allt brukar dyka upp ganska ofta hos de flesta företag.

Hos en kund jag var hos blev vår utforskande testning efter en tid ganska känd bland utvecklarna. I och med att en utvecklare hade upplevt att vi snabbt och effektivt hade testat av dennes hotfix började ryktet snart sprida sig till andra delar av organisationen och fler ville få samma nytta och resultat. Självklart går det ju inte alltid att hoppas på att ett rykte ska generera mer testuppdrag på det sättet som det gjorde för oss, så försök därför själv få till ett test där till exempel en hotfix testas av med både utforskande test och via traditionell testning och jämför sedan antal hittade buggar, tid för exekvering samt testtäckning. Självklart kan det vara svårt att jämföra utforskande test och traditionell testning rakt av i och med att testtäckningen lätt blir väldigt olika samt att tiden att testa av med traditionell testning varierar oerhört beroende på om det redan finns skrivna testfall eller inte och man får därför inte stirra sig blind på antal hittade buggar eller vilken tid det tog. Att ha med så många parametrar som möjligt hjälper till att påvisa en skillnad mellan de olika testerna och de ovan nämnda parametrarna antal buggar, tid för exekvering och testtäckning tillsammans med exempelvis generell känsla av kvaliteten på mjukvaran kan vara bra att ha med. Har man sen effektivt testat av ett antal snabbfixar brukar beställningarna på nya snabbtester börjar rulla in av sig själv.

Sammanfattning

Att få till både lyckad och rolig utforskande test för både organisationen och testaren kräver mycket arbete för båda parter. Ju mindre intresserad organisationen är att ta del av testarens arbete, desto hårdare måste denne jobba med att själv få ett givande och roligt testarbete. Har företaget en hög testmognad med god insikt i vad som krävs för att få utforskande test att fungera kommer många problem att lösa sig utan att testaren själv hela tiden måste försöka få chefer och medarbetare att intressera sig för testrapporter och analyser.

Det gäller att som testare inte ge upp utan fortsätta att skicka ut testrapporter och komma med viktig input i dessa. Exempel på sådan input som organisationen kan finna intressant är till att börja med vilka områden som testats samt inte testats av och vilka fel som hittats. Ytterligare input som är bra att ge är vilken känsla testaren har av mjukvaran – även om inga direkta fel hittats i mjukvaran betyder det inte att den är redo att skeppas ut till slutkund och en av fördelarna med utforskande test är just att testarens bedömning angående kvalitén kan tydliggöras. Det är mycket möjligt att kraven är helt och hållet uppfyllda men att dessa i sig inte är tillräckligt genomarbetade vilket därmed kan skapa problem ute hos kund. Subjektiv input från enskilda personer får förvisso sällan gehör med en gång och därför är det bra att kunna peka på tidigare testrapporter som tar upp just sådana åsikter ifall det visar sig att problem som kunder upplevt faktiskt hittats av en testare i ett tidigare skede. Görs detta på ett korrekt sätt kommer förhoppningsvis projektledning, utvecklare samt testare på andra avdelningar att börja intressera sig för vad testaren arbetar med om dagarna.

Ifall utvecklarna märker att de utforskande testarna är snabbare på att testa av till exempel buggfixar är det stor chans att de kommer börja vända sig till just dem för att få hjälp. Det är heller inte omöjligt att testare på andra avdelningar börjar intressera sig för att använda utforskande test ifall de uppmärksammar att det är ett effektivt arbetssätt som snabbt ger resultat. Jag har bland annat arbetat i ett utforskande test-team hos en kund där utforskande test visade sig så pass effektivt att kunden bestämde sig för att låta utforskande test bli det huvudsakliga tillvägagångssättet för deras mjukvarutestning. Tidigare kände de att allt för många områden inte höll tillräcklig kvalité då ingen riktigt hade testansvar för dem. Vårt ansvar blev att med hjälp av utforskande test snabbt täcka upp dessa områden, vilket i slutändan visade sig vara en väldigt lyckosam satsning.

Så slutligen – glöm inte de enkla åtgärderna du kan göra!

Bjud in till korta debreifings där testområden, testtäckning, fel samt den allmänna känslan av mjukvaran presenteras.
Definiera mål, exempelvis vad målet är med testsessionen. Det kan exempelvis vara ett speciellt fel som tidigare observerats som nu ska återskapas.
Anordna inofficiella tävlingar inom testavdelningen där testarna tävlar om vem som hittar den allvarligaste buggen, flest fel, konstigaste buggen eller liknande. Detta kan ibland vara ett roligt sätt att göra testningen mer kreativ samt öka gemenskapen men det får inte upplevas som ett tvång eller ett mål i sig.

Läs allt om kurserna på inUse Academy här!