Hvorfor skal jeg teste – og teste igen?
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.
Hvorfor skal jeg teste igen - og teste igen?.
Af: Mikkel Bertelsen, Lead Solution Architect, Columbus
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. 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 test.
Tager 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.
