”Nej, det er da ikke nødvendigt at teste – det er et standardsystem, vi implementerer”. Har du hørt den kommentar før?

Nogle af de antagelser, jeg har mødt igennem årene omkring standard løsninger, har været:

• ”Det virker jo allerede – andre bruger det jo.”
• ”Vi behøver ikke test – vi regner ikke med at lave ændringer.”
• ”Det er hurtigt og billigt at implementere.”
• ”Vi kan tilpasse vores processer til systemet.”
• ”Leverandøren tager sig af det.”
• ”Brugerne lærer det bare henad vejen.”

Alt for ofte ser vi organisationer, der kæmper med at lykkes med at implementere f.eks. nye CRM- eller ERP-systemer, fordi man har undervurderet opgaven.

I denne artikel vil vi dykke ned i, hvorfor implementering af standardsystemer ikke altid er helt så simple, som det ser ud til udefra, og med testbrillerne på vil vi komme med anbefalinger til, hvordan vi kan gribe kvalitetssikringen af disse implementeringsprojekter an.

Men lad os lige starte med en definition:

En standardløsning refererer til en softwarepakke designet til at imødekomme de generelle behov hos en bred vifte af brugere eller organisationer. Disse løsninger er færdigudviklede produkter, der kan implementeres uden væsentlige ændringer.

Her bider jeg mærke i to ting:

1. ”Disse løsninger er færdigudviklede produkter”
2. ”kan implementeres uden væsentlige ændringer”

Umiddelbart lyder det fantastisk, men for de fleste organisationer er det bare ikke den virkelighed, de står overfor, når først de kommer i gang. Lad os prøve at dykke ned i nogle af udfordringerne.

Udfordringer

Processer og arbejdsgange

Hvis vi tager udgangspunkt i Dynamics 365FO, kommer det ganske rigtigt som en færdigudviklet løsning med en hel pakke med en struktur af foruddefinerede processer og arbejdsgange – og en brugerflade, der supporterer dem. Men her er der lige en håndfuld spørgsmål, som vi skal huske at stille:

• Hvordan ser vores arbejdsgange ud i dag?
• Har vi styr på, hvor mange der er? Og er de dokumenteret?
• Passer vores arbejdsgange til de standardprocesser, der er implementeret?
• Er det praktisk muligt at ændre vores arbejdsgange, eller er det systemet, der skal ændres?
• Har vi alle de felter til rådighed i de forskellige skærmbilleder, for at vi kan gennemføre de forskellige arbejdsgange, vi har identificeret?

Testfokus kan have stor værdi i arbejdet med processer: Det kan identificere uoverensstemmelser mellem standardprocesser og virksomhedens arbejdsgange tidligt i forløbet gennem workshops med testcases baseret på rigtige arbejdsgange til at validere, om systemet fungerer i praksis.

Test af konfigurationen kan afsløre, om systemets standardfunktionalitet understøtter de eksisterende arbejdsgange, eller om der er behov for tilpasninger. Hvis strategien er at tilpasse forretningen til systemet (i stedet for at tilpasse systemet), kan test vise, om ændringerne er realistiske for medarbejderne.

I komplekse organisationer er processer ofte afhængige af flere systemer og aktører. En test med end-to-end scenarier kan afsløre, om f.eks. en ordreproces fungerer på tværs af ERP, lager- og finanssystemer.

Data

Den næste udfordring, vi kan stå overfor, er dataaspektet. Dette afhænger en del af, hvorvidt vi migrerer fra et andet system og skal have data med over, eller om vi starter på en frisk. Hvis organisationen hører til en af de første, så er det værd at stille spørgsmål som:

• Hvor ligger data i dag? Er data spredt over flere systemer, regneark og manuelle processer?
• Er alle nødvendige data tilgængelige, eller findes de slet ikke i struktureret form?
• Hvem ejer data? Hvilke afdelinger eller systemer har autoritet over hvilke data?
• Hvem har ansvaret for data efter implementeringen? Hvem opdaterer og vedligeholder?
• Har vi styr på politikker, så datakvaliteten ikke sander til over tid?
• Hvordan er den nuværende datakvalitet? Er der mange dubletter, er der fejl i data, mangler der nøgledata?
• Er data standardiseret i dag? Er der f.eks. en ensartet brug af landekoder mv.?

Når vi taler om data, kan vi heller ikke komme udenom datamigrering.

