Den mjuka och den hårda testaren – varför båda behövs i det agila teamet

Agil utveckling har blivit allt vanligare inom mjukvaruutveckling och många företag har anammat det agila tänket för att hitta sin väg framåt mot en effektivare utveckling, med mer kontinuerliga leveranser och en lösning som ligger närmare att uppfylla det behov som kunden har. Agila team bildas och att test behöver inkluderas i teamen håller de flesta med om. Frågan är vilken testkompetens som behöver finnas i ett agilt team?

Många av oss som primärt jobbar med test har en resa framför oss att anpassa oss till den nya miljö som agil utveckling innebär, med mer frekventa leveranser, ständigt föränderlig kravbild, kommunikation och samarbete med övriga discipliner, osv. Miljön ställer nya krav på oss som testare och det är inte alltid lätt att veta hur man ska passa in och bidra i sitt team.

För att försöka bena ut vilken testkompetens som krävs i ett agilt team kan man prata om två olika testare, den mjuka och den hårda. Den mjuka testaren har fokus på verksamheten och användarna, lär sig hur systemet ska användas och vilken nytta systemet ska tillföra. Troligtvis arbetar den mjuka testaren en hel del med utforskande testning och har frekvent kommunikation med användare och verksamheten. Den hårda testaren har en djupare teknisk förståelse med kunskap om gränssnitt för tester, systemets arkitektur, processer för continuous integration och continuous delivery.

Förmodligen jobbar den hårda testaren med testautomatisering och design av automatiska testfall genom ATDD eller BDD. Tillsammans med utvecklarna arbetar den hårda testaren för att hålla utvecklingstakten i teamet uppe genom att skapa en säkerhet vid förändringar och förhindra regression.

Förhållandet mellan den mjuka sidan och den hårda sidan beror självfallet på vad det är för typ av lösning eller system som man tar fram. För vissa system bör man lägga större vikt på den mjuka sidan och för andra system bör vikten ligga på den hårda sidan.

Kanske kan det låta som att man pratar om två olika personer i form av den mjuka testaren och den hårda testaren. Visst, det kan vara så att det är två eller flera personer som tillsammans har kunskapen men det kan också vara så att den mjuka testaren och den hårda testaren befinner sig i samma fysiska kropp, som någon form av agil supertestare.
Det viktiga är att det finns både mjuk och hård testkompetens i teamet. Tyvärr är detta inte alltid fallet och det är inte ovanligt att man missar att inkludera antingen den hårda eller den mjuka testaren i teamets kontinuerliga arbete. Alternativt att man försöker lägga in det i någon som inte har rätt tänk och kompetens inom testning. Har ni både den mjuka testaren och den hårda testaren i ert team?

Markus Niklasson har en magisterexamen (M.Sc.) i datavetenskap från Högskolan i Skövde och har därefter arbetat för bland annat Volvo Cars, SAAB Microwave Systems, Ericsson och Siemens med testautomatisering och agil testning.
Markus Niklasson har spetskompetens inom agil testning och brinner för kontinuerliga förbättringar. 

Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här

3 kommentarer

När jag läser din beskrivning på mjuk och hård testare så låter det för mig som att du menar vad vi i den kontext drivna communityn ofta kallar Tester och Checkar. http://www.satisfice.com/blog/archives/856

Du skriver att den “hårda testaren” ägnar sig åt att automatisera enligt ATDD eller BDD. Jag tycker det är en olycklig rekommendation då dessa metoder främst är för utveckling.

Det är en attraktiv tanke att man slänger in en “hård testare” i teamet så får vi snabbt massor av checkar. Tyvärr är risken att man gör sig själv och teamet en otjänst genom att göra så. De finns en anledning att utvecklingsmetoder som TDD, BDD, ATDD, osv bygger kring checkar. Det är bland annat ett hjälpmedel för programmeraren att ha kontroll på sin kod och att veta när han kodat tillräckligt och därefter kan fokusera på refactoring.

Att se de automatiska checkarna som en separat del och plocka in en person som ska ägna sig åt automatiseringen av checkar gör att vi "tar ifrån" utvecklaren en stor fördel och värde med att använda sig av denna typen av metoder. Inte nog med att vi lägger in ytligare en feedback loop genom att addera en person till i processen vi ger även utvecklarna en ursäkt till att inte tänka på sina checks och på så sätt inte få samma kontroll på sin kod. Det är själva tänkandet och skapandet av checken första gången som innehåller det största värdet för utvecklaren när denne designar sin kod inte regressionskörningarna.
I de flesta team så finns det gott om programmeringskunskaper och ofta en brist på testkunskap. Att då ta upp en plats i teamet med en “hård testare” är enligt mina erfarenheter oftast ett slöseri med tanke på den begränsad mängd kompetenser som ett team har att tillgå.

