Hvorfor er tests blevet en essentiel del af Dynamics 365?
Februar 2021 // 10 MIN
Med en opgradering til Dynamics 365 skal virksomheder vænne sig til nye testvaner for at sikre, at deres forretningssystem altid er velkørende. Vores Development Manager kommer med gode råd til, hvordan I kan indarbejde gode testrutiner.
Med den nyeste generation af Microsofts ERP-system, Dynamics 365, kommer der 8 årlige opdateringer til systemet fra Microsoft, som en del af One-Version tilgangen.
De kontinuerlige opdateringer, også kaldet Continuous Delivery, betyder at tilpasninger og modifikationer kan rulles ud med højere frekvens end tidligere. Dermed stiger behovet for at sikre, at integrationer og tilpasninger virker som hidtil. Hvis kritisk funktionalitet fejler, kan det betyde tabt tid, spildte ressourcer, og i sidste ende økonomiske konsekvenser. Her bliver testing essentielt, og en kritisk del af det, at have et ERP-system.
Det kan lyde som en stor mundfuld. Det er en ny måde at arbejde på end vi er vant til. I samarbejde med vores Development Manager og Partner, Michael Cronqvist, vil vi skabe et overblik over, hvad testing er i relation til Dynamics 365.
Hvad er One-Version?
Opgraderingen til Dynamics 365 bliver den sidste store opdatering. Mindre løbende opdateringer holder systemet opdateret med nyeste funktionalitet. Dermed navnet "One-Version", også kaldet en evighedsversion.
Hvorfor er tests af dit system vigtigt?
Ifølge Michael Cronqvist, er kontinuerlige tests af din forretningsløsning vigtigt for at opretholde en høj driftssikkerhed.
"Fejl sker i større eller mindre omfang ret ofte indenfor softwareudvikling, og det samme gør sig gældende med ERP-systemer. Det er ikke grundet dårlig udvikling eller dårlige systemer. Den store kompleksitet og de mange integrationer i de stærke, fleksible og omfattende systemer har gjort det, og gør det stadig, udfordrende at gennemskue fejl og helt forhindre dem i at ske. Det kan grundig testing i høj grad forebygge."
Vi kan se vores ERP-system som en bil. Bilen bliver brugt dagligt til og fra arbejde, den skal kunne transportere børnene i skole og klare en tur sydpå. Vi har brug for, at den er pålidelig, driftssikker og ikke konstant skal til mekanikeren, for det er dyrt og desuden står vi uden en bil i mellemtiden.
Bilen er vores ERP-system, og de vitale dele på bilen, såsom hjul, motor og bremser er vores kritiske forretningsprocesser. Vi kan ikke komme på arbejde hvis forhjulene falder af, men vi kan godt komme videre med dagen, hvis signalhornet sidder fast, omend det vil gøre dagen en smule mere larmende og besværlig.
Vi ønsker vores forretning skal køre gnidningsfrit, ligesom vores bil. Vi ønsker at kunderne får de korrekte varer og services til den aftalte tid, og samtidig vil vi gerne sikre os, at vores medarbejderes dag forløber ubesværet.
Kritiske processer må ikke fejle
Derfor er det yderst vigtigt at teste om hjulene sidder fast og bremserne virker, altså teste vores kritiske forretningsprocesser. De fleste finder det kritisk, at de kan fakturere, og at produktionen ikke stopper i flere dage grundet en fejl i systemet. Det kan betyde spildte ressourcer, tid og penge.
Er det vigtigt at teste om radioen virker? Ikke alle forretningsprocesser er kritiske, men det betyder ikke, at de ikke er vigtige. Mindre systemfejl kan have en negativ effekt på den enkelte medarbejder, der skal slås med et system der giver fejlmeddelelser, og gør det svært at gennemføre de daglige arbejdsopgaver.
Det er essentielt, at I som virksomhed, tager stilling til, hvilke af jeres forretningsprocesser der absolut ikke må fejle. Her er det en god ide at teste grundigt, og indarbejde faste testrutiner.
Begrebsafklaring - hvad skal du vide?
Ifølge Michael Cronqvist, opstår der ofte en del forvirring omkring test-begreberne.
“Vi ser ofte at det er svært at forstå hvornår testing er relevant, og hvilken type af test der giver mening hvornår. Ofte er det fordi folk har svært ved at forstå hvad de forskellige termer dækker over. Og det er med rette, for det kan hurtigt blive forvirrende.”
Software testing er et vidt dækkende begreb, vi dækker her, hvad vi hos Bredana Axcite, mener er essentielt i forbindelse med testing af Dynamics 365.
Regression- vs. non-regression test
Non-regression-test
Her tester vi den nye del af systemet. Ofte tilføjes ny funktionalitet til systemet, men før det bliver en del af systemet, skal man sikre sig at selve funktionaliteten isoleret set virker og opfylder sit formål. Vi kan se hele systemet som en bil. Vi har brug for at få nye bremser på bilen. Inden vi monterer dem, må vi sikre os at bremserne overhovedet virker, ellers giver det ikke mening at montere dem på bilen. Hvis funktionalitet virker, inkluderer vi den i systemet.
Regression-tests
Vi tester her, at det der virkede før, stadig virker. Regressionstesten tester, at koden, programmerne og de flows virksomheden har i systemet, stadig virker som ønsket, og at den nye kode ikke har påvirket resten af systemet. Når vi monterer nye bremser på bilen, tester vi, at de nye bremser ikke har ødelagt noget andet på bilen. Det kan være, at de nye bremser ikke er kompatible med bilens hjulstørrelse, og dermed virker bremserne ikke mere, og bilen er praktisk talt ubrugelig.
Når der tilføjes ny kode, testes funktionaliteten af den nye koden seperat, og som en del af den eksisterende kode.
Hvis bremserne virker som de skal, og de ikke har ødelagt eller påvirket andet på bilen, så bliver de nye bremser en fast bestanddel af bilen, som vi ved virker. Det samme sker med den nye kode og funktionalitet i systemet. Dermed skal der, næste gang der tilføjes funktionalitet, testes på den nye kodebase.
Automatiserede vs. manuelle tests
Når man tester, kan det gøres enten automatisk eller manuelt. Som udgangspunkt kan alle typer af tests udføres automatisk, der er dog undtagelser, hvor manuelle tests giver mere mening.
Automatiserede tests
Ofte kan det at teste manuelt blive en triviel og ressourcekrævende opgave, og det er derfor også nemt at glemme og underprioritere. Ved at automatisere testene, sikrer man sig at det bliver gjort, og tilmed også bliver gjort på præcis samme måde hver gang. Desuden giver de automatiserede tests ofte en større tryghed ved opdateringer. De automatiserede tests sikrer at systemet stadig virker, og der ikke opstår skjulte fejl af større eller mindre betydning. Med tiden opbygges et stort arkiv af tests, og da disse kører automatisk, bliver mængden og dermed kvaliteten af testene konstant bedre. Desuden reduceres implementeringstiden kraftigt, da der ikke først skal findes tid og ressourcer til at teste, inden opdatering rulles ud.
- Ideel til tests der gentages flere gange
- Kraftig reduktion af implementeringstid
- Færre ressourcer allokeres
- Det bliver altid gjort
- Kan teste flere flows, og dermed finde flere defekter på kortere tid
- Tests udføres på samme måde og i samme omfang hvér gang
Manuelle tests
Ved manuelle tests sidder en person og tester, at hvert eneste skridt i processen virker som den skal. Selvsagt er dette en ressourcekrævende, langsommelig og fordyrende proces. I visse tilfælde er manuelle tests dog de mest brugbare. Skal man eksempelvis teste visuelle ændringer, fysiske outputs som print, snitflade/integrationer mod andre systemer og downloads af filer, er det besværligt at teste automatisk, uden at en person rent faktisk inspicerer outputtet.
- Brugbar hvis det der testes kun skal testes få gange
- Ideel til testing af brugeroplevelse og brugervenlighed
- Når der skal testes for visuelle ændringer
- Når der skal testet for fysisk output
- Ved test af integrationer mellem flere systemer
Både regressions-tests og non-regressions-tests kan udføres manuelt eller automatiseres. Valget afhænger i høj grad af formålet og hyppigheden af testen.
Forskellige niveauer af tests
Der findes flere forskellige niveauer af tests. Test-pyramiden fungerer som en guideline indenfor udvikling af test-strategier. Vi gennemgår her de forskellige typer af tests.
Unit testing
Her tester vi hver enkelt del på bilen imens vi udvikler den. Vi tester om hvert eneste tandhjul i gearene virker og har de rette dimensioner. Softwareudvikleren laver sideløbende med kodningsprocessen af en funktionalitet også en test, der tester at hvert enkelt del af koden giver det korrekte output. Det er mere tidskrævende, men til gengæld kan denne test, finde selv de mindste fejl inden de implementeres i systemet.
Component testing
I component tests, tester vi de enkelte tandhjul samlet i ét gear. Vi tester kun gearerne for sig, og de er endnu ikke sat på bilen. Ved component testing tester man, at de enkelte dele virker i sammenspil med hinanden. Man kan godt have 5 funktioner i sit system der isoleret set virker, men at de fejler når de bliver sat sammen.
Integration tests
I integration test, tester vi om geaerne virker sammen med gearstangen oppe i bilen, og at de udfører deres formål. Der testes her for, om flere komponenter virker i sammenspil med hinanden. Det kan være en test der tester integrationerne i mellem salg og finans.
End to End test
E2E test også kaldet Business Cycle Tests og Usability Test, tester hele systemet og større flows, ofte kritiske forretningsprocesser. Med bil-analogien betyder det, at vi tester om hele bilen virker. Ved at sætte os ind i bilen og træde på speederen, skifte gear og bremse, finder vi ud af om bilen virker og gør som den skal.
Hvem tester hvad?
Unit tests, integration tests og component tests er udviklerens ansvar. Ofte udvikles testene sideløbende med at selve funktionaliteten udvikles, og testene kræver at der kodes. AT E2E tests udføres er kundens eget ansvar. Her kan vi hjælpe på flere måder:
- Opbygning af tests
- Undervisning af medarbejdere
- Assisestere undervejs
- Udføre tests
Vores anbefalinger
I sidste ende er det altid jeres virksomheds egen beslutning at vurdere, hvilke processer der essentielle for netop jeres virksomhed, og hvordan ønsker I at teste jeres løsning.
Hos Bredana Axcites har vi opdelt vores anbefalinger til tests af jeres Dynamics 365-løsning i:
- Test af kritiske forretningsprocesser med tilpasninger
- Test af alle kritiske processer
- Test af alle forretningsprocesser
"Vi anbefaler vores kunder at teste alle deres kritiske forretningsprocesser (2). Det er både de kritiske processer, som man selv har fået skræddersyet, samt de funktioner der kommer standard fra Microsoft. Dermed sikrer man sig, at de opdateringer man selv får lavet, og de opdateringer Microsoft ruller ud ikke medfører problemer. Microsoft tester altid deres egne opdateringer grundigt, men da de bliver en del af kundens system med tilpasninger, bør man sikre sig, at alt virker som det skal", fortæller Michael Cronqvist og fortsætter:
"Som minimum bør man teste de kritiske forretningsprocesser, hvor der er lavet tilpasninger (1). Vælger man nummer 3, så får man Rolls Roycen indenfor testing. Her sikrer man sig, at man ikke har støjende dage/uger, og at mindre kritiske processer virker. Dermed undgår man frustererede medarbejdere og mindre fejl, der potentielt ender hos slutkunden. I sidste ende er det altid en afvejning fra virksomhedens side - hvilke processer er essentielle for netop deres virksomhed?"
Hver gang en test udvikles, forbliver denne test og bliver ved med at bidrage til den konstant voksende pulje af tests. Dermed vil kvalitetsikringen stige med tiden, og de investeringer man gør sig fra start i at udvikle tests, er aldrig spildt.
Lyder det skræmmende?
Vi forstår godt at det kan være en stor mundfuld og mange tests, men ifølge Michael Cronqvist, betyder det ikke nødvendigvis en øget arbejdsmængde sammenlignet med tidligere.
“De hyppige løbende opdateringer giver et øget behov for at teste. En del af den store mængde af tid og ressourcer virksomhederne før brugte på at implementere et nyt system hvert 5.-10. år, bruges nu løbende på at teste, at opdateringer og ny funktionalitet er kompatibelt med det eksisterende system. Man bruger altså tiden på konstant at være opdateret, holde sig konkurrencedygtig, og drage fordel af den nyeste teknologi”.
Desuden påpeger han, at han ofte møder bekymringer hos kunderne.
“At skulle teste på denne her måde, er en ny måde at arbejde på. Ofte bliver vi mødt af bekymringer omkring kompleksiteten og besværligheden af at teste. At skulle teste på denne her måde, betragtes endnu ikke som en fast bestanddel af det at have et Microsoft ERP-system. Det handler i bund og grund om, at man fra start indarbejder sig nogle gode testrutiner, og det hjælper vi gerne med”, fortæller Michael Cronqvist og uddyber.
"Ser man det som én samlet investering i et ERP-system, så er det en god investering på den lange bane, at teste fra start. Det er en investering i fremtiden, som med sikkerhed betaler sig hjem. Med tiden bliver det et spørgsmål om mindre vedligehold af de tests man har udviklet. Man undgår fejl der kan vokse sig større over tid, og det betyder ny udvikling, nedetid, fejlsøgning og utilfredse kunder og medarbejdere. Noget vi alle gerne vil undgå. Vi ønsker ikke at hjulene falder af vores bil. Derfor sikrer vi os, at den er testet ordentligt inden vi sætter os i den, og ikke først efter de er faldt af første gang."
Vi hjælper dig med at teste
Hos Bredana Axcite forstår vi, at det er udfordrende at komme igang med at indarbejde gode testrutiner. Vi hjælper vores kunder med at udvikle testscenarier og opsætte testene, eller varetage de løbende tests.
Fakta
SoftwareReviews er en del af Info-Tech Research Group, som er en amerikansk uafhængig analyse- og konsulentvirksomhed.
Rapporten Enterprise Ressource Planning Data Quadrant er udformet med det formål at hjælpe virksomheder i beslutningsprocessen, når de skal vælge ERP-system, ved at tilbyde et uafhængigt dataindblik fra rigtige systembrugere.
Resultaterne i rapporten er baseret udelukkende på de adspurgtes egen opfattelse af de anvendte systemer.
I alt er 1107 brugere blevet spurgt fordelt på 22 forskellige ERP-systemer.
Vi er specialister i Microsoft Dynamics 365
Vi er særligt stolte af vores certificering som Microsoft-partner med speciale i Microsoft Dynamics 365 Supply Chain Management og Finance. Det betyder nemlig, at du er garanteret markedsledende ERP-produkter af høj kvalitet og sikkerhed.
Har du spørgsmål?
Du er velkommen til at kontakte os her, og vi vender retur hurtigst muligt.