Vanliga frågor om Agil testning

Här hittar du svaren på de vanligaste frågorna vi får kring agil testning och hur du jobbar med förbättringar i system, arbetssätt eller i utvecklingsprocesser.

Har du någon fråga du skulle vilja ha svar på, ställ den i chatten här nere till höger så svarar vi så snart vi kan.

Frågor & svar

    • En "testare" kan ha lika många definitioner som det finns ... Ptja, testare. Du som testare, vad behöver du kunna för att göra ett bra jobb i just ditt sammanhang? Vad behöver du kunna för att lösa dina problem, och för att kunna hjälpa ditt team på bästa sätt? 
       
      För att vara lite mer konkret, och inte bara komma med motfrågor, så kan jag säga att jag har haft väldigt mycket nytta av att kunna programmera. Det underlättar mitt eget arbete, då jag lätt kan behandla utdata från loggfiler, databaser eller dylikt för att hitta information. Det ger mig också möjlighet att till exempel skapa testdata och automatisera upprepade eller tidsödande uppgifter. Dessutom blir det lättare för mig att förmedla problembeskrivningar till övriga programmerare i mitt team då jag kan peka ut exakt den kodrad som är felaktig, föreslå en konkret lösning, eller till och med bidra med egna buggfixar. 
       
      Ju mer du kan, desto roligare kommer du att ha! Det finns ingen anledning att inte lära sig programmera - eller något annat, för den delen! 

    • Någon form utav mindmap och att lära sig åtminstone ett skriptspråk att använda. Använder du en mindmap när du testar eller planerar din testning så kan du i praktiken lämna över den till en utvecklare där kan de följa precis vad du har gjort grafiskt, utan att behöva läsa 14 A4-sidor med dokumentation. Se var det small och få länk till buggrapporten. Allt blir mycket mer förståeligt och övergripligt. Notepad++ gillar jag och Xe Max kan man göra bra macron i. Sen använder jag alltid något clipboard-verktyg.  
       
      Att använda samma agila tavla som resten av teamet/kollegorna/bolaget gör underlättar. Om ni har något verktyg som folk använder och tittar i, då finns det ingen anledning att ta in ett nytt eller parallellt verktyg. Konkreta tips, om ni inte redan har något verktyg: Asana eller Trello.

    • Man kan närma sig utvecklare på olika sätt beroende på hur deras personligheter är. Jag tycker inte att det finns någon egentlig färdig process för det här men den enskilt största framgångsfaktorn för mig är att närma mig utvecklarna och att erbjuda mig att sitta med dem och testa under en period så fort de har någonting testbart. 
       
      Prata med utvecklarna, vara med utvecklarna, var bredvid utvecklarna, fråga hur det går. Och ställ frågan, när har du någonting känn- och klämbart. Och då kan man sitta tillsammans och testa, kanske bara en kvart, halvtimme, kanske en hel timme. Och med lite tur då så kan jag skruva in olika testtekniker som jag kan och utvecklarna tycker att det är jättekul att lära sig någonting nytt där också. Och hittar man mycket buggar så brukar det vara lättare att ta sig närmare utvecklarna, för de ser själva värdet av att man faktiskt kan hitta det tidigare då. 
       
      Sen får man vara ganska lyhörd också, för att vissa utvecklare vill periodvis sitta koncentrerat och tänka själva och då måste man låta dem göra det, så man får personanpassa det lite grann faktiskt. 

    • Absolut, det finns stora fördelar att ha någon som aktivt driver kvalitetsarbetet. Tyvärr brukar det ofta vara så att ”allas ansvar blir ingens ansvar”, varför det är väldigt positivt att ha någon som driver frågan både inom teamet och mot övriga delar av organisationen. Detta ska dock inte förväxlas med att det är en person som ska ansvara för att arbetet blir gjort. Men det blir definitivt mer gjort i frågan om någon är drivande!

    • Det finns naturligtvis flera sätt. En variant som jag har provat med viss framgång, det är att hitta den utvecklaren i teamet som de andra utvecklarna ser upp till lite grann. Och vinner man över de personerna så har man en ambassadör i teamet, för att driva test på ett annat sätt och att bry sig om kvaliteten på det man gör. 
       
      En annan variant som jag brukar köra är att man sätter upp ett forum, QA-forum, som då helt enkelt består av någon person från varje team, där man ses regelbundet, kanske en gång i veckan, en timme. Diskuterar teamens utmaningar och problem och sen så får den här personen gå tillbaka till teamet och jobba och så stöttar man samtidigt. 
       
      Det bästa är ju att kunna sätta sig i teamet och hjälpa till hands-on där man är. Men då blir det ett team åt gången och kan det kan ta ganska lång tid innan man har gått igenom alla om man har en fem, sex team. Så att om man kan jobba med den tekniken parallellt med att man har sina små ambassadörer från ett QA-forum som förbereder lite grann och jobbar på tycker jag är en ganska kombination. 

    • Det är på något sätt som med den här frågan kring agila releaser och business. Grejen med release management är att det kan finnas regulatoriska krav och sånt som gör att det kanske inte går helt enkelt att bara skjuta ut saker utan att ha koll på det. I Jira till exempel kan man ha "Request for change"-issues kopplade till sin release. Man vill fortfarande ha koll och det är bra att ha koll. 
       
      Men release management kommer också att behöva vara med lite mer. I fallet med Jira handlar det mycket om att, inte direkt automatisera men det är svårt att manuellt med dokument ha koll på allting. Man behöver någon form av verktygsstöd.

    • Om du med "definition of ready" menar "när är det här dokumenterade kravet i så pass skick att jag som medlem i teamet kan börja implementera en lösning i tron att den kommer att leva upp till förväntningarna?" så är svaret teamet. 
       
      I en agil värld har du ofta återkommande sessioner där teamet går igenom kraven i backloggen tillsammans med produktägaren för att räta ut eventuella frågetecken och se till att alla är överens om vad som ska göras, varför det ska göras, och hur vi tillsammans gör slutanvändaren nöjd och glad med leveransen.

    •  Är det så att man lever i en värld där man faktiskt har krav, är det ju positivt bara det. 
       
      Normalfallet när man gör utforskande tester skjuter man inte bara från höften och hoppas att man hittar någonting. Det finns oftast en plan, i någon typ av mindmap eller liknande. Så planen utgår ifrån produkter och feature man testar och de eventuella krav som finns. 
       
      När jag ska testa någonting sånt här, brukar jag bygga en mindmap. Antingen i förväg eller så bygger jag den längs vägen. I mindmapen kan jag on the fly skriva in vilket krav jag har testat emot, om det uppfyller det eller inte. Och fördelen med att ha digitala mindmaps är att den går oftast att koppla på något sätt, t ex direkt via länkar vidare till Jira eller annat system man använder för att lägga upp eventuella buggrapporter. 
       
      Det i sin tur är kopplat till ex Confluence där man har sina krav om man inte har dem i Jira. Så det går att göra det här ganska transparent och enkelt se hur kopplingarna ser ut och huruvida man har faktiskt uppfyllt dem. 
       
      Men man behöver inte göra massa förvägsjobb utan kan gör det medan man testar och ser till att det stämmer. Fast man bör ha kraven framför sig, om man vet vilka som finns.

       

    • Självklart finns det metoder som hjälper till med detta. Ett sätt är att involvera testarna tidigt, redan i kravställningsfasen genom metoder som Acceptans Test Driven Development. Det ger samtliga roller en möjlighet att diskutera lösningen och förväntat beteende innan utvecklingen påbörjats för varje enskilt krav. Man kan då börja utforma testerna redan innan det går att testa. 
       
      Att testa varje krav efter att de kodats färdigt är också en möjlighet, då man kan ange att Test blir ett steg innan definition of done är uppfyllt. Då kan testare börja testa innan ett helt bygge är färdigt vilket är helt klart att föredra i en agil miljö. Beroende på testarnas tekniska kompetens kan man också köra parprogrammering med testare och utvecklare tillsammans, men det är en metod som är lite mer kompetenskrävande.

    • Ju tidigare desto bättre. 
       
      Ett krav utvecklas precis som allt annat i den agila världen, och som kravare är det bra att involvera olika personer längs resan. I början är det ganska fluffigt och kanske mest specificerat av de ursprungliga intressenterna. I takt med att du som kravare börjar diskutera kravet med andra intressenter, eller att kravet prioriteras av produktägaren inför en närliggande sprint, så är det dags att involvera testare. 
       
      Jag har märkt att testare brukar komma med väldigt nyfikna och relevanta frågor så de är duktiga på att hjälpa till att identifiera "edge-cases". En annan sak som är bra med att involvera testare tidigt är att de kan bryta ner en större story i mindre testbara delar, så teamet lättare hittar MVP och kan testa en avgränsad hypotes i taget. Ibland behövs det tas fram nytt testdata eller så kan man bara testa i vissa testmiljöer och detta är viktigt att identifiera innan utvecklingen påbörjas, så detta inte blir onödiga förseningar och missförstånd.

    • Åh, det är en rolig fråga. Det hade jag lätt kunnat ägna en timme åt, bara den frågan. 
       
      De gånger det har faktiskt flutit på väldigt bra är när jag har suttit ner och parkodat med en utvecklare. Vi två har satt oss ner och skrivit featurekodan och sen testkoden och vi har skrivit på enhetsnivå och sen på indikationsnivå. Och om det är något litet och lätt, kanske vi kan trycka ut det i produktion direkt och se att det faktiskt är klart och ute på de tre timmar vi har suttit tillsammans vid skrivbordet. Då får man in alla momenten väldigt naturligt och enkelt och det brukar vara väldigt lätt för utvecklarna att fortsätta jobba så sen. 
       
      Sen måste de få ta ansvar för när de släpper inte så bra grejer. Om det kanske gäller något mindre kritiskt så kan man kan få lite mer trial and error. Teamet måste tillåtas att misslyckas ibland för att ta sig framåt.

    • Ja, de gånger jag har jobbat med microservice:ar så har det varit förvånansvärt tillförlitligt faktiskt av någon anledning. Man har en skog av microservice:ar och ändå så lirar det ganska bra. Den största svårigheten jag har stött på, det är det här med att ha koll på versionen av microservicen och versionen av API:et i microservicen. Och hur bakåtkompatibla de här API:erna är och så vidare. 
       
      Det är väldigt mycket en konfigurationsfråga. Om man använder Kubernetes till exempel så finns det stora konfigurationsfiler där som syr ihop allt det här. Jag brukar försöka påverka teamen och säga att håll allting bakåtkompatibelt, kom inte med major-förändringar stup i kvarten på era microservice:ar. Det absolut värsta är nog att någon gör en major-förändring men uppdaterar inte major-siffran i versionshanteringen. Då kan det bli väldigt svårt att få ordning på det. Det är det jag framför allt kommer att tänka på. Sen finns det väldigt mycket man kan prata om här men det är nog det främsta. 

    • Det här svaret kommer från någon som inte är expert inom SAFE, så det kanske inte besvarar all din nyfikenhet. Det som är så fantastiskt med en agil värld är att du kan kräva precis vilken dokumentation som helst. Agilt innebär inte "ingen dokumentation" eller ens "lite dokumentation". Om något innebär det "tillräcklig dokumentation". 
       
      Mitt generella tips är att inte överdokumentera, och att hålla all dokumentation så nära där den behövs som möjligt. Om kraven är skrivna i Jira så är det väldigt praktiskt att även ha testdokumentation i Jira. Det kan vara ett eget länkat ärende, en kommentar, en bifogad fil - allt beroende på behov. Det kan vara ett väldigt detaljerat steg-för-steg-testfall, generella tips och tricks kring hur något ska eller bör testas, eller en rapport från en utforskande testsession om hur något faktiskt testades. 
       
      Confluence och Jira, till exempel, är ju också lättintegrerade med varandra - och förhoppningsvis även med den versionshanteringssystem du valt, så att spårbarhet till själva källkoden och dess enhetstester finns bara ett musklick bort. 

    • Jag tycker definitivt att det finns en plats för användaracceptanstester, även inom de agila testramarna. För att det är ju så att man ska inte bara göra sakerna på rätt sätt, man ska göra rätt saker. Och sista chansen att validera det, det är egentligen om man har en UAT på slutet. Den bör gå i någon typ av miljö som är lite helig, väldigt produktionslik, där man inte släpper ut skräp, använder som någon sån här sandbox-miljö och testar andra saker i. 
       
      Det kan vara så att man har dedikerade perioder där man helt enkelt har en stabil miljö och så vidare som alla får jobba i med lite direktiv, lite styrning upp till en viss nivå och se till att om det behövs specifik testdata att finns den på plats och så där. För man vill ju ha ett okej från business att det här var faktiskt det som stakeholders:erna ville ha och det ser ut på det sättet de ville ha. Funktionaliteten bör teamet ha stämt av redan innan så det är mer att det här är affärsvärdet vi levererar. Och det finns definitivt en plats där, inte för alla features man gör men för större förändringar. Är det här någonting som vi behöver en UAT, en acceptanstest på, ja eller nej. 
       
      Så ja, jag skulle säga att det finns en plats fortfarande. 

    • Det är ett sånt där svar som man kanske inte vill ge - det beror ju helt på hur testledarrollen ser ut i dag hos de olika organisationerna. 
       
      Men tittar vi på testledare i ett agilt team så tror jag inte att den rollen kommer finnas kvar, utan testledaren kommer bli lite spindeln i nätet. Den personen som tittar på vad som kommer i framtiden och som synkar mellan teamen. För jag tror att rena testteam kommer försvinna, det vill säga grupper av QA. 
       
      QA och test kommer gå ut i teamen och testledaren, om den finns kvar, kommer vara en coach. Den som tittar på gemensamma verktyg, gemensamma processer, synergieffekter och så vidare. Sen kommer nog testledarrollen att fasas in i andra, kanske managementroller. Och som min kollega Amanda sagt blir det kanske så att man tittar mer på agila processer än på test, för att test som sådant kommer att bakas in i kvalitetstänket och de aktiviteter man gör för att helt enkelt öka kvaliteten på det man producerar. 
       
      Men det är ingenting som händer över en natt, utan kommer nog ta ett par år. Så att testledarrollen kommer finnas kvar i någon färg och form ganska länge. 

    • Jag tycker personligen om att engagera teamet - och gärna även andra intressenter - i att klämma och känna  produkten under mer eller mindre ordnade former. Vi kallar det för testsessioner, "mob testing", testfest, "bug bash", eller något annat käckt som passar in i det lokala språket. Jag som testare - eller utvecklare med testintresse, eller övergripande kvalitetscoach, eller något dylikt - kan hjälpa till med det administrativa; fixa en testmiljö med relevant data, boka tid och plats, dokumentera arbetet, lista testidéer och infallsvinklar på en whiteboard. 
       
      De flesta, även de mest skeptiska programmerarna, brukar uppskatta att faktiskt få sätta på sig en användares glasögon i en timme och försöka lösa ett verkligt problem med hjälp av sin egen produkt. Många idéer och funderingar kring användarvänlighet och dylikt brukar dyka upp ganska snart.

    • Den största förändringen som behöver ske handlar om kommunikation och samarbeten mellan olika roller. Att få de olika kompetenserna att samarbeta närmare i sitt dagliga arbete är en nyckel för att lyckas. Då agilt snarare är en kultur än en process så handlar det om att fostra en sådan kultur i hela organisationen. Detta gäller inte minst i chefsledet då dessa måste gå från att vara styrande chefer till faciliterande ledare, två begrepp som är väldigt olika. Det är viktigt att införa förändrignarna i små bitar åt gången. 
       
      Man kan börja genom att införa en ny metod ”by the book” och sedan med tiden förändra den till att bli mer och mer anpassad efter organisationen och produkten genom att förändra de bitar av process/metod som inte är värdeskapande och fokusera på de bitar som faktiskt genererar värde mot slutkund. 
       
      Även att börja titta på att kunna göra releaser oftare fast med mindre scope kommer hjälpa er på vägen. Självklart är detta väldigt produktberoende och i vissa regulatoriska miljöer svårt att tillämpa fullt ut. 

    • Jo, men de är viktiga, framför allt mindre och oftare, då är det bra att ha automatiserade regressionstester. Det känns lite som en förutsättning. Och finns det en regressionstest som körs med automatik vid varje release så känns det tryggare att releasa också, då vågar man releasa. 
       
      Utvecklarna blir tryggare också naturligtvis. Sen brukar det vara så, enligt min erfarenhet, att ibland släpper man lite större initiativ. Och då kan vi även ha kanske en manuell testsession. Men svaret är att det är viktigt.

    • Ja, om fem år kommer det fortfarande, tror jag, vara en väldigt stor spridning. Men om vi ser de som i dagsläget har kommit en bit i sin agila resa och kommer fortsätta den så tror jag att det kommer vara ännu mindre roller. Och det kommer nog vara mer att man är utvecklare i ett team och man kanske har lite mer fokus på test men man kommer nog förväntas göra mera saker än bara testa. 
       
      För i och med att utvecklarna också tar ett större ansvar för kvaliteten, vilket man behöver göra i ett agilt projekt, så har jag svårt att se att det kommer behövas en heltid som bara jobbar med test. Så man kanske kan kombinera det med scrum master eller utveckling eller miljöer eller testdata. Om man vill nischa sig genom QA kanske man kan bredda sig emot … ja, säkerhet eller prestanda. Eller ta något mer ansvar. För jag personligen har svårt att se att man kommer att sitta som heltid testare om fem år.

    • Eftersom det finns många olika typer av kvalitetsäkringsåtgärder som kan utföras av andra än testare kan man se till att teamen tar sitt ansvar genom att göra så mycket som möjligt innan det blir dags för system- och acceptanstest. 
       
      Flera olika metoder som hör till olika testnivåer går att tillämpa. Allt ifrån att man samarbetar med kravframtagning och skriver acceptanskriterier tillsammans (tex. genom Acceptance Test Driven Development), eller att ha kodgranskningar, använda sig av statisk kodanalys-verktyg, tillämpa parprogrammering och i bästa fall även testdriven utveckling (se Test Driven Development), till att teamen automatiserar integrations- och systemtester så kan många defekter fångas innan de når systemteststadiet. Då kan man fokusera på utforskande tester och i slutändan även ta hjälp av kunder eller kundrepresentanter inom organisationen för att utföra acceptanstester. 

    • Jag tror att de största fallgroparna är när man introducerar agil testning. Agil testning är helt enkelt att flytta kvalitetsarbetet längre till vänster - shift left. Där ingår aktiviteter som kanske inte är ren testning t ex code reviews och man har kanske en övertro på att det går väldigt fort att introducera det. 
       
      Men det här är frågan om ett kulturskifte. Därför är den största fallgropen helt enkelt att man har för bråttom, man tror att det kommer gå fort och att alla kan testa. I viss mån, ja, men det är frågan om skillset och mindset, alla kanske inte har viljan och den typen av förtrolighet att man kan bli en bra testare. Så man måste bygga kulturen och det tar tid. Och det är första steget - att låta det ta den tiden som behövs. 
       
      Sen finns en övertro i automatisering, att man kan automatisera allt. Man trycker på den gröna deploy-knappen när man skrivit sin kod och så kommer det ut i produktion och alla är glada och lyckliga. Det kommer finnas steg där emellan som tar tid att jobba bort, som fortfarande kommer vara manuella och som behövs jobbas in. 
       
      Så att jag tror att ett visst mått av övertro och ett visst mått av att man har för bråttom, det är de största fallgroparna.

    • Det finns jättemycket olika sätt att hantera det här. Ett sätt som var nytt för min del, på nuvarande uppdrag, var att om ett team bygger ett API som mitt team ska konsumera så är det mitt teams ansvar att gå in och skriva API-tester i det andra teamets kodbas, så att de hela tiden är fria att uppdatera så länge deras regressionstester går igenom. Det tycker jag var väldigt smidigt, för vi får precis den säkerheten vi behöver för att använda API:et och de har full frihet att uppdatera det när de vill. Så att det var en väldigt trevlig upplevelse för min del. 
       
      Annars kan det lätt bli så trassligt och omständligt och varje version ska hanteras och kollas av med stakeholders och så där men det fungerade väldigt smidigt. Och om det inte är ett så enkelt case, som API och klient. Kanske båda ska skriva lite klientkod och så, då tror jag mest på att prata med varandra. Utvecklarna i teamen, testarna etc. Några intressenter i varje team får helt enkelt sätta sig ner och prata och sätta en gemensam plan för hur man ska göra det här. 

    • Agilt är ju ett arbetssätt på hur man utvecklar i mindre iterativa steg. Sen att det kanske inte kommer ut direkt i produktion, det är en annan sak. Så det finns stora vinster med den agila processen utvecklingsmässigt, oaktat det. 
       
      Att man inte lämnar över saker i flera led nedåt, utan alla är med på tåget under utvecklingen. Test kommer in tidigt, kravarna är med, business är med och så vidare. Så att den processen är superbra. Sen vill man naturligtvis få ut det där ganska fort också så att man ser att det faktiskt lirar. Har man inte den möjligheten så är det lite olyckligt men det skulle inte stoppa mig från att genomdriva att man har en agil utvecklingsprocess. För det är lite två olika saker ändå. 

    • Absolut nummer ett för att få utvecklare att lämna ifrån sig delmål är att aldrig någonsin straffa en utvecklare som lämnar ifrån sig ett delmål. För att om de upplever det som negativt att lämna ifrån sig delmål så kommer de att sluta göra det. Utan jag brukar göra som tvärtom, att upptäcker jag problem så då lägger jag ner kanske en timme om dagen eller något att hjälpa utvecklaren. Utvecklaren kanske behöver hjälp med att hitta testdata, hjälp att utföra tester, hjälp med vad som helst. 
       
      Alltså, straffa aldrig utvecklarna för det de gör, faktiskt. det måste bli en positiv cirkel. Det här förutsätter då att jag över huvud taget kan och får närma mig utvecklarna, att det finns en väg in, att jag kan sitta bredvid dem och prata, ha en kommunikation. Se till att det är positivt för utvecklaren att du finns där. 