• Hvordan flytter vi data fra det gamle til det nye system? Big bang eller bulks?
• Hvordan håndterer vi historiske data? Skal alt migreres med over, eller tager vi først fra et vist tidspunkt? Hvis det sidste er tilfældet, hvad er så konsekvensen af at udelade data?
• Hvad gør vi med fejlbehæftede eller ufuldstændige data?
• Hvordan sikrer vi, at alle relevante data er overført korrekt?

Dette kræver også test – både med fokus på datakvaliteten i forbindelse med migration i form af datavalideringstest, hvor den migrerede data sammenlignes med den originale – men også dataflow test, hvor fokus er på, at data bevæger sig korrekt både internt i systemet og mellem systemerne. Det bringer os videre til næste udfordring.

Integrationer

Og lad os også lige tale om en af de klassiske elefanter i rummet, integrationer. Som testmanager er det virkelig et af mine yndlingsord, ”integrationer”. Mest fordi det er sådan en ”sjov” testopgave, som gang på gang bliver undervurderet. Jeg tror, den bedste kommentar jeg har fået i den kontekst er, ”Vi har testet ud til snitfladen, så vi ved, at det virker”. Famous last words. Selvom det er to standardsystemer, der skal integreres, kan det være en stor udfordring, og det er essentielt, at der er fokus på integrationerne fra dag 1:

• Hvilke systemer skal vores nye ERP-løsning integrere til?
• Hvordan virker integrationen? Bulk loads? Delta overførsel? Realtids push?
• Har vi defineret klare snitflader? Har vi helt styr på feltformaterne i begge ender af integrationerne?
• Har vi fået mappet alle de data, der skal flyde mellem systemerne?
• Har vi klart overblik over, hvem der har ejerskab over data? F.eks. hvis nu vores Dynamics skal integrere til et HR-system, hvilket af systemerne ejer så løndata? Persondata?

Regulatoriske krav og governance

Og så er der selvfølgelig også det med den generelle governance såvel som regulatoriske krav:

• Hvordan styrer vi adgangsstyring og datasikkerhed?
• Hvem må se hvilke data i det nye system?
• Hvem må gennemføre hvilke processer?
• Overholder vi GDPR?
• Hvilke compliance krav skal vi overholde? F.eks. bogføringsloven, regler i forhold til told og skat, NIS2 osv. Og så er der selvfølgelig alle de domænespecifikke compliance-krav som f.eks. i forhold til Finanstilsynet, hvis man er i finanssektoren, eller GAMP5, hvis man er i pharma.

Også denne del kan være temmelig omfattende at få styr på i løbet af projektet, afhængigt af hvilket domæne man arbejder i.

Så der er en række udfordringer, der kræver, at vi, inden vi går i gang med implementeringen, har styr på:

1. overblik over hvilke processer, systemet skal supportere
2. en strategi for datamigrering
3. en plan for at sikre datakvalitet
4. klare ejerskaber og governance
5. test af integrationer, datavalidering og processer.

Terminologi

Vær også opmærksom på, at nogle termer bruges anderledes, end vi er vant til. I SAP bruges termen unit test f.eks. ofte om en funktionel test af en konfigureret løsning eller forretningsproces, typisk udført af konsulenter for at sikre, at f.eks. en indkøbsordre eller en bogføringsfunktion virker som forventet. Det adskiller sig fra ISTQB’s definition, hvor unit test er en lavniveau test af isoleret kode skrevet af udviklere for at verificere korrektheden af individuelle funktioner eller metoder.

Hvordan tester man så et standardsystem?

Når man skal teste standardsystemer (f.eks. ERP, CRM eller HR-systemer), adskiller teststrategien sig fra en traditionel softwareteststrategi, da standardsystemer sjældent udvikles fra bunden men i stedet konfigureres, integreres og migreres. Det betyder, at vores fokus ikke ligger på de mere udviklernære testniveauer som unittest og unitintegrationstest men ofte har fokus på:

• konfigurationstest: Sikrer, at systemet er opsat korrekt i forhold til de krav og behov, vi har identificeret sammen med vores brugere
• integrationstest: Sikrer, at systemet fungerer sammen med det eksisterende IT-landskab
• datamigreringstest: Hvis organisationen har data fra andre systemer, der skal migrereres, skal vi sikre at gamle data overføres korrekt til det nye system
• forretningsproces-test: Det er helt essentielt, at vi gennemfører test af de identificerede forretningsprocesser for at bekræfte, at arbejdsgangene fungerer som forventet
• accepttest (UAT): Brugerne bekræfter, at systemet understøtter deres daglige opgaver. Accepttesten kan være en ”paraply”, der reelt samler op på resultatet af de andre testaktiviteter og evt. supplerer med noget scenariebaseret test med end-to-end fokus for at sikre, at daglige opgaver kan løses.

