Per Erik Strandberg /cv /kurser /blog

http://www.pererikstrandberg.se/blog/tilo-linz-testing-in-scrum-400.jpg

Jag läste nyligen Boken Testing In Scrum - A Guide for Software Quality Assurance in the Agile World av Tilo Linz från Rocky Nook, utgiven 2014, på strax över 220 sidor. ISBN: 9781937538392. Den ska likt Boken Software Testing Foundations vara en studiehjälp för den som är nyfiken på att certifiera sig. Priset ligger på strax över 200 SEK på adlibris (se [1]). Den har ännu inget betyg på Amazon, men ligger där på strax över 30 USD (se [2]).

Överblick

Boken Testing In Scrum har precis som Boken Requirements Engineering Fundamentals och Boken Software Testing Foundations en mycket trevligt format: paperback, inte för lång, vettiga illustrationer, bra index och så vidare. Boken Testing In Scrum är på totalt 224 och har en introduktion, 7 kapitel, en ordlista, referenser och ett index. Ett av kapitlen är en samling mycket värdefulla fallstudier från olika företag som introducerat scrum, eller agilt, och/eller lean. Fem av kapitlen har övningsuppgifter som ska hjälpa till inför en eventuell tenta som Istqb Foundation Certified Agile Tester.

Negativt med boken?

Det som jag uppfattar som negativt med boken - eller kanske som negativt med agila metoder - är:

Positivt med boken?

Många saker var bra med boken:

Observationer och Lärdomar

Jag gjorde mot slutet av läsningen en rad anteckningar över saker som var extra intressanta.

Roller och teamsammansättning

En observation som återkommer är diskussionen om sammansättning i team, och hur rollerna förändras. I traditionell utveckling händer det ibland att utvecklingsteamet skiter i om koden är buggig eftersom det kan test ändå hitta senare. Å andra sidan är test helt oberoende av utveckling och kan känna stolthet i att hitta fel som ibland kan blocka en release.

I de agila teamen (så kallade cross-functional teams) ska varje team ta ansvar för krav, kod, test, dokumentation och kvalitet vilket ställer mycket höga krav på de som är involverade i teamen, speciellt om man behöver följa en industristandard som EN50128.

Flera gånger i boken framförs observationen att testare kan "börja tänka som utvecklare", det vill säga att de vill behaga projektledningen genom att släppa fram releasen - istället för att vara "professionellt pessimistiska". I den svenska kursplanen för Istqb Foundation Certified Tester Foundation Level läser vi "Att leta efter felsymptom i ett system kräver nyfikenhet, professionell pessimism, ett kritiskt öga, uppmärksamhet på detaljer, god kommunikation med utvecklare [...]". Man riskerar med andra ord att den här kritiska förmåga och den oberoende testningen går förlorad vid agil utveckling.

Det här är inte bara något jag drömmer ihop av att övertolka litteraturen - det stämmer mycket väl med mina egna observationer. Testar man mjukvara från någon man misstänker har man ett helt annat tankesätt än när man undersöker mjukvaran från en kompis. En av fallstudierna nämner att man funderar på att återinföra central testning, en annan fallstudie att systemtestning och testning efter "de tunga protokollen" som arkiveras som bevis på att man uppfyller en standard är oberoende av utvecklingsteam. En annan fallstudie beskriver att de har agila testare i varje team kombinerat med ett testteam - det tänket tilltalade mig, då gör det inte så mycket om vi har en hög med ja-sägare så länge några är mer lagda åt det skeptiska hållet.

När man tänker på testning som lasttester, säkerhetstester, användbarhet, skalbarhet och så vidare så tror jag det snabbt blir jobbigt för den stackare som är agil testare i ett scrumteam om inte externa resurser även finns.

Att agil testning är en utmaning på små och medelstora företag är jag säker på.

En av fallstudierna talar varmt om den bra teamsammansättningen och att det triggar ett kritiskt tänk till processen: kan den optimeras på något sätt?

Något relaterat till teamsammansättning är att få testare i olika team att sammanstråla då och då, för att utbyta erfarenheter och växa i rollen som testare. Det här är något jag har stor erfarenhet av i rollen som konsult: vi har lyckats mycket bra med det och får folk, på frivillig basis, att sammanstråla från olika kunder, helt olika projekt i helt olika domäner och från olika städer. Vi möts en gång i månaden och behandlar olika teman. Tack vare det och att vi har drivande individer har vi växt otroligt i rollen som testare och testledare.

Parprogrammering

Begreppet parprogrammering återkommer många, många gånger i boken. En självklarhet som inte var självklar för mig innan var de olika kombinationerna av par man kan ha. Några exempel:

En av fallstudierna nämner att behovet av formell kodgranskning blir minimalt med parprogrammering - de gör bara kodgranskning om en modul är har en högre nivå av krav på säkerhetsklassning eller liknande. För mer om granskning kan jag tipsa om Metod För Formell Granskning.

Betala för agil expertis

