Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
I ethvert ERP-projekt er test et ufravigeligt tema … og med god grund. Det er gerne her, mange komplikationer og hovedpiner kan undgås efter go live.
Et vellykket forløb omkring test vil ikke kun danne grundlag for, at løsningen er sammenhængende.
Det vil i stor grad underbygge overfor en forretning, hvorledes hele værdikæden fremadrettet kan og vil fungere, og vil således indtage en funktion som oplærende element i hele projektet.
I mange af de projekter, jeg bliver tilknyttet, vil man i løbet af projektet komme frem til den konklusion, at der er brug for et mere dedikeret fokus på test.
Jeg oplever ofte, at der opstår en tiltro til, at hvis der ansættes en dygtig test manager, vil det være muligt at få gennemført en test, der vil bane vejen for en succesfuld ’go live’.
Man vil gerne vende øjnene mod sin implementeringspartner, der også vil være i stand til at bringe projektet fremad på baggrund af erfaring og kompetencer fra mange tidligere projekter.
Alligevel viser det sig ofte mere vanskeligt at komme i gang med en ordentligt plan, og ofte er det svært at holde fokus på det helt elementære, der skal være på plads.
En teoretisk dygtig test manager vil let komme til at sammensætte en teststrategi, som vil sikre en ekstraordinær god test af en løsning, hvis den kan føres ud i livet.
I alle tilfælde forholder det sig dog således, at test skal udføres af projektets deltagere, som slet ikke har de samme forudsætninger for at kunne absorbere og forholde sig til abstrakte termer og krav om, hvorledes en løsning skal testes, hvorefter en test gerne kommer haltende fra start og projektet hurtigt mister momentum.
Der vil kunne opstå en følelse af afmagt og frygt for, at systemet faktisk ikke passer til den forretning, der skal understøttes. Eller endnu værre, at projektdeltagerne faktisk ikke er i kontrol med, hvad der er blevet skabt.
Helt basalt er det af yderste vigtighed, at den teststrategi, der lægges for dagen, vil tilgodese den laveste fællesnævner, således at der kan opbygges en solid testpakke, hvor forretningsdeltagere i projektet har en reel mulighed for at tage det ansvar, der opbydes.
Man skal som test manager til enhver tid gøre sig tanke om, hvordan det er muligt at forsimple testaktiviteter, fra opbygningen af testcases til gennemførsel, rapportering og gentest af identificerede udeståender og fejl.
Hvornår begynder test management
Eksamen er en fest for den velforberedte. Det samme gør sig gældende for test i ERP-projekter.
Som udgangspunkt er det vigtigt at forstå, at den egentlige test ikke omhandler test af et system. Omdrejningspunktet skal være forretningens processer og netop derfor starter arbejdet hen imod en succesfuld gennemført test langt tidligere end tiltænkt.
Allerede i modellering og design af løsningen bør der tages højde for en ensartet og struktureret dokumentation af de forretningsprocesser, der fremadrettet skal understøttes af løsningen.
Dette tjener ikke kun til formål at kommunikere klart med konsulenter og udviklere. Ej heller til træning af brugere på et senere tidspunkt. Det skal også danne rammen om de varianter af processer, der vil være behov for at teste.
Man vil således have gjort sig selv en stor bjørnetjeneste, hvis man har fortravlet sig og undladt nødvendig dokumentation.
I så fald vil testopgaven skulle starte med en opsamling af, hvad det egentligt er, man har designet og implementeret, hvilket hurtigt vil kunne åbne op for filosofiske spørgsmål om, hvorvidt det endelige løsningsdesign faktisk er i tråd med det tiltænkte.
Undgå detektivarbejdet
Når de endelige test af forretningsscenarier herefter påbegyndes, vil man i flere omgange befinde sig i situationer, hvor der bliver meldt fejl ind, hvor det kan virke uklart, hvorfor løsningen ikke fungerer efter hensigten.
Så begynder detektivarbejdet. Er stamdata sat rigtigt op? Er alle steps udført, som de skal? Er det et spørgsmål om rettigheder?
I sidste ende kan det ende ud med en fejl, men vejen til at identificere dette er ofte længere end tiltænkt.
Man bør derfor have for øje at fjerne al risiko for tvetydige testresultater, og derfor er det vigtigt at have styr på den rigtige rækkefølge af forskellige test.
I løbet af udviklingsfasen bør alle enkeltdele af løsningen være testet af, således at det ikke er funktionalitet i den enkelte funktion, der vil opstå som fejl. Herefter vil det være muligt at teste de enkelte processer.
Når disse er testet uden fejl, vil man slutteligt kunne gennemføre scenarietest, hvor komplette gennemløb igennem værdikæden testes og valideres.
Her kan der ligeledes sondres imellem, om der testes med forretningsmæssige roller, eller om man gennemfører de første end2end test uden at skele til rettigheder.
Her er det i høj grad af betydning, at der testes ud fra et afgrænset og klart kommunikeret testgrundlag, så man er sikker på, at eventuelle fejl ikke skyldes uhensigtsmæssigheder i stamdata.
Stamdata bør testes separat, hvilket bør være en aktivitet i sig selv og ikke sammenhængende med test af løsningen.
Hold fast i de gode dyder
En korrekt tilgang til test sikrer, at en forretning har muligheden for at påtage sig et reelt ansvar for en løsning.
Dette er et mål, der bør række udover projektets levetid, således at fremtidige releases kan testes i samme form af forretningen.
Der bør være en selektiv stillingtagen til hvor dybt og bredt, test bør pågå alt efter hvilke releases, man ser frem imod, men ubetinget af dette bør man bibeholde et dokumentationsniveau og et forretningsmæssigt procesansvar, der efterlader en forretning med muligheden for at kunne sikre sig, at den løsning, de arbejder med, altid vil være valideret og sikret, så medarbejdere ikke møder ind til ukendte fejl og stop i eksekveringen af dagligdags aktiviteter.
Tre gode råd
Der er mange faldgruber i test management. Helt grundlæggende handler det om at tænke sig om tidligt, så man ikke får malet sig op i et hjørne. For at sikre den bedst mulige tilgang bør man derfor overveje følgende:
Tænk test ind så tidligt som muligt
Grundstenene til et godt testforløb og muligheden for at placere ansvaret korrekt fordrer, at du tænker test ind i det forarbejde, der gøres tidligt.
Sørg for struktur og disciplin omkring procesdokumentation og italesæt, at dette vil være fundamentet for en lang række af aktiviteter igennem projektet … herunder test.
En logisk slutning af dette kan mange gange være, at den, der bærer ansvaret for processer, også bør tage ansvaret for test management.
Test er et forretningsmæssigt ansvar … men der er brug for struktur og styring
Selve gennemførsel af test skal ikke blot være klart kommunikeret.
Deltagere i et projekt er ofte ikke professionelle projektdeltagere men medarbejdere udvalgt i forretningen til at varetage et ansvar, og fortolkningen af, hvorledes de skal udføre opgaver, påhviler ikke dem men testmanageren.
Alle opgaver og aktiviteter skal assisteres, så opgaven for testere lettes i størst muligt omfang.
Vælg det rigtige værktøj
Tag dig tiden til at overveje, hvilket værktøj der vil give både testere og test manager de bedste muligheder for at få gennemført værktøjet.
Hvis det valgte værktøj er for komplekst, så vil der skulle bruges uforholdsmæssigt meget tid på at sikre sig forståelse heraf, som således vil fragå den egentlige test.
Omvendt bør den valgte løsning heller ikke være så forsimplet, at den ikke kan danne baggrund for klar opfølgning, kommunikation og tilretning af identificerede fejl og uhensigtsmæssigheder.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