Principper for test af standardsystemer

Der er nogle vigtige principper for test af standardsystemer, som bør tages med i planlægningen af projektet:

• Risikobaseret test: Fokus på de mest kritiske områder (f.eks. finansielle processer i et ERP). Ofte kan der f.eks. være rigtigt mange forretningsprocesser (jeg har set eksempler på 150-200 forskellige), og her er det vigtigt at kunne prioritere testaktiviteterne, så de vigtigste processer er dem, der får den mest grundige test.
• Tidlig test af konfiguration og integration: Undgå at vente med test til slutningen af projektet. Generelt er princippet om shift-left også vældigt relevant her. Der er ingen grund til at vente med test af f.eks. feltkonfigurationer til UAT eller procesorienteret test; lav tidlig test af de enkelte konfigurationer, og gerne noget der er automatiseres, så det bliver en integreret del af regressionstesten. Det er et nærmeste, vi kommer ”unit test” i klassisk forstand, da vi jo ikke tester kodekomponenter som sådan men konfigurationer.
• Automatisering hvor det giver mening: F.eks. regressionstest af workflows eller API‘er. ERP-systemet skal give værdi i mange år fremover, og mange organisationer vil opleve, at de løbende har behov for forbedringer og tilpasninger. For ikke at forglemme de forholdsvis store releases, der kommer fra leverandøren (SAP eller Microsoft afhængigt af platform) med utallige rettelser. Her har jeg set releasenotes med flere tusinde rettelser til en af de store releases – så her bliver regressionstest essentiel, og den skal ikke være manuel, da organisationen som oftest så vil være tvunget til at trække på forretningen i stort omfang, hver gang der kommer en ny release.
• Brugerinvolvering i accepttest – Forretningsbrugerne skal godkende, at systemet virker som forventet. Hvis vi skal være sikre på, at vi ikke kun har bygget det rigtigt men også har bygget det rigtige – at det virker i brugernes hverdag – så skal brugerne involveres i testen af løsningen. Som minimum i accepttesten.

Tips til test

Rent praktisk er der en række ting, der er værd at have in mente, når vi planlægger testen. Dette for at sikre, at vi får skabt det rigtige setup for testen og får styr på det rette omfang af testen – ikke for meget, ikke for lidt – men lige tilpas.

Så brug denne tjekliste som inspiration, når I skal i gang med at planlægge testen;

1. Fokus på de mest kritiske forretningsprocesser. Brug workshops med forretningen til at identificere de kritiske områder.
2. Brug testteknikker!! Også ved standardsystemer. F.eks. er procescyklustest helt fantastisk til at skabe det mest effektive sæt af test cases med procesfokus.
3. Automatiser gentagne tests så som workflows og tests af API’er.
4. Manuel test er vigtig, hvor brugeroplevelsen er i fokus. Altså test af konfigurationer og accepttest.
5. Hvis eksterne systemer ikke er klar, så brug mocks og testdata til at simulere integrationerne – men husk at teste dem rigtigt også!
6. Hvis mange brugere skal bruge systemet samtidig, så overvej, om det er relevant at gennemføre performance test for specifikke områder.
7. Hvordan får vi et testmiljø, der afspejler produktionen? Er det nødvendigt?
8. Hvordan håndterer vi versioner og opdateringer af standardsystemer?
9. Hvordan får vi testdata? Kan vi bruge anonymiseret produktionsdata, eller skal det genereres?

Test bør ske løbende gennem projektet. En prioriteret rækkefølge kan være som vist nedenfor, dog med den tilføjelse, at regressionstesten bør udvikles så tidligt som muligt, så den kan køres løbende gennem projektet; især hvis man arbejder inkrementelt, hvor områder færdiggøres løbende og samles til en samlet idriftsættelse:

1. Tidlig test af konfigurationer (konfigurationsvalidering)
2. Integrationstest (sikre system-til-system kommunikation)
3. Datamigreringstest (test af dataoverførsel fra gamle systemer)
4. End-to-end test (validering af forretningsprocesser)
5. Brugeraccepttest (UAT) (slutbrugerne godkender systemet)
6. Regressionstest og stabilitetstest før go-live