Oftast när jag ser detta så ligger problemet i brist på kunskap och förståelse för syftet och hur metoderna appliceras. Mitt råd är att istället säkerställa att det finns kompetens och vilja i teamet att använda metoderna som de är tänkta. De som har störst nytta av dessa checks är programmeraren. Då får ni alla fördelar och ni utnyttjar teamets kompetens bäst genom att låta de som programmerar även använda dessa design metoder.
Visst kan en testare vara bollplank om det behövs vid tillfälle men det bör inte behövas att vara konstant involverad. På så sätt får testaren mer utrymme att fokusera på “mjuka tester” vilket är ytligare en vinst.

Till sist för att förbigå ett par vanliga kommentarer: Programmerare kan visst lära sig att skapa värdefulla checkar det är inte bara vi testare som klarar detta. Nej, det tar inte längre tid för en programmerare att utveckla en funktion när dom även ska skapa massa checkar, de vinner så mycket annat som spar tid för dom. Och visst kan det finnas andra tester som man vill automatisera men man ska väl inte behöva ha en “”hård testare” i teamet för att klara detta.

Jag verkligen understryka att jag inte nedvärderar Checkar (hårda tester). Checkar är viktiga och värdefulla. Jag skrev en blogpost för ett par år sedan om viktent av checking.
http://blog.houseoftest.se/2012/03/26/checking-as-an-enabler-for-testing/

Svara
Markus Niklasson mod

Visst finns det kopplingar man kan göra till tests vs checks.

Vad det gäller hårda testare, så är utveckling i ett agilt team som jag ser det ett lagspel där personer med olika kompetenser samspelar och samarbetar för att ta fram lösningar. För att få exempelvis framgångsrik ATDD så behöver man ha diverse olika kompetenser, bland annat inom test. Jag ser det inte som att det är något som de som skriver produktionskoden gör på egen hand för att säkra sin kod. Sedan kan det vara så att de som skriver produktionskoden också implementerar testerna rent tekniskt. Framtagandet av testerna (eller checkarna) är en viktig process för hela teamet för att komma fram till hur lösningen ska fungera och är ett samspel mellan testare och utvecklare (och verksamhetskunniga). Detta har jag upplevt som mycket framgångsrikt.

Svara

jag håller med dig i mycket av det du skriver i din respons.
Utveckling/problemlösning är samarbete viktigt där man utnyttjar olika kompetenser och infallsvinklar.

“Framtagandet av testerna (eller checkarna) är en viktig process för hela teamet för att komma fram till hur lösningen ska fungera och är ett samspel mellan testare och utvecklare (och verksamhetskunniga)”.
Vi är eniga jag håller med dig det är viktigt att alla parter gemensamt förstår problemet som skall lösas.
Vi verkar båda vara överens om att ett team kan ha stor nytta av att ha testkompetens i teamet.

Dock läser jag det som att du ändrar din åsikt mot original texten.
Där skriver du “Förmodligen jobbar den hårda testaren med testautomatisering och design av automatiska testfall genom ATDD eller BDD”.
I din respons till min kommentar skriver du “Sedan kan det vara så att de som skriver produktionskoden också implementerar testerna rent tekniskt”.

Det är ditt första uttalande jag inte håller med om att det är ett generellt bra råd.
Jag är mycket mer för att det är de som skriver produktionskod som implementer testerna och du verkar också tycka det är ett sätt att göra det på.

Min fråga är då om vi tänker oss att utvecklarna använder detta som designmetodik och implementerar testerna. Varför är det då så viktigt att ha en “hård testare” i teamet? Som jag ser det så kan en “mjuk testare” tillföra den testkompetens som behövs.
Om det inte är som beskrivet ovan utan vi går på det du skrev först att den hårda testaren jobbar med test automation enligt ATDD eller BDD. Vilka fördelar har ett team av att den “hårda testaren” gör detta istället för att utvecklarna använder sig av detta som design modeller? Samt vilka nackdelar kan du se med en sådan set up?

När jag skriver detta inser jag att jag har väldigt svårt att förstå den här uppdelningen mellan hård och mjuk testare. Det är en för mig onaturlig uppdelning av egenskaper eller klassificering av testare.

Svara

Skicka en kommentar

Trevligt att du vill dela med dig av dina åsikter! Tänk på att hålla på "Netiketten" och använda vårdat språk.