Gästpost: IT-utveckling är ett lagspel

Publicerad 18 november 2016 | Inga kommentarer ännu

Idag kan jag stolt presentera ett gästinlägg här: Anders M Olausson som skriver om en viktig del som jag själv inte berör så mycket i boken: vikten av test, och att testa återkommande. :)

———

IT-utveckling är ett lagspel

När jag läser Jonas Söderströms bok, ”Jävla skitsystem” så är igenkänningsfaktorn jättestor och jag skrattar ofta innan jag blir bedrövad. Hur kommer det sig att vi år 2016 är dåliga på att bygga IT-system när vi egentligen borde veta hur man gör? För de flesta exemplen i boken känner jag ”Jag vet varför det blev fel!”

Jonas förklarar mästerligt hur man måste lyssna på användarna, ta hänsyn till andra system runt omkring osv. Sen beskriver han även hur man skall låta användarna testa systemet innan man går i drift. Men mellan kravinsamling till driftsatt IT-system är det väldigt många steg, även om man arbetar agilt. Det är de stegen jag vill komplettera Jonas bok med.

Jag har jobbat med IT-utveckling i 20 år och test i 10 men det är under de senaste 4, då jag främst ägnat mig åt utbildning inom test och krav, jag har funderat på varför det så ofta blir fel.

Jag är inte ensam om att vilja berätta ”vad som gått fel”. Andra talar om dålig upphandling, dålig projektledning, fel system, dåligt UX osv. Det påminner ganska mycket om sportreportrar och fans som berättar vem som bar skulden för gårdagens förlust. Oftast har de rätt, vi har allihop rätt, men det är sällan det är ett fel som gör att IT-system inte blir bra eller att vi förlorade.

Varför upptäcks det så sent att man bygger ett dåligt IT-system?

Ofta när företag inser att deras produkt inte håller måttet, så anställer de testare, eller ännu oftare ger de någon anställd ansvaret att testa den färdiga produkten. Att försöka lösa kvalitetsproblem med test av en färdig produkt är lite som att bota tandvärk med Alvedon. Det blir kanske lite bättre temporärt men vi måste se till att man hanterar roten till det onda.

Precis som det är viktigt att ha med användare redan i kravarbetet, för att de skall använda systemet senare, så är det viktigt att ha med testare för de skall testa systemet. De behöver kontrollera om kraven är testbara och kan hjälpa till att göra systemet lättare att testa. Det gör kvalitetssäkringen både billigare och bättre.

Projektledning, krav och test måste jobba tillsammans redan från början för att skapa stabilitet i utvecklingsarbetet. ”Men du har glömt, UX, systemarkitekter, användare, driftspersonal med mera” säger du då. Nej, de kompetenserna ingår i de tre kategorierna ovan. Ju större betydelse en kompetens har för ett specifikt projekt desto viktigare är det att ta in den tidigt i projektet. Ju större betydelse en kompetens har för ett specifikt projekt desto viktigare är det att ta in den i projektet tidigt.

Det är ofta fel i kraven, antingen är de bristfälligt inhämtade, felaktigt formulerade, har fel fokus eller fel detaljnivå. Inhämtning av krav har Jonas redan skrivit mycket om så den biten hoppar jag över.

Alla fel i kraven kan få allvarliga konsekvenser. Om vi förutsätter att de är rätt insamlade så är det ur testsynpunkt viktigt hur de är formulerade. De måste formuleras på ett sådant sätt så att det inte kan bli missförstånd, de får inte vara tvetydiga, vilket är mycket vanligt. De måste gå att testa och vara mätbara annars kan vi inte kontrollera om de uppfyllts. Kravinsamlande och kravformulering är en egen kompetens, och det man samlat in bör även det testas.

Vi måste kontrollera de små delarna innan vi sätter ihop dem till större enheter. Det är mycket lättare att hitta brister då, än när vi satt ihop hela system.

Kompetensbrist?
Test och kravställning blir allt viktigare ju mer komplexa system vi bygger.

Det finns dessvärre många som arbetat länge med test som inte ens har grundläggande kunskaper i testdesign. Precis som för utveckling kräver testarbete olika kompetenser och tekniker beroende på vad vi just nu håller på med för del av systemet Att testa utan att kunna testdesign, är väldigt ineffektivt. Många andra använder gamla och ineffektiva arbetssätt vilket ofta ger testarbetet dåligt rykte.

När jag började jobba heltid med IT-utveckling, i mitten på nittiotalet, så fick jag höra att jag var ”duktig på datorer”. Det innebar att jag kunde hantera såväl hårdvara som operativsystem och mjukvara. Idag har IT blivit så oerhört komplext så att säga att någon är duktig på datorer är som att säga att någon är duktig på sport, vilket innebär allt från schack till styrkelyft. Det är fullständigt omöjligt för någon att kunna allt.