Vi som svarat på frågorna

Jan Sahlström

Jan Sahlström

CONTINUOUS, AUTOMATION, LEDNING & COACHNING

Jan är senior inom QA och har bred erfarenhet av mjukvaruutveckling. Han brinner för processförbättringar som skall underlätta för teamen samtidigt som det ska ge en kontinuerlig leverans av högkvalitativa lösningar.

 

Jan på Linkedin

Amanda Johansson

Amanda Johansson

CONTINUOUS, AUTOMATION

Amanda har stor erfarenhet att förbättra processen och anpassa test till den aktuella situationen och då med fokus på CI/CD processen och automatiseringen. Hon arbetar alltid med ett starkt målfokus och är bra på att prioritera.

 

Amanda på Linkedin

Stefan Nerby

Stefan Nerby

CONTINUOUS, AUTOMATION, LEDNING & COACHNING

Stefan är en erfaren testare inom mjukvara som kan planera och utföra funktionella tester från ax till limpa helt självständigt eller i grupp. Han är van att agera användarnas företrädare samt att förmedla projektets val och prioriteringar.


Stefan på Linkedin

Per Almström

Per Almström

CONTINUOUS, AUTOMATION

Ett livslångt teknikintresse och en medfödd nyfikenhet har skärpt Pers sinne för problemlösning. Han har en bred erfarenhet av test inom olika roller, faser och branscher, från tekniknära tester till bland annat prestandaingenjör.

 

