Det är tyvärr en allt för vanlig sanning att när ett projekt stöter på ett problem så är tid för test en av de första posterna som får stryka på foten. Det ligger viss logik i det, i och med att om projektet inte är klart så finns det ju inget att testa. Om projektet får tillräckligt med tid på sig för utveckling så kommer det att finnas färre fel för test att hitta och testjobbet blir enklare. Det låter ju rätt så rimligt, eller??

Men om man har varit med några omgångar så lär man sig snabbt att så inte alls är fallet. Testerna går sällan snabbare och fel dyker upp ändå. Det kan givetvis vara en stor mängd orsaker som ligger till grund för detta men en av de största orsakerna ligger i hur testarbetet har implementerats.

Att man bör testa tidigt under utvecklingen är något man gärna säger men väldigt få möjliggör. Vanligtvis så landar ursprungskravställningen i händerna på en testledare sent i processen. Han/hon rekryterar i sin tur personal från verksamheten för att bedriva acceptanstester. Verksamheten gör sen tester utifrån hur systemet kommer användas på riktigt och i bästa fall skiljer dessa två värdar sig inte allt för mycket åt.

Vanligtvis leder detta till kommentarer såsom: ”Testarna är ju aldrig nöjda” och ”Vi har följt kraven”. Generellt sett inte särskilt muntra eller hjälpsamma kommentarer men de vittnar om två tydliga problem.

  1. Testarna är ju aldrig nöjda” – Pekar inte bara på att kvalitén på leveransen inte lever upp till vad som krävs för verksamheten, utan även på att man inte förstår att test är en del av utvecklingen. Man är på samma sida och målet är att leverera något som genererar värde för företaget. Målet med ett utvecklingsprojekt är inte att bli klara med sin del, utan att leverera värde.
  1. Vi har följt kraven” – Är ett vanligt sätt att förklara varför man gjort på ett visst sätt. Det tråkiga som följer med ett sådant här uttalande är att det nästan uteslutande kommer av misstag gjorda i kravarbetet. Man har lagt ner arbete på att utveckla något som inte genererar det värde som man vill ha.

Så, kan man minska risken för att springa på dessa problem? Ett bra sätt är som sagt att testa tidigare. Och med tidigare menar jag redan på kravnivå. Testa att kravuppfyllnad ger det resultat som verksamheten vill ha. Testa testfallen som skall användas i intigrationstesterna, systemtesterna och i acceptanstesterna. Krav och testfall måste gå hand i hand genom hela kedjan.

Den enkla sanningen är att om man bygger sina utvecklings- och test-processer mera samspelta så kommer både klagomålen om kvalitetsbrister och tidsbrist att sjunka. Att inte begränsa test till acceptanstest och påbörja testerna tidigare minskar totala tiden test, minskar felutveckling och rättningar men framför allt så hjälper det er få ut det värde ur ert arbete som projektet avser.

Det blir helt enkelt lättare att göra rätt!

Vill du veta mer kan du hitta ytterligare information, från mig och mina kollegor, här.

Missa inte heller vårt seminarium som handlar om konceptet Värdebaserad Kvalitetssäkring som vi genomför den 22 april. Mer information och möjlighet att boka sig hittar du här.