Agil test - Vilka utmaningar får du?

2011-10-20 Artikelbanken Test Läst 13406 gånger

När vi vill prestera på en högre nivå eller producera högre kvalitet räcker det inte med att tillämpa nya tekniker eller verktyg utan vi behöver även ändra vårt arbetssätt; hur vi organiserar arbetet och hur teamet samarbetar. Ett arbetssätt som ofta diskuteras och värderas högt inom systemutveckling är agil utveckling. I resten av artikeln kommer vi att diskutera hur en testare kan hitta sin plats i den agila världen och det motstånd som kan upplevas, för att avsluta artikeln med ett förslag på hur man kan påbörja sin agila ansats.

IT-utvecklingen har historiskt sett kopierat och lånat många processer och arbetsmetoder från industrin, med fokus på hårt styrda och detaljerade processer och optimerad logistik. Detta tankesätt passar självklart fabriksproduktion väldigt bra och har även lett till en förbättring av systemutvecklingsprocesserna inom IT-industrin med större framgångar i många projektleveranser. Tyvärr är det dock fortsatt mycket kvar att göra. Inom IT-utveckling arbetar vi med kreativt skapande och har därmed vårt tänkande som främsta verktyg. Detta kan jämföras med att vara hantverkare istället för linjearbetare. IT-utveckling är dessutom mer beroende av lagarbete och kommunikation mellan grupper av människor som inte talar samma tekniska språk, det vill säga verksamhetens språk och utvecklarnas språk. Agila värderingar är ett försök att höja prioriteringen av dessa problem. Den tekniska lösningen som ska levereras blir inte perfekt om inte de mjuka värdena också tas om hand.

I artikeln Är agilt så bra som vi alla säger av Konsultbolag1, framfördes påståendet att agila arbetssätt mer är en kultur och ett tankesätt än en process eller utvecklingsmetodik. I många projekt och förvaltningar som drivs agilt har fokus varit att introducera nya tekniker och metoder utan att fokusera på de agila värderingarna av samarbete och kommunikation. Beror detta på att arbetssättet är fel eller finns det andra bakomliggande problem?

Agilt och testaren, och varför det är svårt

När du går in som testare i ett agilt team så har du ett antal utmaningar att möta för att du ska kunna hjälpa teamet att bli så agilt som möjligt och få till ett effektivt och kvalitativt bra arbetssätt. Utmaningarna är att allt inte finns dokumenterat när du påbörjar ditt testande, att det kan upplevas som att det inte finns tid för tester och att mängden regressionstester växer kraftigt med varje iteration samtidigt som du kanske känner dig hotad i din profession. Det kanske känns som att ditt jobb ändras totalt i form eller till och med att du blir överflödig.

Testa utan dokumentation

En värdering i det agila manifestet är ”Fungerande mjukvara framför omfattande dokumentation”. Det betyder inte att vi ska sluta dokumentera utan istället använda dokumentation som ett verktyg för att nå målet, det vill säga en fungerande mjukvara, istället för att dokumentationen är ett mål i sig. Det finns självklart dokumentation som behövs för systemets fortlevnad och förvaltningsbarhet såsom användardokumentation och systemdokumentation, men frågan du behöver ställa dig är vad som behövs under arbetets gång. Det ni behöver fokusera på är att lösa hur kravställarna kommunicerar sina behov och krav på ett enkelt och effektivt sätt och hur dessa sedan tas om hand för att skapa en fungerande mjukvara.

Agil utveckling kan många gånger vara ett större steg för testare än för utvecklare. Hur ska vi kunna testa och avgöra vad som är rätt eller fel beteende om det inte finns dokumentation? I en agil miljö kommer kraven från diskussioner med användare och det är en förutsättning för att kunna leverera fungerande mjukvara att testare deltar i dessa diskussioner. Krav formuleras som användarberättelser och användningsfall som tas fram av teamet. Som testare är du dessutom ansvarig för den dokumentation av systemet som tas fram i form av olika testdokument, oavsett om det är i form av testspecifikationer, testloggar från utforskande testning eller testidéer som sedan återanvänds för regressionstester. Dessutom växer kraven fram under utvecklingens gång i enlighet med det agila tankesättet sprunget ur att man inte kan tänka på allting på en gång eller ens vet allt tidigt i arbetet. Som testare kommer du själv ta fram krav under tiden du sitter och testar allt eftersom du förstår hur systemet är tänkt att fungera. Detta faktum i sin tur medför att det blir lättare att delta i designdiskussioner och på så vis bidra till att stoppa införandet av defekter i ett tidigt stadium. Det blir dessutom lättare att snabbt sätta sig in i kundens behov.

Testa utan tid

