Testområdet bliver nedtonet eller skubbet til den sidste fase i projektets liv. Det er hvad jeg oftest ser I større software-udviklingsprojekter. Det giver typisk meget store omkostninger for projektudviklingen - samt en forlænget udviklingstid, med endnu større omkostninger til følge.

 

tomvejno 200x200Projekter, der ender i en eller anden form for fiasko, er velkendte. Det er velkendt, at op til 70% af alle projekter bliver identificeret som fiaskoer eller kørt af sporet; definitionerne er mange. Årsagerne bliver aldrig analyseret til bunds, da det jo også koster ressourcer. Derfor pakkes de oftest af vejen i en fart, frem for at analysere rod-årsagen til projektets tilstand. Ledere og ressourcer flyttes, uden at lære af projektets fejl – så de kan lave de samme fejl igen, uden at være vidende om det.
Jeg har indenfor de seneste 15 år deltaget i 10–12 større projekter. Set i bakspejlet er der åbenlyse faktorer, der kunne have været ændret med stor økonomisk fordel. Ledelse og tidspres er oftest en af synderne - sammen med manglende kvalitet i de krav, der ligger til grund for projektets scope. Et af de områder, man relativt nemt kan ændre - og dermed implementere i et projekt - er testområdet, og det er det område jeg gerne vil stille fokus på.
I fasen, hvor man initierer projektet og udvikler de krav, der er i projektets scope, inddrager man normalt projektlederen af projektet. Hvis man i samme fase også tog testmanageren med i arbejdet med kravene, så ville man få mere optimale betingelser for at projektet kan afsluttes med succes.

 

Gør straks kravene testbare
Hvorfor nu det? Flere ting taler for dette – det første er at man allerede i arbejdet med de krav der skal udvikles til scope, forholder sig til, hvorledes man skal teste kravene. Om de så er baseret på Use Cases eller er skrevne krav, er underordnet. Men ved allerede i denne fase at gøre kravene testbare - samt opstille de succeskriterier, der senere vil være for en accepttest - får man elimineret de krav, der ikke er testbare, og dermed forholdt sig til dem før udviklingen bliver igangsat.

 

Krav, kvalitet og kroner hænger sammen
Det forhindrer senere fejlkodning, og dermed defekts i softwaren – samt at man får lavet en høj kvalitetssikring af de krav, der skal være i scope. Dette kan i større projekter spare fejludvikling og dermed tid. Tænk på en projektorganisation med 40 deltagere – der bare på den konto kan spare to-fire mdr. analyse- og udviklingsarbejde, hvilket i samme organisation repræsenterer en værdi på 3,2 til 6,4 million DKK. Den besparelse kan opnåes, blot ved at håndtere kravene til scope korrekt i forhold til scope. Det vil sikkert stille større krav til dem der er ansvarlige for kravene, men i det forhold er det en mindre omkostning.
Den optimale løsning i dette perspektiv kan være at opstille en betingelse om, at krav leveres sammen med testcases og derigennem de succeskriterier der er for udvikling. Det giver projektet en god start, en god besparelse, hindrer mange misforståelser samt konkretiserer projektets formål yderligere.

 

Tidlige reviews
Dette giver også muligheden for at indføre reviews tidligt i processen. Om man arbejder med V modellen eller andre udviklingsmodeller, er irrelevant i denne optik. Den funktionelle specifikation får en højere kvalitet. Det smitter af på den tekniske specifikation og til sidst på programspecifikationen der skal kodes efter. Under hele denne proces er det muligt at lave statisk test, før der er kodet en line – og dermed reducere muligheden for fejl-analyse samt fejl-kodning. Dermed får man et produkt, der har en høj kvalitet, hvor alle projektdeltagere ved præcist, hvad der forventes af dem i relation til slutresultatet. Det gør også, at de andre discipliner i projektet bliver enklere at håndtere, samt at risikologgen ikke bliver et uoverskueligt dokument, der er svært at forholde sig til for styregruppen/ledelsen af projektet.

 

Modenhed samt andre områder kunne med fordel have været belyst, men min klare anbefaling i denne artikel er:
Brug mange ressourcer på at finde den rigtige projektleder. Brug de samme ressourcer på at finde testmanageren, så de sammen kan arbejde med projektets scope fra begyndelsen. Det er der rigtig mange penge i – rigtig mange.

 

Artiklen er skrevet af Tom Vejnø, Senior Project Manager