Det finns många olika definitioner om vad agil testning är för något men samtidigt är det sällan man får ett svar som känns tillfredställande. För mig är det viktigt att skilja på test och agil testning. för mig är agil testning en aktivitet som kan utföras av alla, på olika sätt i alla led. För att utveckla begreppet agil testning så måste vi börja med att undersöka vad vi menar med agilt och vad vi menar med test.
Jag försöker se agilt som en ideologi, ett sätt att leva efter när man arbetar med mjukvaruutveckling. En del vill använda begreppet mindset eller kanske filosofi men jag tycker att ideologi passar bättre.
Ideologi är en samling idéer som utgör ens mål, förväntningar och handlingar. Ideologi är en vision oftast en utopi och ett system för ens abstrakta tankar att appliceras på det vardagliga rummet. Att vara anhängare av en ideologi betyder alltså att man accepterar dess verklighetsbeskrivning, delar dess grundläggande värderingar och stöder dess handlingsprogram.
Agilt är ett ramverk med riktlinjer i form av värderingar och grundprinciper. Det är själva tanken med det agila, det vill säga agilt är inte syftet utan ett stöd för att uppnå de värderingar som finns i manifestet. Scrum, Kanban och XP är handfasta metoder för att realisera den abstrakta agila tanken för att uppnå målet i praktiken. Exempelvis är inte Scrum agilt förrän den agila ideologin finns i organisationen. Innan du lyckats införa detta tankesätt så är dessa agila verktyg enligt mig bara en nerbantad projektmetod.
Nästa steg är att definiera vad begreppet test är. Test kan ha många betydelser och tolkningar. Exempelvis finns det en rad olika typer av test: integrationstest, systemtest, prestandatest, automatiserad test. Det finns även en rad olika faser, så som acceptanstestning på det har vi olika roller som testledare, funktionella testare, testare, testanalytiker, testautomatiserare etc. Så vad är test, eller snarare vad är test i din organisation och vad vill ni att test ska vara?
Då det finns så många olika tolkningar av begreppet test så har jag valt en mer generell beskrivning. Syftet med test är att säkerställa och/eller höja kvalitén på det som utvecklas. Test är inte en roll, person eller en fas i ett projekt. Det går inte att testa in kvalitet men det går inte heller att veta vilken kvalitet man har utan test.
Idén att utgå från test som en aktivitet är en bra början. Jag tror själv att det behövs testare i ett agilt arbetssätt även om rollen kanske inte är en klassik definition av en testare (vad det nu är). Inom agilt så är test så pass viktig att man inte boxar in den i en projektfas eller lägger ansvaret hos en specifik person eller grupp. Test är något som genomförs av alla i teamet på olika sätt, agil testning är en aktiveter som görs kontinuerligt på olika nivåer med olika tekniker av olika personer.
Testning kan vara många olika saker och här är några exempel på testaktiviteter:
- Kravgranskning
- Parprogrammering
- Kodgranskning
- Kontinuerliga byggen
- Refaktorering
- Användarberättelser
- Riskplanering
- BDD
- TDD
- Kodstandard
De skickligaste programmerarna som jag arbetat med har lagt stor vikt på att försöka skapa kvalité genom att testa in egen kod på olika sätt där parprogrammering, kodgranskning, TDD, automatisera regressionstestning, granska kravspecifikationer, utveckla lite i taget är några testtekniker som används. Min roll i teamet har istället varit att skapa acceptanskriterier, hjälpa till att lokalisera riskområden, informera om vanliga fallgropar och ta användarnas perspektiv.
Alla tekniker ovan är testtekniker, att parprogrammera är en sätt att testa koden, inte bara skriva koden. En agil testare ser kvalitet i ett större perspektiv. En testare kan oftast se helheten och ta användarens perspektiv på ett sätt som inte alla programmerare alltid klarar av eller vill göra. En agil testare fokuserar på att både stödja programmerarna med test som att vidareutbilda organisationen inom kvalitetssäkring. Genom att coacha, utbilda och stödja övriga i teamet behöver inte test blir en trång sektor, test kommer istället bli en aktivitet som alla känner ansvar för att utföra.
En agil testare ska arbeta för att se till att medvetenheten runt kvalitet och test höjs i alla led. Att alla förstår sitt ansvar i att leverera kvalitetssäkrad kod utifrån de krav som organisationen ställer, de krav som intressenterna ställer och de krav som marknaden ställer.
När du börjar se testning på detta sätt och börjar leva efter den agila ideologin så tror jag att du närmar dig vad Agil testning bör vara enligt min definition.
– Jagannath Tammeleht, OnTrax AB
Hej!
Jag håller med om att test i en agil kontext skiljer sig från test i mer “traditionella” projekt. Dock ser jag inte riktigt behovet av att särskilja mellan “agil testning” och “testning”. Det finns mängder av olika sätt att jobba med test, och det kan göras av många olika roller. Det finns många olika “ideologier” att följa. Vissa ideologier följs av många, som t.ex. den agila ideologin, medan andra kanske har personliga ideologier de använder sig av.
Varför ska vi kalla testning gjord av en person som följer den agila ideologin för agil testning? Vilket värde tillför det att göra denna uppdelning av begrepp?
Johan
Hej, jag håller helt med om att vi inte behöver göra en uppdelning. Men nu har det ju redan skapats en uppdelning och ett “nytt” begrepp som folk kallar för agil testning. Därför tycker jag att det är viktigt att man gräver djupare för belysa vad det kan betyda.
Tack för en bra kommentar
Och en annan fundering.
Om vi kallar allt nedan för test:
•Kravgranskning
•Parprogrammering
•Kodgranskning
•Kontinuerliga byggen
•Refaktorering
•Användarberättelser
•Riskplanering
•BDD
•TDD
•Kodstandard
Finns det inte en risk att vi utarmar begreppet till att inte betyda någonting?
Kan man inte kalla allt ovanstående för kvalitetssäkrande aktiviteter? Och välja en snävare definition av test? Jag säger inte att det måste vara faktiskt testexekverande aktiviteter, men kanske något snävare en hela den lista du beskrivit?
Jag har ingen egentlig åsikt i ämnet, utan det är mer funderingar, så ta det för vad det är.
/Johan
Hej igen, bra fundering. Visst finns det risk för utarmning, men det tror jag att det delvis redan skett. Och visst är det så att det är kvalitetssäkrande aktiviteter, jag anser att test och kvalitet hänger ihop. Du kan inte testa in kvalité men du kan inte heller veta vilken kvalité du har förren du har testat.
Min utgångspunkt är att test är en rad olika aktiviteter som tillsammans säkerställer eller höjer kvalitén på produkten som utvecklas.
Listan kan göras hur lång som helst men syftet med denna var främst för att belysa att det finns olika typer av test aktiviteter som vanligtvis man missar.
Min fråga till dig, behövs det en snävare definition av test?
Min förenklade definition av test.
Test har som mål att säkerställa överrenskommen kvalité eller att höja kvalitén till önskad nivå.
Återkom gärna med feedback och synpunkter
/Jagge
Håller absolut med dig om att det är viktigt att belysa den mångfald av aktiviteter som finns inom ramen för att säkerställa överenskommen kvalité och höja kvalitén till önskad nivå.
Håller också med dig om att man inte kan testa in kvalité.
När det gäller målet för test så skulle jag spontant bryta ut det i tre punkter:
*Ge beslutsfattare rätt beslutsmaterial för att avgöra om produkten möter uppsatta kvalitetsmål
*Hjälpa utvecklare att identifiera relevanta problem, som de sedan fixar, på ett effektivt sätt
*Driva en bra design av koden
(den exakta formuleringen bör nog förfinas lite :))
Behövs en snävare definition av test. Det beror så klart på vad man ska använda definitionen till. Men jag tycker det blir svårt att tala om test om jag inkluderar en massa kravarbete, utvecklingsarbete, configuration management etc. Jag säger absolut inte att det är enkelt att avgränsa sig. Det är en svår fråga.
Om jag fick en massa ord och snabbt skulle svara på om det var test eller inte, så skulle det nog sett ut så här:
TDD/BDD = test
Testabilty krav = test
Kontinuerliga byggen = inte test
Continuous Integration Tests = test
Kodgranskning = inte test
Parprogrammering = inte test
Generellt riskplanering = inte test
Riskers impact på test scope = test
Kodstandard = inte test
Refaktorering = inte test
Generellt kravarbete = inte test
Omsättning av krav till use cases som går att testa efter = test
Allt som har test i sig (testplanering, testexekvering, teststrategier, etc.) = test
Ja slutsatsen är väl att det inte är en exakt vetenskap 🙂 och jag säger absolut inte att jag sitter inne på rätt svar, och inte heller kan jag lova att min åsikt i ämnet förblir konstant :). Svaret beror nog på vad man ska använda definitionen till.
Ett litet förtydligande:
TDD/BDD är så klart en utvecklingsmetodik, men jag satte lika med test för att jag tycker det ingår en testkomponent i det.
Hej igen Johan, vilken intressant diskussion det blev. Vi har nog lite olika syn på test och det är ju kul:)
*Ge beslutsfattare rätt beslutsmaterial för att avgöra om produkten möter uppsatta kvalitetsmål
Ja det kan jag köpa, test är ofta en väldigt bra input till beslut.
*Hjälpa utvecklare att identifiera relevanta problem, som de sedan fixar, på ett effektivt sätt
Ja, delvis, hjälpa stämmer men då menar jag att det även ska ingå att hjälpa utvecklarna att testa själv. Programmerare kan testa själva och i många fall gör de bättre tester själva.
*Driva en bra design av koden
Absolut.
Jag kan förstå att många tycker att kan vara svårt att prata om test, men det är det redan idag. Och för mig handlar det mycket om vilken hatt man väljer att ta.
Mitt mål är inte att snäva in test i en ISTQB version utan snarare få folk att öppna ögonen och inse att det finns fler synsätt runt test och hur man säkerställer kvalitén.
Det är vad jag menar med skillnaden på testning och agil testning, många som arbetar utifrån en agil utvecklingsmetod har en annan syn på begreppet test. Test kan göras på olika sätt och i olika steg, test är snarare en aktivitet som kan ske i olika steg i processen. Det är bra om man i en organisation försöker införa aktivitetssteg tidigare i processen där det ofta kan saknas bra tankar runt test istället för att anställa fler testare i slutet-
Exempel: Par programmering är såklart en test och programmeringsmetod. En del av syftet med att ha en som kodar och en annan som observerar och kommer med input är ju tillför öka kvalitén på koden.
Och det som skiljer det agila sättet på test är att test är en aktivitet som ”alla” har ansvar för. Att man sedan hittar olika ansvariga för varje test aktivitet spelar ingen roll. Men att granska kraven ser jag som en test aktivitet, du testar en produkt innan den finns som kod.
Tack för bra input, det är sådana här diskussioner som gör att jag lär mig mer
Hej Jagge, jag håller med om att test är en aktivitet – som kan utföras av “testare” eller “utvecklare”.
Men varför kan vi inte utgå från ISTQB’s definition på agil testning:
“Testing practice for a project using agile software development methodologies”
Det är klart, du kanske vill ha en mer uttömd beskrivning av vad som innefattas i denna “practice”? Det beror ju – precis som du är inne på – vad som innefattas i begreppet “agile software development methodologies”. Det kan vara lite luddigt, det håller jag med om.
Däremot håller jag inte med om att vi behöver “uppfinna” vad “test” är. Det finns tydligt beskrivet i ISTQB.
Om det finns en etablerad definition – som revideras vid behov – så bör vi väl även här utgå från den istället för att försöka hitta på en egen, eller?
Hela poängen med en definition är att försöka snäva in ett begrepp för att underlätta kommunikation. Om alla ska etablera sina egna definitioner av begrepp ökar vi bara förvirringen ytterligare.
Tack för en intressant artikel 🙂
Tack för kommentaren.
Tror att syftet med min artikel kanske inte är så tydligt, men det är ju bra
Egentligen vill jag inte definiera, jag gillar inte definitioner för det begränsar en. Även om jag är fullt medveten om att vi ofta behöver en definition för att kunna förstå begreppet. Och det är vad jag skulle vilja göra med Agil testning.
Idag tycker jag inte att det finns någon bra definition av agil testning, eller ingen som jag känner mig tillfredsställd med och då har jag ju såklart inte läst alla definitioner.
Men varför kan vi inte utgå från ISTQB’s definition på agil testning:
”Testing practice for a project using agile software development methodologies”
Ja du, klart att vi kan utgå från den men jag tycker inte att den definition säger något om agil testning.
Testing practice? Är väldigt öppet vilket är bra, men många tolkningar av testing practise är för dåliga, det vill jag ändra på, agil testning handlar om att tänka på ett nytt sätt, inte fasta i gamla hjulspår runt testning.
Det många tolkningar av agil testning som är skapade utifrån det gamla sättet att testa men att skillnaden är att det görs i ett Scrum, Kanban etc projekt.
Detta är enligt mig det stora problemet, man tror att man testar agilt bara om man har en agil projektmetod typ Scrum. Vilket betyder att så fort man jobbar i ett Scrum team så är man agil testare, inte enligt mig. ISTQB hade säkerligen inte tänkt sig så från början men nu är det tyvärr så bland väldigt många testare och testföretag.
Du är inte en rallyförare bara för att du kört en rallybil.
Slutsats:
Jag tycker det saknas en bra etablerade riktlinjer för agile testning.
Det finns för många olika definitioner idag där de flesta enligt mig är under all kritik.
Jag vill öppna upp det snäva sättet att se på test, dvs V-modellen, systemtest, integrationstest, testfaser, testteam. För mig handlar test om att stödja kvalitetsarbetet, om det är att granska krav, så får det vara så. Ja det finns de som vill separera krav från test men jag vill inte arbeta på det sättet.
Tack för en bra kommentar,
Jag och några kollegor kommer släppa lite nya vinklingar på agil testning som förhoppningsvis skapar en nödvändig diskussion.
/Jagge
Intressant diskussion.
Håller med dig om att stödja utveckling med testkompetens också kan inkluderas i test. Det kan vara i form av att man skriver teststrategier till dem, coachning i testmetodik, hjälper till med automatisering, etc. Jag inkluderar detta i “hjälpa utvecklarna att identifiera relevanta problem”. Dock tror jag att jag vill skilja på granskning och test.
Kodgranskning och parprogrammering har då en granskningskomponent men inte en testkomponent.
Tyvärr så går då min bild tvärt emot resten av världen, där statisk testning är del av test. Så jag menar dynamisk test när jag pratar om test, och inte statisk test, som jag då kallar granskning, med eller utan verktyg, och i en mängd olika former.
Jag förstår fortfarande inte riktigt vad som är speciellt med agil testning och ser fortfarande inte behovet av terminologin, men jag köper att min oförmåga att inkludera statisk testning i min definition av test kan anses felaktig, och att andra kan finna ett värde i termen agil testning 🙂
Men om vi bortser från statisk testning/granskning, så tycker jag forfarande att följande gäller:
Kontinuerliga byggen = inte test (CM inte test)
Kodstandard = inte test (utveckling inte test/granskning – kan användas under granskning/statisk test dock)
Refaktorering = inte test (utveckling inte test/granskning, men kan ske parallellt med kodgranskning som är statiskt test)
Generellt riskplanering = inte test (projektplanering, bortsett från om det används till scopesättning)
Men jag tror vi har tömt ämnet nu 🙂 Tack för diskussionen.
Jag är inte riktigt säker på att jag förstår vart du vill komma. Du kanske kan exemplifiera genom att ta en befintlig definition du inte är nöjd med?
Som jag ser det håller vi på med systemutveckling. En aktivitet är test. Det är det oavsett om vi jobbar agilt eller inte. Att sedan denna aktivitet innefattar olika moment beroende på hur vi arbetar ser jag som självklart – det är sunt förnuft. Det finns till och med övertydligt i ISTQBs foundation:
Testing principle: Testing is context dependent. Testing is done differently in different context.
Om jag förstår dig rätt vill du generalisera den “agila testningen” och plocka fram de moment som utmärker en “agil testning”?
Jag har arbetar med test i agila projekt sedan 2005 och mina arbetsuppgifter har varit vitt skilda beroende på system och vilken roll jag haft.
Men visst, jag håller med om att i den “agila världen” så blir man ofta en ambassadör för test i sitt team. Fast idag tycker jag det är ovanligt med lagmedlemmar i agila team som man behöver “promota” test för. De flesta har förstått betydelsen av ett “kvalitetstänk”.