Nästa frågeställning som du som testare måste ta hänsyn till är hur du ska hinna testa allting innan sprinten tar slut. Det enkla svaret är automatiserade tester kombinerat med tankesättet att du är en del av ett team där ni inte påbörjar något nytt innan det första uppdraget är klart. I agil utveckling är det viktigt att komma ihåg att teamet tillsammans bär ansvaret att leverera i tid och att leveransen inte är klar innan den är testad och godkänd. Det betyder att utvecklare hjälper till med tester på en eller flera nivåer. Det kanske till och med är så att utvecklingen sker med hjälp av testdriven utveckling, som oftast leder till förbättrad kodkvalitet genom förbättring i enhetstestningen.

Utvecklarna måste hjälpa till med utveckling av de automatiserade testerna, med att ta fram testdata, med testmiljöer och allt annat som får teamet att leverera i tid. Plötsligt är du som testare en viktig och naturlig del i teamet för att du har kunskap och erfarenhet av att utföra dessa uppgifter. När utvecklarna och du delar samma vision av ”klar” kommer ingen att tro att allt är klart bara för att kodningen är färdig. Sannolikt får även du som testare en bättre förståelse för de problem som utvecklarna möter dagligen.

Att vara en programmerande testare

Den tredje utmaningen som du som testare har att möta är hur du ska kunna jobba med automatiserade tester när du kanske inte är programmerare. Om du ska jobba med korta leveranstider (det vill säga korta sprintar) kan du inte komma ifrån automatisering av tester om du ska hinna med regressionstestning, och att utesluta regressionstestning är inte acceptabelt för en kvalitetsmedveten testare. Om detta kan du läsa mer i artikeln Utan automatiserade tester, ingen agil utveckling! på Faktabanken. För att skapa automatiserade tester krävs goda kunskaper i att designa testfall och den erfarenheten är det du som testare som besitter.

Utveckling av automatiseringskoden kan en utvecklare, om du inte är bekväm med det själv, antagligen hjälpa till med. Du kan även dela dina erfarenheter med utvecklarna för att hjälpa dem med att förbättra sina komponenttester och du har sannolikt redan pratat med slutanvändarna för att skapa bättre testfall utifrån deras behov. Om ni får automatisering på plats kan du som testare fokusera på de manuella testerna som behövs för den nyutvecklade funktionaliteten genom utforskande testning!

Sammanfattning

Det agila manifestet beskriver ett antal värderingar som anses som framgångsfaktorer i det agila arbetssättet. Det kan vara svårt att bli agil eftersom det kräver att vi ändrar hur vi samarbetar med andra i utvecklingsteamet och med kravställaren. De tre kanske vanligaste farhågorna för en testare när det gäller agila metoder visar sig också vara möjligheter, men det krävs att du angriper dem på ett medvetet sätt tillsammans med de medarbetare som ansvarar för kravarbetet respektive utvecklingsarbetet:

  • Dokumentationen – bara det som behövs, men absolut det som behövs
  • Tidsbristen – hela teamet arbetar tillsammans för att nå målet, och test kan ske både hos utvecklare och testare
  • Automatisering – ta hjälp av en utvecklare för att frigöra tid till att arbeta med utforskande test och acceptanstest

Startpunkt - Mätning och nulägesanalys

Vi har identifierad de tre huvudanledningarna till varför vi, som testare, står emot införande av agila metoder och värderingar i vårt arbete. Men om du är intresserad av att komma förbi dessa problem och i stället börja följa de agila värderingarna fullt ut på ett effektivt sätt är det viktigt att veta hur det ser ut just nu. Hur fungerar kommunikationen inom gruppen och vilken kultur har ni i ert team?

Vi har ofta mål i våra liv, men precis som med en vägkarta, om vi inte vet var vi befinner oss hur ska vi då kunna hitta den bästa vägen till målet? I arbetslivet finns det ofta ytterligare en dimension – vi måste visa för chefen att vi är på god väg mot målet och i enlighet med planen. För att kunna visa detta underlättar det om vi har ett mätetal, exempelvis ”vi vet att koden håller högre kvalitet än igår därför att vi har åtgärdat fem buggar och bara hittat en ny”. Vi måste välja ut mätetal som passar situationen och hjälpa oss utvärdera vår framgång. Om vi har identifierat att det största problemet är att vi inte hinner med allting inom en leverans då måste vi ta fram mätetal som är fokuserade på precis detta problem.

Men vi måste också tidigt i processen börja fundera över vad ”kvalitet” betyder för oss. Därefter kan vi försöka definiera mått och sätta ett värde på vilken kvalitet vi faktiskt har på systemet. Genom att definiera ”kvalitet” och hur vi ska mäta den får vi en bättre förståelse för vårt mål och kanske får vi också fler idéer om hur vi ska nå dit.

Nästa steg

Konsultbolag1 erbjuder hjälp med att genomföra en nulägesanalys av er verksamhet där vi tittar på hur väl anpassade ni är till de agila arbetssätten. Vi kan även göra den med ett speciellt fokus på test. Vid en nulägesanalys skapas en plan för vad som bör göras framåt och inkluderar framtagning av lämpliga mätetal så ni kan mäta er framgång. Om behov finns erbjuder Konsultbolag1 hjälp med själva införandet av agil test i er verksamhet.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln