Granskning

Det finns undersökningar som visar att så mycket som ca 50% av felen härrör från kraven. Dvs om vi kan hitta felen redan vid kravarbetet så kan vi arbeta mycket mer effektivt. Dessutom så är det mycket billigare att hitta ett fel så tidigt som möjligt. Ett fel som hittas under kravgranskning tar mycket mindre resurser i anspråk att rätta, kanske endast en minut, än ett fel som hittas i drift som kan ta flera dagars arbete i anspråk. Och med tanke på alla buggar som hittas sent och som kostar mycket att rätta är det konstoigt att man inte lägger mer tid på granskning. Fast det är förstås avårt att bevisa att det kommer att vara lönsamt med ordentlig granskning, just detta projekt kommer förstås inte att ha problem med kraven. Och kostnaden för att genomföra granskningsarbetet är lätt att peka på, men vinsterna är mycket svårare att se. Men granskning är mycket effeltivt och borde genomföras i alla projekt.  Varför görs det då inte mer, en förklaring är som tidigare nämnts att projektledningen och den som beställt utvecklinen inte är säker på granskningens förträfflighet. En annan anledning är att det är svårare att göra bra än att säta sig med ett program och klicka och leta fel. Ytterligare en förklaring är att tidsbrist också slår till mot testgruppen. När trycket ökar börjar även den mest nitiske granskare att tvingas att fokusera på at testa leveransen som nyss kommit istället för att granska kraven för en framtida version av systemet.

Anledningar till att man ska arbeta med granskning är bland andra:

• Upptäck felen tidigt

Genom att granska kraven kan man redan på skrivbordsstadiet upptäcka många fel. Och testare är det bästa granskarna. Testare är kritiska, vana att granska krav, har ofta stor kunskap om systemet. Och en erfaren testare funderar instinktivt på hur kravet ska testas i testfall och testdata.

• Ta bort onödiga krav

Granskning av testfall inte bara upptäcker fel tidigt, det visar också då och då att krav som ställs inte är viktiga. Det man ville lösa med kravet kanske går att lösa med en befintlig funktion i systemet.

• Informationsglapp kan minskas

Då flera delprojekt ska leverera fram en lösning är det stor risk för informationsglapp. Eftersom det är svårt att se till att information hela tiden delges alla och eftersom det är lätt när trycket börjar öka att de olika projekten fokuserar mer och mer på sin leverans och inte har tid att prata med övriga projekt så är risken alltid stor att man mot slutet ser att leveranserna som är beroende av varandra inte överensstämmer helt. Exempel kan vara:
Parametrar som webbgränssnittet behöver inte har nått fram till webbtjänstprojektet som därför behöver lägga mer tid på att utveckla, eller kanske tom göra om vissa funktioner.
Det visar sig att det saknas hela funktioner eftersom kraven i det ena projektet fortsatt att utvecklas utan att den information nått fram till det andra projektet.

För att undvika informationsglapp är det förstås viktigt att de som arbetar med kravställningen hela tiden ser till att alla projekt hålls uppdaterade. Det är enkelt att säga men svårare att genomföra i verkligheten. Ofta är ju IT projket under stark tidspress och måste hantera förändrade och utökade krav som gärna ska hinnas med inom samma tid. Här hjälper dock inte en master testplan, men genom att testgruppen har kontroll över flera projekt är det möjligt att man kan se där glapp finns och peka på detta för projektlednignen. Detta pekar på att det ofta kan vara bra att låta testpersoner vara med och granska kraven. De kan ofta ha en bra överblick och även kritiskt kunna granska hur hållbara kraven är.