När Ni läser detta inlägg så ber jag Er att ha i åtanke att jag är positiv till Agil utveckling och aktiv i Agila rörelsen genom att sitta i Styrelsen för DSDM konsortiet samt är med och anordnar den årliga konferensen ”Agile i Sverige”. Det jag skriver nedan kan om man inte har detta i åtanke tolkas som att jag är en stark agil motståndare, vilket vore ett misstag.
Om du är en erfaren tesledare så känns det ofta ganska skönt, om än ovant, att ta klivet in i ett agilt projekt. Det är på många sätt befriande att slippa försöka verifiera bristfälliga, mångtydiga krav och istället fokusera på kundnyttan. Likaså så känns det oerhört effektivt att slippa skriva långa testplaner med löpande text och standardformuleringar inför varje projektuppstart och/eller iteration Även bugg rapportering blir lättare då man sitter i teamet och därmed pratar ansikte mot ansikte med utvecklaren. Till och med den tidigare så viktiga testrapporten, blir relativt oviktig då mycket av det väsentligaste ändå framkommer via projektets övriga aktiviteter, jag tänker då i förstahand på (om du kör SCRUM) D.O.D, demo och retrospective.
Detta innebär ju dock inte att du inte planerar dina tester, inte följer upp buggar eller inte kommunicerar hur dina tester går. Allt detta gör du ju med ryggmärgen och intuitivt, skillnaden är att den inkrementella utvecklingen tillåter dig att effektiviserat det hela genom att att göra scopet för iterationen greppbar och därmed möjlig att planera och kommunicera utan en massa omständliga dokument..
Jag tänker mig nu om jag som helt oerfaren som testledare och skulle ha hamnat som ansvarig för systemtester i ett av de lite rörigare ej helt renläriga agila projekten som det finns så gott om. Utan stöd för eller krav på att redogöra för hur testningen kommer gå till (muntligt eller via testplan) är det högst troligt att det mest skulle ha blivit adhoc testning och brandutryckningar utan vidare eftertanke eller strategi. Jag skulle förmodligen ryckas med och endast fokusera på den synliga hands-on kundnyttan och glömma bort att det finns en stor del underliggande funktionalitet som måste verifieras i någon form (så som beräkningar, juridiska aspekter , underhålbarhet, negativa tester, felhantering m.m.). En del av dessa kräver dessutom krav att verifiera emot, eller en hel stab av specialister att tillgå.
Det skulle antaligen krävas ett par produktions stopp innan jag insåg vikten av att följa upp statusen på hittade buggar om jag inte tvingats till detta genom att rapportera in dem i ett felhantering system med tvingande/styrande process. Dess felhanterings system är ofta byråkratiska tidstjuvar med många obligatoriska fält, men de har i varje fall lärt mig vad en felrapport behöver innehålla, vad den inte behöver innehålla ( fälten som man alltid fyller i på samma sätt eller hittar på ett värde till) och vikten av att följa upp att buggarna faktiskt rättas till och inte återkommer i nästa version.
Utan att tvingas skriva en utförlig testrapport efter en alldeles för omfattande mall, skulle det antaligen även krävas ett par smällar innan jag insåg vikten av att på något sätt visa för omgivningen vad vi i test faktiskt har testat och under vilka premisser och kanske framförallt, vad vi i inte testat.
Så med facit i hand så är jag är faktiskt glad att jag började min bana som testledare i ett byråkratiskt vattenfalls projekt, sådana projekt som jag idag undviker i möjligaste mån. Annars hade jag nog inte blivit långlivad som tesledare utan flytt tillbaka till Java kodnings träsket som jag kom ifrån.
Fallgroppar så som dessa gå ju naturligtvis att undvika genom utbildning, mentoring och kunskapsöverföring, men det gäller för individen att inse behovet av detta. Så håll utkik efter nybörjare och delamed dig av din kunskap och dina kunskapskällor om du träffar på någon, sedan är det upp till denne att och suga åt sig, värdera och bearbeta all tillgänglig information. Om inte annat, så kan du ju alltid viska TestZonen.se i nybörjarens öra.
Ja, jag tror det är enklare att klara sig i Agila projekt om man har någorlunda lång erfarenhet av mer struktuerade processer. Ju äldre jag har blivit desto mer intresserad är jag av agiliteten då jag har känt av risken med att ha en alltför dokumenterad process där allt skall gå via en plan som är gjord på uppskattningar när man visste som minst – dvs från början.
Väl skrivet Jonas. Och tack för att du som representerar 70-talisterna sällar dig till mig och den äldre generationen av 40-, 50- och 60 talister som vill kombinera våra erfarenheter av effektivt utvecklings och testarbete med de senaste ”flugorna” som Agile och Scrum.
Nästan alla som i sina krönikor eller bloggar skiver om det nya fenomenet ”Agile eller Scrum” känner ju till den magiska laddningen som ligger i dessa ord. Som en magnet (sockerbit) drar det seminariedeltagare och bloggläsare till sig.
Jag brukar säga att det allra bästa med de nya orden är den friska debatt och intresse som skapats kring de lite tråkiga ord som systemutvecklingsmetodik och testmetodik, två områden som intresserat mig sedan 70-talet. Metodik uppfattar många som styrning, regler, anpassning till standarder och aldrig någonsin har den nya generationen av 80- och 90-talister attraherats av sådant som vuxit upp med Dataspel och spel på nätet. Missuppfatta mig nu och tro att jag menar att Agile och Scrum bara gillas av de yngre.
Så vi kommer att se en mängd exempel av ungdomar med bra affärsideer inom IT som växer till produktföretag som kommer att upptäcka för sent att man saknar erfarenheten och Best Practice för att kunna överleva. Till detta behövs rätt metodik, struktur, process, verktyg som ger rätt kvalitet. Kanske finns det hopp om jobb för Jonas och mig med om den insikten finns våra kunder.