Per på Linkedin.

Alixander Ansari

Alixander Ansari

KRAV, LEDNING & COACHNING

Alixander har flera års erfarenhet från fordonsbranschen samt erfarenhet från alla nyckelroller såsom testare, testledare, CM, integration, automatisering & processer. Han är en driven och ambitiös ingenjör med passion för problemlösning.

 

Alixander på Linkedin. 

Behöver ni hjälp med test eller
vill bli agila?

Oavsett om ni är i behov av nya teststrategier, vill sätta igång med testautomatisering, vill tillämpa Continuous för en snabbare produktionstid eller är under omställning till ett mer agilt arbetssätt så kan vi hjälpa dig!

Vi har testare och agila coacher med många års erfarenhet och med stor vana att vägleda
efter behov, förutsättningar och mål. 

Vill du veta mer om hur vi kan hjälpa dig baserat på er situation?

Våra senaste inlägg om Test

Vad är Low Code/No Code?
Lästid: 9 min

Vad är Low Code/No Code?

Läs mer
Vad är teknisk skuld?
Lästid: 5 min

Vad är teknisk skuld?

Läs mer
Det här ska du tänka på när du testar produkter inom Medtech
Lästid: 12 min

Det här ska du tänka på när du testar produkter inom Medtech

Läs mer