Något som återkom i fallstudierna var att de investerat för att börja med Scrum eller för att köra agilt. Det var förstudieprojekt, pilotprojekt, scrumcoachar, tips att anställa scrummasters, konferenser, workshops, och så vidare. Det är ju egentligen självklart att det kommer kosta tid och pengar att lära sig något nytt, och att införa det i en organisation. Detta tror jag inte verbaliseras i den agila litteraturen, där känns det mer som "håll käften, det är skitenkelt!".

Den sista fallstudien går så långt att de säger att agil utveckling inte är möjlig utan agila coacher.

Vem tar hand om kvalitet?

I den första fallstudien slinker den in lite i en parentes: "As expected, the teams were initially missing some of the skills (such as quality management) [...]", och det var ju inte helt utan hånskratt jag läste det. Det stämmer mycket bra med mina fördomar om agil utveckling: att det är fragil utveckling, det går fort och det går fel.

Det som verkar vara den enda lösningen är att ha några krav på sin utvecklingsmodell - typ "kvalitetsgrindar":

När testar vi?

Flera av fallstudierna ville komma bort från implementera först, testa sen. Vi får några tips. Ibland var det lämpligt att testa i slutet på varje sprint, ibland att ha en testsprint, ibland att ha släpande test (som ligger en sprint efter). Men bäst är att testa samtidigt, ha ett stort fokus på automatiserade tester och begreppet test first återkommer ofta.

En tanke som en av fallstudierna trycker på stämmer mycket bra med min erfarenhet är att all testning inte kan automatiseras. Ofta nämns undersökande och sessions-baserad testning - som jag skriver lite om i texten Session Based Exploratory Testing. Jag skulle här vilja lägga till manuell och skriptad testning, sånt som inte går att automatisera men som ändå är rätt så mekanisk - jag tror det finns en plats för det även i agila projekt. Som regressionstestning om inte annat.

Ärendehantering

En sak som oroar mig verkar vara när Scrum ā la Jehovas Vittnen säger "alla funna buggar blir omedelbart omhändertagna" eller "bara buggar som involverar andra team läggs in i ärendehanteringssystemet". Det här känns som rent skitsnack - man kan väl inte förvänta sig att ett team som gör massor med olika saker ska avbryta allt de håller på med för att hantera alla funna problem.

Det är väl knappast deras roll att analysera kundnytta, affärsnytta eller vad den nu må vara i alla funna problem? Det jag fiskar efter är att ett ändringshanteringsråd (Change Control Board) borde ha ett och annat att säga i frågan.

Ett annat problem jag har med att underrapportera fel är att man missar chansen att göra till exempel automatiserade regressionstester av det - och ligger det i ärendehanteringssystemet är det lätt att hitta igen om ett liknande fel uppstår.

Produktägaren

Det är kanske ingen överraskning att produktägaren är viktig för Scrum. Faktum är att en oengagerad kund är en av de viktigaste faktorerna för låg mjukvarukvalitet (se listor i Boken The Economics Of Software Quality), så en kund som bryr sig är bra oavsett utvecklingsmetod.

Ett av företagen i fallstudien nämner att de har en hierarki av produktägare: en chefsproduktägare och så en eller flera specialistproduktägare för de olika funktionella områdena i produktserien.

Fördelar med Agil Utveckling

Boken nämner flera fördelar med agil utveckling som jag kan hålla med om (en del av dessa var faktiskt nyheter för mig):

(När det gäller nackdelar med agil utveckling kan jag bara hänvisa till resten av denna text - jag är inte nödvändigtvis bara positiv till agil utveckling.)

Indelning i Kapitel

De viktigaste kapitlen är:

Översatta till svenska (av mig, ha överseende) blir kapitlen:

Vad tar jag med mig

Det låter som floskler, men Boken Testing In Scrum är en bok som väcker känslor, och en bok jag kommer återkomma till.

Den förklarar Scrum på ett trevligt och förhållandevis neutralt sätt.

Som bekant lider Scrum, XP och Agil utveckling av ett abnormt not invented here syndrome och begrepp som krav förekommer inte ens utan ersätts av till exempel backlog. Så att få begreppen på plats kommer hjälpa mig mycket när jag kikar mer på Scrum - även här gör boken det materialet lättåtkomligt. Till exempel var begreppet Definition of Ready (som jag inte stött på i den agila litteraturen) ett nyckelbegrepp - tack vare det kanske jag kan komma att acceptera Scrum så småningom.

Stora delar av boken handlar om hur man bör göra enhetstester, integrationstester och systemtester. Bland många exempel och referenser till forskning ges ett som fastnade i mig extra mycket Det handlar om Design for Test - hur man kan designa för test: om vi har fem moduler i produkten är det önskvärt att bara ha fyra kopplingar mellan dem (som i en trädstruktur). Är alla moduler kopplade till alla andra får man en ohållbar situation med för många saker att testa.

Eventuellt kommer jag någon gång satsa på att bli en Istqb Foundation Certified Agile Tester och då kommer jag läsa om boken och även jobba med instuderingsfrågorna.

Tillhör Kategori Test
Tillhör Kategori Boktips

Se även Istqb Foundation Certified Agile Tester
Se även Boken Agile Testing
Se även Boken Software Testing Foundations