Test af IT systemer er en vigtig disciplin. Dels er det ofte meget dyrere og mere besværligt at opdage og rette fejl, når først de er i produktion, og dels kan pludseligt opståede fejl gøre betydelig skade. Derfor er test vigtig, og der bliver ofte lagt mange ressourcer i test af IT systemer.
Der er mange forskellige typer af test med forskelligt formål og forskellig detaljeringsgrad.
Groft sagt kan de forskellige test typer inddeles i følgende tre kategorier:
- Unit test
- Integrations test
- Funktionel test
Dette kan illustreres som en pyramide (Mike Cohns Test Pyramid) af testtyper:
Unit test er test, der tester de mindst mulige elementer som for eksempel metoder og funktioner i den udviklede kode. Det er oftest udviklerne, der tester deres færdige arbejde for, om der er fejl i den udviklede kode. Af de tre test typer vil det være unit tests, der vil være flest af.
Integration test er test hvor integrationerne til eksterne systemer testes. Mens unit test er test isoleret til enkelte metoder/funktioner, er integrationer oftest udeladt. Integration test er mere tidskrævende end unit tests, og kræver ofte at de eksterne systemet er kørende op imod et test miljø. Der vil være færre integration test end unit test, men de vil være sværere/mere tidskrævende både at udarbejde og teste.
Funktionel test (GUI Test) er den tredje kategori ,og dækker over test af systemets funktionalitet gennem bruger interfacet. Med andre ord testes der funktionalitet, der nås gennem brugergrænsefladen, og ofte strækker sig over flere unit tests og i nogle tilfælde over en hel end-to-end proces. Det er den mest tidskrævende test kategori, både i opbyggelse og udførelse, og kræver ofte gode test scripts og test data. Til gengæld vil de funktionelle test ofte kunne identificere fejl, der ikke er opdaget under unit test, da de funktionelle test tester funktionaliteten i sammenhæng. Funktionel test (GUI Test) er forudsætningen for, at brugerne kan godkende systemet og udgør derfor de funktionelle test cases. Det vil oftest være funktionelle test, der er færrest af, da de er tidskrævende at udarbejde, vedligeholde og udføre.
Test pyramidens relation til hastighed og pris kan illustreres som nedenfor:
I toppen af test pyramiden finder man GUI test, og det er her der ønskes så få test som muligt, for GUI test er langsomme og vanskelige at lave, besværlige at køre og svære at vedligeholde.
Løsningen kan være at udarbejde automatiserede test, som kan udføres uden involvering af mennesker. Til dette har der i årtier været forskellige værktøjer med forskellige fordele og ulemper. Det har traditionelt set været svært at gå til. Ofte har barrieren været at skulle lære et nyt (scripting-)værktøj og begrænsninger i, at kunne lave automatiserede test på alle typer af GUI og på end-to-end processer, der måske spænder over flere GUI typer.
RPA kan være svaret på de udfordringer.
Man kunne benytte RPA til at udvikle automatiserede test i GUI test laget.
Det er dog vigtigt at huske følgende:
- Automatiserede test bør ikke kun være til stede i GUI laget. Ofte har IT leverandøren allerede automatiserede test i Unit Test og Integrationstest laget
- Som tommelfinger regel skal en udviklet automatiseret test udføres mindst 4 gange før investeringen er tjent hjem (før det er fornuftigt at udvikle testen som automatiseret test i forhold til at beholde den som en manuel test)
- De automatiserede RPA test scripts bør også automatisk kunne oprette tickets i et incident management system
Og endelig bør de RPA automatiserede test scripts hovedsageligt baseres på de processer, der er vitale – se inspiration til hvordan processer udvælges her: https://www.processmining.dk/2018/01/robotic-process-automation-succes-sikres-med-process-mining.html
