<img src="https://secure.leadforensics.com/133892.png" alt="" style="display:none;">

Ikke alt var bedre i gamle dage, og det gælder i særdeleshed software. Nutidens løsninger holder generelt en langt højere kvalitet end deres forgængere, og en kombination af styrkede metodikker og bedre udviklingsværktøjer spiller afgjort en rolle.

Mindst lige så afgørende er det dog, at vi er blevet bedre til at teste systemer og finder fejl i rette tid. Hvorfor testing også prioriteres særdeles højt hos samtlige globale udviklingshuse.

Derimod har man undertiden tendens til at overse værdien af systematisk, automatiseret testing i udvikling og implementering af forretningsløsninger på virksomhedsniveau. Det er synd, for testing er ikke blot et nødvendigt onde, men bør betragtes som en investering, der giver afkast på flere niveauer.

Hvorfor skal jeg teste?

Testing handler bl.a. om at sikre en løsnings kvalitet, stabilitet, kapacitet og integrationer til andre systemer.

Testing handler bl.a. om at sikre en løsnings kvalitet, stabilitet, kapacitet og integrationer til andre systemer. Om at finde fejl på forhånd og kontrollere, at alt fungerer, som det skal og bliver ved med at gøre det – også når et stort antal brugere anvender løsningen på samme tid. Det er både relevant at vide, før en ny løsning går live og når der foretages ændringer på en løsning, der allerede er i produktion.

For det kan let blive kritisk, hvis et ERP-system f.eks. begynder at spytte forkerte fragtdokumenter ud, gør det umuligt at udstede (eller betale) fakturaer eller at bestille nye råvarer. I værste fald kan ringe softwarekvalitet give røde tal på bundlinjen. Det er en risiko, testing kan minimere i meget betydeligt omfang.

Samtidig kan en moderne testingstrategi udmunde i en opdateret dokumentation af din løsnings specifikke funktionalitet, hvilket i visse brancher endda kan være et decideret krav fra myndigheder og/eller revision. Du har endda mulighed for at få dokumentation direkte på hånden, der detaljeret beskriver dine processer og kan indgå direkte i onboarding og undervisning af nye medarbejdere.

Hvornår skal jeg teste?

Ofte ser jeg, at man først for alvor begynder at teste sidst i et projekt, når den samlede løsning er stort set færdig. Det er af flere årsager ikke særlig hensigtsmæssigt. Først og fremmest er det en meget tung arbejdsbyrde at løfte på én gang – ja, nærmest et helt projekt i sig selv. Samtidig risikerer man at overbelaste projektgruppen med feedback i den allermest kritiske fase af projektet – lige før man går live.

Derimod bør man komme i gang med at teste så tidligt som muligt i projektforløbet. Indledningsvis handler det om at definere en teststrategi, dernæst om at teste de enkelte "units" – eller løsningselementer – efterhånden som de bliver klar.

Lad os sige, at man bygger en løsning, der håndterer det samlede flow lige fra en kunde indgiver en ordre, til den leveres, faktureres og hele vejen til der skal indkræves betaling. I det tilfælde kan man sagtens teste ordreelementet, fakturamodulet eller et hvilket som helst andet delelement for sig – uanset om resten af elementerne er på plads eller ej – og det bør man gøre.

Dermed spiser man ikke blot elefanten én bid af gangen, man får også lettere ved at håndtere projektet og re-allokere ressourcer effektivt undervejs. Samtidig er man allerede nu i gang med at bygge det bibliotek af testcases, som kan anvendes som skabelon for fremtidige tests, og som bliver del af de afsluttende end-to-end tests af hele den nye løsning.

Hvordan skal jeg teste?

Tidligere var testing manuelt tungt, hvilket har været med til at give disciplinen et ry som besværlig, langsommelig og kostbar. Ryet var i sin tid faktisk fortjent. Jeg arbejdede f.eks. selv engang på et projekt i en pharmavirksomhed, hvor vi skulle gennem 17 testcases, der krævede tre dages fuldtidsarbejde med manuel scripting og testing, hver eneste gang der blev ændret blot det mindste i et bestemt interface. Det var hårdt, monotont og omkostningsfuldt – men helt nødvendigt.

