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ö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?
Informator erbjuder flera spännande kurser inom Kravhantering och Testmetodik. Se alla våra kurser inom Krav och Test här
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.
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
2 kommentarer
Visst finns det kopplingar man kan göra till tests vs checks.
SvaraVad 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.
jag håller med dig i mycket av det du skriver i din respons.
SvaraUtveckling/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.
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.