Myt #1: Alla agila testare måste vara tekniska
Myten om att alla agila testare måste vara tekniska är inte bara en bland många myter, utan en riktig klassiker! Agil testning kan vara ganska svårdefinierat. Eller rättare sagt; det finns många intressanta tolkningar av vilken kompetens som krävs av en agil testare.
Ursprung
Varför myten har uppstått beror på en rad olika faktorer. En faktor, tror vi, är att agile är väldigt utvecklingsnära. Det var främst utvecklarna och inte testarna som initialt drev (och driver?) det agila framåt i Sverige. En annan faktor är det agila arbetssättet som sådant, som fokuserar på ett teams medlemmars förmåga att samarbeta och producera resultat tillsammans. Att det ställs nya och andra krav på team-medlemmarnas mjuka och hårda kompetenser kan så klart oroa många.
Diskussionen kring automatiserade tester har också eldat på myten. Automatiserade tester är ofta något som belyses som något extra viktigt för att lyckas med agil utveckling. Testautomatisering kräver teknisk kompetens hos den som implementerar testerna för att kunna utföras. Det rör sig då om antingen scriptning eller tämligen avancerad programmering av testinfrakstruktur och själva testerna. Speciellt de senare aktiviteterna brukar inte förknippas med den traditionella testarrollen.
Vi tror också att begreppet ”tvärfunktionella team” har bidragit till mytens spridning. Detta begrepp skapar enkelt den felaktiga bilden av att alla måste kunna göra allt. En testare ska t.ex. kunna hoppa in och koda när det behövs. Så är givetvis inte fallet, men denna misstolkning har legat till grund för myten.
Vadå ”teknisk”?
För att förstå myten bättre kommer vi behöva bryta ner den i mindre delar. ”Teknisk” är själva påståendet i myten, och för att besluta om myten är busted eller approved behöver vi reflektera över vad vi menar med ”teknisk testare”.
Att vara teknisk är, i våra ögon, en kompetens som teamet, projektet eller organisationen behöver för att utföra uppgiften. Utifrån vilken uppgiften är, kommer varierande kompetenser att behövas. Det är viktigt att säkerställa att rätt kompetens finns tillgänglig i teamet/organisationen. När det finns behov av teknisk kompetens inom testning behöver det inte nödvändigtvis vara kopplat till rollen testare. Det kan enligt oss lika gärna vara en programmerare som ansvar för aktiviteten. Det viktigaste är således inte vilken person som har kompetensen, och framför allt behöver det inte vara en testare som står för den tekniska testningen. Det är snarare upp till teamet att säkerställa kvaliteten och tillsammans se till att uppfylla kompetenskriterierna.
Vad definierar en agil testare?
Fortsätter vi bryta ner myten, har vi rollen ”agil testare” kvar. Här blir det lite lurigt. Syftet med denna artikelserie att tydliggöra definitionen av agil testning och vi vill inte springa för långt fram redan i första myten.
Att vara en agil testare är inte kopplat till rollen testare, utan snarare en person som försöker stödja och främja kvalitet och ser det som ett arbete som omfattar alla teamets aktiviteter. En agil testare är en person som utför testning. Denna testning är en aktivitet som sker i olika steg på olika sätt av olika personer kontinuerligt igenom hela utvecklingsprocessen. En agil testare ser också till att testning och testbarhetsaspekten aldrig glöms bort under designen eller planeringen. Agil testning är inte kopplat till en roll, person, team eller projektfas utan görs av alla teamets medlemmar. I agil testning är kvalitet så pass viktigt att man försöker utnyttja alla individers olika kompetenser och erfarenheter i testningen.
Alltså…
Den tekniska kompetensen ligger alltså på teamnivå och inte kopplat på en roll. Agil testning är därför en rad olika aktiviteter som ska utföras av olika personer med olika kompetenser. En testare behöver således inte vara teknisk för att kunna kalla sig agil testare.
Med andra ord, myten är:
"Myter är som kamouflerad kollektiv visdom, det finns alltid något att lära.
Agila Myter BUSTED 
Trevligt skrivet, Jimmy!
Även om jag håller med i sak vet jag att en testare (för mig, en person som brinner för kvaliitet) som insett att automatisering av tester är essentiella vid iterativ, inkrementell utveckling och kan lära ut och sprida det till övriga i teamet är oerhört mycket värdefullare än en testare som tänker mer traditionellt (automatisera försiktigt, vid behov). Då är personen ”teknisk” för mig.
Så nej, man behöver inte ”vara teknisk” men man är oftast bra mycket värdefullare för det agila teamet om man är det.
Tack Joakim!
Måste börja med att kommentera att jag inte skrivit detta inlägg. Vi är fyra författare som hjälps åt 🙂
Med det sagt måste jag tacka för den vinkel du ger. Men visst är det väl så att man som testare kan inse vikten och nyttan av automatisering och TDD utan att själv kunna skriva de automatiserade testerna (dvs ha teknisk kompetens) och ändå få lov att kalla sig agil testare. Eller?
Men visst, om testarna i teamet dessutom är tekniska höjs antagligen teamets produktivitet. Teamets produktivitet höjs också troligtvis om utvecklarna tänker på kodens och systemets testbarhet och inkluderar test i planering och estimering 🙂
Joakim, varför vill du ha en testare till att messa ut till resten av teamet att man måste automatisera tester. Ni har ett helt team redan som är duktiga på att programmera, ta inte in en testare att göra ert skitgöra, utan ta ett eget ansvar för era checkar det är då ni får ut värde av det arbetet.. För mig är det slöseri med kompetens och tid mot vad ni kan få ut av en duktig testare. Det är en väldigt skev bild av testning man har om man tycker att det är mycket värdefullare att ha en testare som tror automatisering av alla tester är målet (ni har inte en testare, ni har en till utvecklare). Att gå på ditt spår slutar i att ni endast Checkar av ert system och inte Testar det. jag hänvisar till min blogpost http://blog.houseoftest.se/2012/03/26/checking-as-an-enabler-for-testing/
Vadå ”ert skitgöra” och ingen sa väl att en testare skulle ”stå och me[ä?]ssa ut till resten av teamet att man måste ha automatiska tester”? Luktar lite tolkning utifrån egen värdegrund om du frågar mig.
ja du har rätt ”skitgöra” det var ganska dåligt uttryckt av mig.
Det känns som att många idag efterfråga testare med programmeringskunskaper just för att utvecklarna själva ska slippa utföra sina checkar. Det har även spridit sig en övertro till att så länge dessa checkar lyser grönt så är allt frid och fröjd och det finns ingen anledning att testa mer. Effekten av detta blir att fler och fler testare ägnar i princip all sin tid med automatisering och man testar produkten minde och mindre.
Man kan vända på det och säga att det även är högre efterfrågan på utvecklare med test-skills. Fler och fler arbetar med lean/agila metoder där man premierar ett team som kan arbeta nära med varandra. Dessutom har dessa metoder ett större fokus på test.
Så att man efterfrågar testare med programmeringskunskaper ser jag som en ganska naturlig följd. Det betyder inte att behovet av otekniska testare kommer försvinna men jag tror definitivt att det kommer minska.
Jag kan dock tycka det är märkligt med föreställningen att otekniska testare ska verifiera mjukvara (validera bör de självklart kunna göra). Hur skulle det se ut om man satta otekniska testare på att verifiera ett brobygge eller en pacemaker? Att man behöver insikt hur tekniken fungerar för att kunna göra ett bra test-jobb ser jag som en självklarhet.
Tack för kommentaren Jocke, håller med om att en teknisk kompetens aldrig är fel. Hoppas att du hänger med i våra kommande inlägg. Du kan förvänta dig 25 myter om testning sedan rullar nästa område in i mythbusters malpåse:)
Jag känner mig inte övertygad om att myten är ”Busted”.
För mig är en teknisk testare en person som förstår de underliggande teknologierna, och som använder verktyg när det behövs.
När jag samarbetat nära med utvecklarna, så har den största förtjänsten inte varit de gånger jag programmerat (en minoritet av tiden), utan det har varit att jag pratat samma språk som dem, jag har förstått deras arkitektur och design, och jag har kommunicerat mina resultat från testningen på ett sätt som ligger nära hur de tänker.
Så utifrån perspektivet att det ska vara lätt att samarbeta med utvecklarna, så blir det lättare för en ”teknisk” testare.
Därmed inte sagt att det är det som behövs, ofta är det ju de nya perspektiven som testare ger som är det mest värdefulla.
Så en ”oteknisk” testare kan bidra med minst lika mycket värde, men det ställer högre krav på utvecklarna, att de vågar ta till sig andras perspektiv, formulerat på andra sätt.
Så om myten ändras till ”Testare i agila sammanhang har det lättare om de är tekniska”, så tror jag att det ligger något i den.
Kan det månne bero lite på omgivningen? En agil testare måste inte vara teknisk men jag tror definitivt det hjälper – åtminstone i många sammanhang. En bra sammansatt utvecklingsgrupp innehåller personer med olika kompetenser. För att denna grupp ska kunna kommunicera effektivt behöver man ett gemensamt språk – ett tekniskt språk. Den agila testaren bör kunna detta. Annars är risken för missförstånd uppenbar.
Å andra sidan, det kan finnas fördelar med ”otekniska” testare också – t.ex. kan de ev. bidra med ett helt annat synsätt/vinkling av problematiken.
Om jag ska sätta ihop ett team i en agil utvecklingsmiljö vill jag att alla ska vara ”tekniska”. Det är viktigt att det i gruppen finns individer som har egenskaper som noggrann, analytisk, kritisk etc (kvalitéer som utmärker ett test-mindset).
När jag läser artikeln så tolkar jag det som att fokus ligger på programmeringskunskaper och enligt min erfarenhet är det mycket fokus på just detta när man pratar om att en testare ska vara teknisk. Men att kunna programmera är bara en version av att vara ”teknisk”. Teknologi är ett så mycket vidare begrepp än så, fritt översatt från Oxford Dictionaries så betyder teknologi, applicering av vetenskaplig kunskap med praktiska syften. Ser vi till denna definition så tycker jag nog att de flesta i vår branch är ,mer eller mindre men fortfarande likväl, tekniska. Så myten kanske skulle vara ”Behöver testare kunna programmera” då det är mer specifikt och det som jag tror många menar när man tänker teknisk.
Jag tror inte att man av automatik tillför mer värde som testare för att man kan programmera. Det är en kompetens av flera som en testare kan besitta. Jag tror det är bra mycket mer komplext att förutspå om en testare skulle vara bättre än någon annan och det räcker inte heller att säga att det är i en agil kontext då det inte definierar alla de parametrar som påverkar prestationen. Jag tycker det är väldigt olyckligt att det är så pass stort fokus på programmeringskunskaper för testare som det är idag då man tenderar till att inte se till vilka kunskaper som saknas i gruppen för att kunna öka våra möjligheter att lösa de problem vi jobbar med.
Igår skulle alla vara certifierade testare, idag ska alla vara andra klassens programmerare, imorgon kommer det vara något annat. Man söker en likformighet av personer istället för att skapa variation och olikheter i kunskap, erfarenheter och personligheter. Jag tror vi riskerar att stå sämre rustade för att lösa de problem som kommer framför oss och genom att vi alla ska vara lika hämmar vi vår utveckling som individer.
Tekniska kunskaper är aldrig fel i ett testarbete även om vi testare inte direkt behöver kunna koda. Att gå ner i databasen och se hur saker verkligen ser ut ger ovärderlig information fast självklart kan även en utvecklare hjälpa till med det bara man kan efterfråga informationen. Att använda testklasser där utvecklare kodar testfall är mycket kvalitetshöjande men om man kan föra en dialog med en erfaren testare om hur man ska lägga upp det hela så vinner man mycket mer. Att testaren ska kunna koda själv tycker jag inte är nödvändigt. Hur saker ska fungera bör ändå alltid beskrivas utanför själva koden.
Detta gäller både agil och mer traditionell utveckling.
Visst, att vara en teknisk testare gör det enkelt att komma in tidigt och testa redan innan hela funktionen är levererad (vilket ofta är fallet vid testning i agila projekt). Ett agilt team har också stor nytta av verksamhetsinriktade testare för hjälp med att tolka userstories och verifiera lösningar utifrån systemlösningens kontext et.c. Har flera exempel på när en driven verksamhetsinriktad testare (ej teknisk) varit en viktig framgångsfaktor för teamet.
Jag är inte heller helt övertygad om att myten är ”busted”. Jag tror att agila team bör ha ett större överlapp av kunskap än vad man kanske tänker sig traditionellt. Sedan behöver för den skull inte alla göra allt.
Bara att vara medveten om vilka möjligheter programmering kan ge är värdefullt. /Personligen/ skulle jag inte ta in en testare som är helt ”oteknisk” i mitt team om det var jag som valde. Då är min erfarenhet att det är effektivare att sätta ”programmerarna” och ”verksamheten” i samma rum och gå och fika tillsammans.
Tack för alla kommentarer.
Som du skriver Henrik så är begreppet teknisk lite lurigt och vi utgår från vad vi tror att myten tolkar begreppet som, dvs att man har programmeringskunskaper, som du nämner i kommentaren. Vi har försökt ta på oss hatten som en person som har just denna myt om agil testning.
Självklart är det bra med programmeringskunskap, det håller jag med om även om det är viktigt att man har olika intressen och kompetenser för att få en bred på testningen. Är alla tekniska ”programmerare” finns det en riska att testningen inte blir så varierande som man kan hoppas, alla kan inte tänka lika. Däremot så tycker inte ”agila myter” att tekniskkompetens ”programmeringskunskaper” är ett krav för att kunna kalla sig för agil testare. Det finns många andra kompetenser som är intressanta och värdefulla och då tänker jag mycket på användarfokus, användarvänlighet, strategier, metoder, processer utbildning, grafiskompeten mm.
Om den är BUSTED eller inte kommer ju alltid att kunna diskuteras, då det som finns många olika nyanser av svaret och det är ju det roliga med myter, det finns så mycket att diskutera.
Men vi har valt att försöka undvika att argumentationen bygger på ” det beror på”, utan snarare försökt ta ställning, rätt eller fel det kan inte vi avgöra utan det är vad vi tyckte när vi skrev den. Det vi vill uppnå med bloggen är att belysa myter inom området för att på ett enklare och förhoppningsvis roligare sätt hjälpa människor att reflektera över de svåra utmaningar som finns med agilt.
Nu vet jag ju vilka alla är som har kommenterat på detta inlägg och alla ni är ju personer som själva driver för att ständigt utvecklas och utveckla branschen så det är inte konstigt att ni har mycket idéer och tankar. Det är superkul och vi försöker ta till oss så mycket som möjligt av era tankar och kommentarer.
/Agila myter
Bra inlägg där. Kommer fortsätta att läsa och göra inlägg där jag kan bidra.
Kul ämne och intressant diskussion 🙂
I Agila team är teamet ansvarig för att leverera värde. Så teamet behöver sätta upp strategier hur man ska testa produkten utefter de givna förutsättningarna man har. I många fall är det bra att ha någon som kan automatisera vissa tester och man behöver väl i alla fall alltid på ”teknisk detaljnivå” bekräfta att det man vill åstadkomma också åstadkoms.
I Agila team behövs all nödvändig kompetens för att utföra de uppgifter som är ålagt teamet. Man är ofta van att se medlemmarna i teamen som ”testaren”, ”utvecklaren” etc. Jag tror att man kan få ett roligare och mer varierat jobb om man tänker fritt vem som skulle kunna lösa en uppgift när den borde göras. Behöver man utveckla ett script kan testaren utföra detta om personen kan det. Behöver man verifiera att någonting fungerar i en testmiljö kan utvecklaren göra det.
När det kommer till test är det väldigt bra om alla någon gång hjälper till att utföra testning efter sin egen kompetens eftersom att bra testning förutsätter att se systemet ur så många perspektiv som möjligt. Ser en utvecklare hur bökigt det är att utföra ett visst test kan denna kanske fixa så det blir enklare.
Så för att återknyta till frågan om alla agila testare måste vara tekniska? Mitt svar blir att det i de allra allra flesta agila team (kanske alla) behöver finnas dem som kan bekräfta att systemet fungerar som det är tänkt på teknisk nivå. Vem som utför den uppgiften beror på vem som är mest lämpad utifrån förutsättningarna (timeing/budget/etc).