Men i dag har navnlig Automated Testing gjort arbejdet langt nemmere. Automated testing er hvor man foretager en bestemt handling i et stykke software (f.eks. fakturering eller indkøb af råvarer), mens testingsoftwaren automatisk "optager" alle handlingens sekvenser og automatisk bygger et testscript i baggrunden, der senere kan "afspilles" og eventuelt justeres. Automated testing gør det blandt andet meget nemmere at udføre regressions testing hvor man tester potentielle effekter af de ændringer, der er foretaget i et stykke kode. Det sparer usandsynligt meget tid, gør testingarbejdet nemmere og øger kvaliteten af indsatsen, fordi man minimerer risikoen for manuelle fejl.

Læs mere om automatiseret testTager vi eksemplet ovenfor, ville det i dag stadig tage nogle dage at forberede og gennemføre den allerførste testingindsats af det pågældende stykke software, men alle følgende tests ville herefter kunne gennemløbes på 2-3 timer. Her er med andre ord tale om en effektivitetsgevinst på mindst faktor 10.

Ligeledes kan man via Automated testing lettere stressteste ved at simulere, at et stort antal brugere f.eks. tilgår forskellige dele af en løsning eller samme delelement af løsningen på én gang. Det er med til at sikre, at virksomhedens løsning både fungerer hensigtsmæssigt i hverdagen og når der er spidsbelastning i forbindelse med eksempelvis højtider eller ved aflæggelse af årsregnskab.

Hvornår er det relevant at teste?

Hos Columbus anbefaler vi altid at udarbejde og følge en testingstrategi som del af et forløb, der omfatter udvikling/konfiguration, implementering og drift af en løsning – eller i forbindelse med implementering af opdateringer. Naturligvis dels for at kvalitetssikre og øge sandsynligheden for, at alle forretningskritiske processer fungerer efter hensigten. Men også fordi det i bund og grund er en god forretning for kunden, der som nævnt også kan være med til at styrke dokumentation, uddannelse og compliance.

Så hvis man skal give et kort svar på, hvornår det er relevant at teste, så må svaret være: Igen og igen! Og heldigvis er det blevet nemmere end nogensinde.Læs mere om automatiseret test

Kommenter indlæg

Recommended posts

I 2018 satte Black Friday-salget ny rekord – i øvrigt ligesom året forinden – og det kunne meget vel også ske i denne omgang. Under alle omstændigheder bliver 29. november årets største dag for dansk detail, selv om Cyber Monday også er ved at vinde indpas for virksomheder, der satser stort på e-commerce.
Tillid er godt, men test er bedre… Og denne gamle sandhed er ikke blevet mindre aktuel med Microsofts ”Evergreen”-initiativ, hvor der nu udkommer opdateringer otte gange årligt til Dynamics 365 Finance & Operations. I det store billede er Evergreen en positiv nyskabelse, der sikrer virksomheder konstant adgang til ny og opdateret funktionalitet, mindsker behovet for specialudviklinger eller for, at virksomheden kommer langt bagud i en årelang opdateringscyklus.
Midt i et stort IT-projekt er det let at glemme, at det hele slutter en dag, at løsningen tages i drift og at det bliver hverdag igen. Det er endnu sværere at forholde sig til i begyndelsen af projektforløbet, når opgaverne tårner sig op og slutmålet knap kan skelnes ude i horisonten.
Med en baggrund inden for Lean & Six Sigma og som M.Sc. i Production Management har jeg altid vidst, at evnen til at kommunikere klart og tydeligt, ville være med til at afgøre graden af succes, men alligevel er jeg overrasket over at opleve de sande fordele ved et fælles organisationssprog, da det udgør hjørnestenen for succes.
Proaktiv overvågning af virksomhedens integrationer kan udgøre forskellen mellem et kostbart produktionsstop og business as usual.
right-arrow share search phone phone-filled menu filter envelope envelope-filled close checkmark caret-down arrow-up arrow-right arrow-left arrow-down