Hvor vanskelig kan det egentlig være? Dette sitatet har aldri vært sagt av en testleder, men jeg har hørt det flere ganger i innføringsprosjekter. Av prosjektdeltakere, sluttbrukere og andre som venter utålmodig på at systemet, som er forsinket på 3 året skal bli “Ferdig”.
Uavhengig av omfang og kompleksitet på prosjektet, må testledere, fra leverandørsiden og kundesiden alltid bidra til at at systemet som skal i produksjon har blitt tilstrekkelig testet. Det betyr at prosjekteier, gjennom testrapportering, har fått god nok oversikt over produktkvaliteten, til å kunne ta beslutninger som leder til Go/No-Go for produksjonssetting.
Så, hvordan sørger vi da for at systemet er tilstrekkelig testet? I denne artikkelen tar jeg for meg kundens verdikjedetest i et innføringsprosjekt. Vi tenker oss at all test fra lavere nivåer er gjennomført og godkjent av kunden. Det som gjenstår nå er kundens akseptansetest, som inkluderer verdikjedetest.
Testprosessen
Testprosessen som beskrevet i fig 1 og testpyramiden i fig 2 , viser prosessen frem til testavslutning. Pyramiden beskriver fire testnivåer, der alle faser i testprosessen må gjennomføres og avsluttes med godkjenning, før neste fase kan starte. Når akseptansetesten er gjennomført leveres en testrapport som beslutningsgrunnlag.
Ende-til-ende test, som både kan være en del av systemtest og akseptansetest, tar ikke alltid tilstrekkelig hensyn til forhold som ligger utenfor direkte integrasjoner med systemet. Verdikjedetest handler om å validere at systemet fungerer på tvers av arbeidsprosesser, via indirekte tilstøtende systemer og deres prosesser. Eller sagt på en annen måte. Følge dataflyten gjennom alle systemer og prosesser.
Alt dette er vel og bra, men veldig teoretisk. Strukturert test med kvalitetssikring på hver enkelt testnivå er helt klart det noe av det viktigste vi gjør i en god testprosess, men er det godt nok?
Forutsi det forutsigbare
Testinnsatsen må også dekke bredere enn bare å bruke krav og prosesser som er systemnært som testgrunnlag. Vi er nødt til å teste bredere, langt utenfor det testsystemet vi har tilgang på. Det betyr også at verdikjedetest må gjennom alle fem fasene i testprosessen, ikke bare de tre siste . Det er mange utfordringer vi må løse for å få til dette. Prosjektet vil ofte ikke være rigget for verdikjedetest, så vi er nødt til å få dette med i teststrategien vår. Det er utrolig viktig å starte tidlig med å samle informasjon og få en oversikt over brukergrupper, prosesser og andre forhold som vil påvirkes av innføringen av systemet. Uten dette forarbeidet blir verdikjedetesten kun stikkprøver og flaks om vi treffer på de scenarioene vi ønsker å validere mot. Det aller viktigste er likevel å forankre behovet for verdikjedetest hos prosjekteier, for å gjennomføre aktiviteter knyttet til verdikjedetest. Uten dette vil det garantert oppstå uforutsette problemer som i verste fall kan ramme prosjektet hardt.
Årsakene til at innføringen av en systemendring ikke ble like vellykket som forventet, forsinket eller vesentlig dyrere, er ofte knyttet til helt andre forhold enn antall bugs, eller tekniske svakheter. Eksempler på “uforutsigbare” forhold kan være at kunden ikke har hatt nok fokus på endringsledelse i mottaks organisasjonen, eller at prosjektet ikke har knyttet til seg riktig type kompetanse og brukere som kunne identifisert problemstillinger tidlig. Dette kan være nødvendige oppdateringer i andre systemers brukerveiledninger, eller grunndata som ikke vil kunne fungere sammen med det nye systemets prosesser eller teknologi. Dersom tilstøtende systemer eller tilstøtende prosesser som blir påvirket ikke har blitt tilpasset i tide, kan det medføre både forsinkelser og andre problemer.
Løsningen
Det viktigste for en god verdikjede test er at prosjektet, som en del av testprosessen, allokerer tilstrekkelige og riktige ressurser til verdikjedetesten. Dette kan forhindre kritiske og stoppende problemer. Det er også viktig å merke seg at det ikke er antallet scenarier som skal valideres som er viktig, men treffsikkerheten på de scenariene vi velger å validere. Disse scenariene er ofte ikke enkle å finne, heller ikke ved å bruke KI, selv om KI kan hjelpe oss. Scenariene må defineres av brukere som har historisk og inngående kunnskap om organisasjonen systemet skal innføres, såkalt skjult kunnskap. Kunnskap som ikke er skrevet ned, og som KI ikke nødvendigvis vil kunne finne. Det er heller ikke nødvendigvis veldig mange og komplekse verdikjeder vi trenger å validere, da verdikjeder som involverer offentlige registre og andre kjente grensesnitt, ofte er godt validert. Med andre ord. Planlegg og gjennomfør utvalgte verdikjede flyter med nøyaktige og godt gjennomarbeidede parametere og tilhørende test data. Det er egentlig alt. Det er treffsikkerheten på scenariene, både happy-path og negative, som er avgjørende for at vi kan redusere risikoen.
Denne artikkelen er skrevet av Øyvind Woll, han jobber i Promis Qualify.