Vikten av kontroll
Det finns ett antal olika skolor, inte bara inom test, som pratar om vikten av att styra upp arbetet med någon sorts riktlinjer. De mest rigida är av typen Six Sigma, CMM level 5 där allt ska styras in i minsta detalj. Många av de som jobbat med den typen av metodik säger att det ofta är mycket ineffektivt i systemutvecklingssammanhang. Fokus blir på att tillgodose kraven på dokumentation och inte att jobba så effektivt som möjligt. Som exempel kan nämnas den outsourcing som en del gör till Indien - det mest CMM 5 täta landet i världen. Problemet är att de tar fram PRECIS det vi har skrivit i kravspecen men eftersom det är omöjligt att skriva en perfekt specifikation så får vi inte det vi behöver eller egentligen vill ha.
Mindre styrning - bättre resultat?
Åt det andra hållet finns de lättrörliga metoderna där man fokuserar på att producera fungerande kod och att använda allas kompetens och skicklighet maximalt. Ledaren låter här de som jobbar själv planera och styra sitt arbete till mycket hög grad. Nu är det inte alla som klarar av eller gillar att joba på det sättet.
Frågan just nu
Hur som helst så är mitt senaste uppdrag att införa en testmodell på ett stort företag. Test var till för något år sedan relativt okänt här, men har under senaste tiden blivit mer aktuellt då de börjar bygga större och mer komplicerade system. Jag som suttit på två storbanker och jobbat med rätt så omfattande processer för test funderar på vilken nivå som lämpar sig just här. Min erfarenhet av styrning är att att ju mindre detaljerad den är, desto fler kan tänkas acceptera den. En alltför detaljerad styrning av arbetssätt, eller testfall för den skull, kväver både arbetslusten och det egna tänkandet. En övergripande styrning med STOR PRAKTISK inriktning är mycket mer effektiv. Jag sitter just nu och läser Dale Carnegies klassiker Hur du vinner vänner och påverkar din omgivning. Det står många visa ord där. Bland annat pratar han om att ett effektivt ledarskap innebär att du får andra att själv VILJA göra det du vill att de ska göra. I annat fall kommer många att göra allt för att slippa och säkerligen göra ett jobb som är sämre än deras kapacitet. Så det är viktigt att de som ska använda processen känner stor egen motivation. Det gör man sällan om man är hårt styrd.
Vårt angreppssätt
Valet vi har gjort är att med en relativt liten insats -ca 300 timmar- jämfört med tidigare uppdrag, ta fram en enkel testprocess . Det ingår självklart mallar och exempel för de viktigaste dokumenten som strategier och rapporter. Men målet är att skriva så LITE som möjligt, vilket är betydligt svårare än att skriva mycket! Vi har utgått fran existerande mallar och exempel från både mig själv och kollegor. Hellre enkelt och snabbt är stort och detaljerat. Vi är inne på att antingen skaffa en freewareprodukt för felhantering eller en billigare variant av testfall och felhantering som ReQTEst. Vi ser inte att den kommerciella giganten Quality Center är värd den höga kostnaden. Det bästa exemplet på väl fungerande freeware är Linux som jag tror kommer att ta över efter Windows inom tio år. Införandet är som alltid en större utmaning. Jag tänker mig en 2-3 timmars intro till alla om test på företaget och test i allmänhet, sen en grundkurs på två dagar och en testdesignkurs på två dagar för de som ska bli testare. Ytterligare påbyggnad för testledare en dag plus mentorskap i samband med projekt. Vi vill ha två personer som är experter på programtest och förslagsvis N-Unit. Vi får väl se hur det går. det beror helt på viljan att satsa den tid som det kommer att kosta.