Men vi skal selvfølgelig kigge på jeres egen kontekst og finde det setup, der passer. Det kan være, at der er behov for en separat test, der fokuserer på compliance i forhold til, hvad I nu end har af regulativer, som I skal overholde for at sikre, at I får den korrekte og tilstrækkelige dokumentation til at bevise compliance. For i den type test handler det jo i lige så høj grad om den rapport/dokumentation, I kan levere efterfølgende som bevis for compliance – så det er nødt til at være i fokus ved planlægningen af testen.

Det kan også være, at der stort set ikke sker tilpasning af processerne, da vi udelukkende bruger standardprocesserne. Så kan der skæres ned på den detaljerede test af processer og fokuseres på en overordnet end-to-end test som en del af brugeraccepttesten.

Konklusion

Selvom standardsystemer kommer som færdige løsninger, betyder det ikke, at de kan implementeres uden grundig test. Konfigurationer, integrationer og datamigreringer introducerer risici, der kan påvirke både systemets funktionalitet og forretningens daglige drift.

En veltilrettelagt teststrategi sikrer, at systemet fungerer i praksis og understøtter forretningens behov. Fokus bør være på tidlig test af konfigurationer, grundig validering af integrationer, kvalitetssikring af data og risikobaseret prioritering af kritiske forretningsprocesser.

Test er ikke en unødvendig omkostning. Det er en investering i en succesfuld implementering.

Kender du det? Systemet er bygget, det kan i grove træk det, det skal kunne, men undervejs glippede det med kvaliteten og der er alt for mange (kritiske) fejl.  

Det kan der være flere årsager til, f.eks.: 

• Tidspres 
• Manglende teststrategi 
• Dårligt kravgrundlag 
• Ufuldstændig dokumentation 
• Dårlig eller ingen sporbarhed, der fører til mangelfuld testdækning 
• En af de agile faldgruber; fokus er udelukkende på den enkelte user story og aldrig på produktet i sin helhed.  

Særligt sidstnævnte kan være resultatet af, at vi laver et komplekst produkt med leverancer fra flere teams, der hver især har ansvar for deres eget delområde. 

Når vi går på kompromis med kvaliteten, begrænser vi potentielt den værdi, produktet egentlig skulle give. Vi risikerer at ende med et produkt, der er besværligt at bruge og i stedet skaber irritation – det kan overskygge det, der i princippet fungerer. 

Dårlig kvalitet er uholdbart – særligt når der fortsat skal udvikles og vedligeholdes på systemet. 

Vedligeholdbarhed 

Når vi går på kompromis med kvaliteten, medfører det typisk teknisk gæld, fordi midlertidige eller forhastede løsninger hober sig op. Det kan have konsekvenser for, hvor let systemet er at vedligeholde efterfølgende, blandt andet fordi det bliver svært at undgå fejl, når der tilføjes ny funktionalitet – særligt hvis der ikke findes tests til at fange de fejl, der måske introduceres.  

Manglende eller dårlig dokumentation kan også påvirke vedligeholdbarheden af systemet og kan være resultatet af, at viden primært ligger hos nøglepersoner. Det gør det vanskeligt for nyansatte at danne sig et overblik over det produkt, de arbejder på, hvilket yderligere gør det vanskeligt at skulle foretage ændringer eller fejlrettelser, hvis de ikke i tilstrækkelig grad forstår omfanget af ændringen.  

Sporbarhed 

En af vores fornemste opgaver som testfaglige er at kunne give information om kvaliteten af et produkt. Jo bedre sporbarhed vi har at arbejde med, jo mere detaljeret og konkret kan den information blive. Derudover giver det os et overblik over vores testdækning og ikke mindst kan vi mere effektivt vurdere, hvad der potentielt kan være påvirket efter en ændring, når vi ved præcist, hvad det er, vi tester og hvordan det hænger sammen med andre funktioner/komponenter. 

Tunnelsyn 

Når vi arbejder i agile teams, risikerer vi at arbejde i siloer, hvor fokus primært er på de enkelte user stories fremfor på den feature, de tilsammen udgør – og produktet som helhed. Vi ender vi med et fragmenteret produkt med inkonsistente brugeroplevelser, hvis hvert team blot fokuserer på, at deres del fungerer, og ikke forholder sig til, hvordan den del skal indgå i systemet eller hvilke afhængigheder, der måtte være på tværs af teams. 

Hvad kan vi gøre ved det? 

Helt grundlæggende skal der forankres et supplerende fokus på produktet. Det kan virke som en forholdsvis uoverskuelig opgave, men hvordan er det nu, man spiser en elefant? 

Produktperspektivet skal indføres på flere forskellige parametre – én bid ad gangen. 