Test i sig självt håller på att bli lika komplext och det finns få som kan hantera alla de discipliner som ingår. Men ingen behöver kunna alla dessa delar för precis som för all annan IT-kompetens så behöver man resurser som motsvarar det vi just nu skall utföra. Det skiftar inte bara med tanke på vad vi utvecklar utan även när i utvecklingsprocessen vi är och storleken på projektet.

Det krävs till exempel kompetens i att:

• Fånga upp och formulera krav
• Bygga en arkitektur
• Skapa gränssnitt
• Utveckla systemdelar
• Sammanfoga de olika delarna till ett system
• Integrera med andra system
• Driftsätta och förvalta systemet tills det en dag skall tas ur drift.
• Sätta systemet i händerna på användare och lära dem hur man gör genom att ge dem manualer och att utbilda

Alla dessa aktiviteter behöver testas innan man går över till nästa. Teknikerna för att testa i de olika aktiviteterna skiljer sig avsevärt. Det gäller även om du skall utföra nästa steg själv. När du sätter upp en hylla i ditt hem så mäter du att den har rätt längd innan du börjar skruva upp den. Finns det någon anledning att inte mäta (testa) hyllans längd förrän den sitter färdigmålad på väggen?

Ju senare vi hittar ett fel desto mer insatser kräver det att korrigera och ju dyrare kan felrättningen och/eller konsekvenserna bli. Det gäller även vid agil utveckling, även om kurvan för kostnaden då inte är så brant. Det finns personer som har kompetens i flera av de här disciplinerna men jag har aldrig träffat någon som är bra på allt.

Att snåla in på testkompetens gör inte projektet billigare, oftast blir det dyrare.

Parallellerna med ett lagspel som till exempel fotboll är inte svåra att se.

Om vi jämför testande med fotboll kanske det blir enklare att förstå.

Beroende på vilka vårt lag skall möta så väljer vi de spelare som bäst motsvarar det motstånd vi kommer att ställas mot. Om vi möter ett dåligt lag eller om matchen inte har så stor betydelse så behöver vi kanske inte sätta in våra bästa spelare och vi behöver kanske inte träna så mycket innan. Det innebär på inget sätt att vi kan slarva med genomförandet. Vi måste använda de resurser vi fått tilldelade på bästa sätt. Möter vi ett anfallsstarkt lag så kanske vi väljer en strategi med en stark backlinje och om vi behöver göra många mål för att gå vidare till slutspel kanske vi satsar på många anfallare.

Man måste sätta allt i ett sammanhang, det gäller såväl fotboll som utveckling och test.

Forskning, vilket innefattar utvecklingsteam hos bland annat Google, bekräftar att teamet är viktigare än de enskilda medlemmarnas spetskompetens.
The Most Productive Teams at Google Have These 5 Dynamics

Vad är test i fotbollslaget?

Så vilken plats har mitt specialområde test i vårt lag? Är det en målvakt, en libero eller rent av en anfallare? Ingetdera, testarna är snarare en läkare eller fysioterapeut som ser till att alla spelare är i bra kondition och håller en hel match. De skapar egentligen ingenting men är för den sakens skull inte oviktiga för laget. De märker långt innan match i vilken kondition spelarna är. Tror de inte att en spelare kommer att klara av att spela får de sätta in en åtgärd, alternativt se till att någon annan tar hens plats.

Man samtidigt måste vi komma ihåg det egna ansvaret, den egna kontrollen. För även om vi har fysioterapeuter (testare) och läkare (testledare) så har vi ett eget ansvar för vårt hälsotillstånd. Det är jag själv som först upptäcker om jag har feber eller har ont i knät. På samma sätt måste utvecklare kontrollera sitt eget arbete vilket kräver grundläggande kompetens i testdesign.

Fysioterapeuter stöttar spelarna i hur de skall träna för att bli starkare, alternativt jobba förebyggande för att inte bli skadade igen. Testare arbetar även med att stödja och hjälpa utvecklare att testa sitt eget arbete. Att fysioterapeuter lägger över det mesta ansvaret för rehabilitering på spelarna innebär inte att de gör sig själv redundanta.

Utvecklare kan inte förväntas vara bra på allting inom IT-utveckling. Om de lägger tid på att bli bra även på att testa, så har de inte tid att även bli bättre utvecklare.

Zlatan skall inte lägga tid på att bli en bättre målvakt.

Om vi testar tidigt är det lättare att lansera i tid och kostnaderna hålls nere. Vi får också nöjdare kunder och användare.

Hur det hänger ihop tänker jag berätta i en senare bloggpost.

——

Anders post finns också på testbloggen.se.

Kommentarer