Titt som tätt kan vi läsa om stora banker och hur deras mobil- och internetkopplingar ligger nere under flera timmar. Problemet är omfattande och drabbar alla kunder och samtliga digitala betalningstjänster, även appen Swish och telefonbanken. Problemen uppstår oftast i samband med en uppdatering i bankens IT-system. I sådana här lägen är det lätt att ställa sig frågan om man verkligen testat allt ordentligt. Förmodligen anser bankens IT-avdelning det själva, eftersom de ger ok till produktionssättning. Eller var de pressade av deadlines och löften till kund eller beställare om att uppgradera ny funktionalitet? Fanns det kanske ingen annan utväg än att gå i produktion vid en viss bestämd tidpunkt?
Testa tidigt för att slippa onödiga kostnader
Alla som jobbar med test vet att desto senare felen upptäcks, desto dyrare blir det. Det finns olika sätt att räkna fram kostnaden för fel i olika skeden av projektet. En enkel metod är att göra en analys över skrivna felrapporter i kombination med en flödesanalys av felrapportens väg genom projektet. I större projekt kommer detta sannolikt leda till skrämmande höga kostnader som härrör från direkta eller indirekta kostnader kopplade till upptäckta fel. Det finns också en kostnad för den badwill som drabbar företaget om något inte fungerar som det ska vid lansering av en produkt eller system. Detta är ofta osynligt för utvecklingsorganisationen då budgeten är separerad mellan utveckling och support. Det är i kostnaderna för supporten som även effektiviseringar på utvecklingssidan ska hittas.
Det vi vill belysa är att även om vi anser att vi lägger ner tillräckligt med tid på test innan vi sätter våra system och applikationer i produktion så är det kanske ändå för lite, i vissa fall. Vi säger inte att det alltid är på detta sätt, men det händer och det är inte allt för sällan. Då, om inte förr, behöver man se över vilka metoder som används för att hitta fel.
Därför bör du tänka kvalitet redan innan kraven formuleras
Hur kan vi då komma till rätta med denna utmaning? För ingen vill väl produktionsätta ett nytt system med en massa fel! Ändå händer det så ofta och kommer hända ytterligare flera gånger i framtiden.
En del av lösningen är att börja tänka kvalitet redan från början i ett projekt, när kraven ska skrivas – eller ännu tidigare. På vissa företag finns riktlinjer som säger att alla IT-projekt måste ha en testledare och en kravanalytiker för att få starta, och givetvis en del andra resurser också. Finns inte testledaren och kravanalytikern namngivna får projektet helt enkelt inte påbörjas. Detta är en klok strategi. Kanske bör fler företag anamma denna enkla regel för att tidigt få in ett kvalitetstänk i sina projekt.
Om situationen är sådan att kravbilden inte är tillräckligt bra finns lösningar även här. Utforskande testmetodik räcker en lång väg för att identifiera fel tidigt med bristfälliga krav. Det är en testmetod som rekommenderas för att använda i projekten som viktigt komplement till all annan testning.
I ett testprojekt för ”Medical device” för många år sedan infördes utforskande test som ett försök för att se hur mycket mer kvalitetsbrister som skulle kunna upptäckas. Då är förutsättningen här att det fanns 100 procent kravspårning mellan krav och test samt en rigorös testprocess. Efter genomförda tester med utforskande metodik i form av SBTM som metod hade man hittat 80 procent fler fel än med skriptade testfall.
Våga utmana och bli hjältar
Idag tillsätts ofta resurser för test och testledare senare än övriga resurser i projektet. Varför är det så? Vem har bestämt det och på vilka grunder tas dessa beslut? Ofta finns en okunskap om att det faktiskt går att spara pengar i IT-projekten om test och kvalitetssäkring görs tidigt i projekten och med rätt metoder. Våga ifrågasätta detta i de projekt som du jobbar. Kanske kan du bidra till att ni blir hjältar genom att genomföra företagets mest och bäst testade projekt/release.
Ta reda på vem som skriver kraven för det ni utvecklar/testar. Jobba närmare den eller de personerna och diskutera vilka områden som behöver skriptade tester och vilka som kommer behöva utforskande. Att skapa ett team mellan krav och test är många gånger ett av de effektivaste sätten att få in kvalitetssäkring tidigt.
Någon gång har du säkert själv sagt eller hört: ”Det här var svårt att testa när kraven är så dåliga!”. Om det nu ens funnits några krav det vill säga. Den enda som kan påverka detta är DU. Vänta inte till nästa gång det händer utan gå till projektledaren, testledaren eller beställaren och påminn om det faktum att ju tidigare felen kan hittas, desto lägre blir kostnaden. Om de inte lyssnar, ta steget vidare upp i organisationen. Kanske till IT-chefen. Vem vill inte spara pengar i nästa IT-projekt?
Vårt förslag för att nå dit är att öka antalet resurser inom kvalitetssäkring och att göra det med rätt kompetenser. Det bör göras så tidigt som möjligt i processen och med rätt metoder. Gärna redan när projektet ligger på ”ritbordet” för att från början pränta in tänket kring test och kvalitetssäkring för att rätt funktioner ska utvecklas i rätt takt så att systemet eller produkten blir testbar så tidigt som möjligt.
Mer tid till test när insikten ökar om värdet med kvalitetssäkring
En uppmaning till alla som läser detta och jobbar med test: Be om mer tid till test och kvalitetssäkring tidigt! Då kan en stor del av felkostnaden hanteras redan i kravgranskningen och tidiga testfaser. Om alla beställare inser detta får vi som jobbar med test förhoppningsvis mer tid att testa och kvalitetssäkra.
Kategori:Teknik
Behöver du hjälp att få ytterligare argument för att kunna påverka så att ni får mer tid att testa och pengar över till att säkerställa kvaliteten på produkterna ni testar? Tveka då inte att ta kontakt med oss. Vi delar gärna med oss av våra erfarenheter.
Vill du veta mer om hur du skapar en effektiv kravprocess, förstå faktorerna bakom problemen och hur du ställer krav på rätt nivå? Då tycker jag att du ska ladda ner vår guide.