Der bør etableres et testteam på produktniveau. Er dette ikke en mulighed, kan et alternativ være at placere ansvaret for test på produktniveau hos en repræsentant fra hvert team.   

Derudover skal den, der har produktansvaret – enten forretnings- eller IT-mæssigt – have ansvaret for at skabe et overblik over (og ikke mindst dokumentere) alle produktets funktioner samt hvilke processer/arbejdsgange, det understøtter – gerne med support fra test. 

Herefter kan vi: 

• mappe funktionerne til systemets komponenter 
• lave en produktrisikoanalyse (PRA) på funktionsområderne 
• etablere regressionstest på produktet i prioriteret rækkefølge efter risikoklasse. 

Når vi har et dokumenteret overblik over alle funktionsområder, skal de mappes til systemets komponenter – det vil være en opgave for arkitekter/lead developers. 

Denne dokumenterede sammenhæng vil ikke mindst give værdi til (nye) udviklere, der nemmere kan få overblik over produktet og dermed nemmere forstå den kontekst det, de arbejder med, skal indgå i.  

Næste skridt bør være at lave en PRA på funktionsområderne. Det vil give værdi til alle, der er involveret i udviklingen, da det vil synliggøre hvilke dele af produktet, der er kritiske. For testteamet vil det særligt give værdi i forbindelse med etablering af regressionstest på funktionsområderne med dertilhørende processer/arbejdsgange og senere i forbindelse med udvælgelse af, hvilke tests der skal afvikles når en ny feature og/eller release introduceres. 

PRA’en vil derudover give input til, i hvor høj grad de forskellige funktionsområder skal dækkes med test, dermed være input til, hvilke testdesignteknikker der skal benyttes i testanalysen. 

Hvordan skal vi arbejde fremadrettet? 

Når vi har dokumenteret produktets funktioner, dokumenteret sammenhængen mellem dem og komponenter, lavet en PRA på dem og påbegyndt etablering af regressionstest på produktet, skal vi til at kigge fremad.  

Vi skal begynde at: 

• arbejde aktivt med sporbarhed mellem feature, user story, komponent og funktionsområde. 
• arbejde aktivt med sporbarhed fra krav/feature til test til testresultat til bug. 
• bruge testdesignteknikker tidligt. 

Sporbarheden til komponenter og funktionsområder kan helt lavpraktisk implementeres som tags eller felter i opgavestyringssystemet. På den måde vil vi på enhver feature eller user story kunne se, hvilke(t) funktionsområde(r) der måtte blive påvirket af den – og planlægge vores test ud fra det. 

Sporbarheden skal implementeres på alt nyt, så vi ved, hvilket krav eller hvilken feature der bliver påvirket, når vi finder en bug. Så vi ved, om vi har dækket det, vi skal. 

For at vi fremadrettet og på en struktureret måde kan illustrere, hvad en feature eller et krav egentlig indeholder, skal vi begynde at bruge testdesignteknikker, inden vi begynder at udvikle. Indeholder kravet/featuren processer, vil det for eksempel være oplagt at bruge teknikken procescyklustest, når det drejer sig om arbejdsgange, eller tilstandsovergangstest, hvis det omhandler en tilstandsmaskine. Handler det om forretningsregler, vil det være en fordel at lave en beslutningstabel. Tidlig brug af testdesignteknikker vil fange fejl tidligt og bidrage til at tydeliggøre, hvad der skal bygges.  

Teknikkerne giver input til test på flere niveauer – også produktniveau. Vi skal huske at jo højere niveau vi tester på, desto mere bør testen afspejle det reelle brug af systemet. Vi skal ikke genbruge de testcases, der blev udviklet for den enkelte user story – medmindre den har fokus på systemet som helhed.  

Sidst men ikke mindst – drop de dårlige vaner – hellere sent end aldrig 

Stop starting, start finishing – husk at prioritere fejlrettelser undervejs – hvis de konstant parkeres til fordel for nyudvikling, ophober den tekniske gæld sig, og det går ud over den grundlæggende kvalitet af systemet. Vi kan ikke forvente at skabe værdi med nye features hvis de skal eksistere i et system, der grundlæggende er af dårlig kvalitet. 

Skal vi hjælpe?

Vil du høre mere om, hvordan vi kan hjælpe med at bygge kvalitet ind i jeres system fra starten af? Så kontakt chefrådgiver og områdeleder for kompetencer og viden, Gitte Ottosen, på gitte@key2quality.dk eller 4940 8552.