<img height="1" width="1" src="https://www.facebook.com/tr?id=1272750026111903&amp;ev=PageView &amp;noscript=1">

La RPA teste for deg

Petr Dreiseitl

Petr Dreiseitl | 30. januar 2020

Det er stadig større fokus på effektivisering i vår hverdag, og med dette tar robotene over flere og flere oppgaver. Jeg har jobbet med testautomatisering i over 15 år og har i det siste implementert automatisert verdikjedetest ved bruk av robotisert prosessautomatisering (RPA). Robotisering er relativt nytt. Her får du en liten innføring i hva det er og hvorfor du kan ta det i bruk også i testfaget.

RPA - din digitale medarbeider

Visste du at det faktisk er 100 år siden konseptet og begrepet “Robot” kom til verden? Begrepet ble først brukt i skuespillet R.U.R, (Rossum’s Universall Robots) skrevet i 1920 av Karel Čapek, en forfatter fra Tsjekkia, der jeg også kommer fra. Selve ordet “Robot” sies å ha sitt opphav fra broren hans, Josef, som tok det fra det gamle tsjekkiske ordet “robota”, som kan oversettes til “pliktarbeid” eller “slavearbeid”. Skuespillet R.U.R. var satt opp i Det norske nasjonalteateret i 2017 og manuset, som omhandler mange aktuelle filosofiske spørsmål, anbefales å lese. 

Skuespillet handler om datidens Elon Musk; forretningsmannen Mr. Rossum (som betyr "fornuft", evt. "forstand "på tsjekkisk). I sin gigafabrikk produserer Mr. Rossum tusenvis av roboter med et velment mål om å erstatte alle menneskers oppgaver. Flytter vi dette til moderne tid, kan vi snakke om RPA som din “digitale medarbeider”, hvor målet er å optimalisere manuelle arbeidsoppgaver på digitale arbeidsflater.

Hvorfor ta i bruk RPA?

Det er flere gode grunner til å ta i bruk RPA-produkter fremfor å bestille skreddersydde IT løsninger. RPA er universell og kan brukes for ulike oppgaver i flere IT-løsninger, noe som gjør at det ofte er lav terskel for å komme i gang.
Tenk deg at du driver en forretning som har vokst og har nå mange ansatte, hvor deilig hadde det vært å ha en HR-bot som husker på å sende bursdagsgratulasjoner til hver ansatt? Eller som automatisk godkjenner reiseregninger og andre utlegg og selv tar kontakt med den ansvarlige når den finner noe som ikke stemmer? Eller hva med produksjon av automatiske rapporter til regnskap hver måned? Dette er kun noen eksempler på hvor RPA kan tas i bruk. Kjennetegnene for denne type prosesser er at de gjerne er av stort volum, de er rutinepreget og behovet for menneskelige vurderinger er styrt av klare regler.

RPA kan støtte eller erstatte den menneskelige arbeidsflyten. I dette ligger det store besparelser, både når det gjelder tid og kostnader. Med automatisering av manuelt arbeid, frigjør man ressurser og får kapasitet til andre formål, samtidig som risikoen for feil reduseres (vi har jo alle hørt om “menneskelige feil”). Samme fordeler gjelder selvfølgelig også i testfaget, hvor automatisering har en lengre historie enn det vi kjenner fra RPA og prinsippene er visualisert i den kjente test pyramiden.

RPA som testverktøy

RPA og verktøy for testautomatisering markedsføres og produseres adskilt. Jeg har hittil ikke funnet noen produsenter som både lager RPA og testautomatiseringsverktøy. I mange tilfeller er også de som jobber med RPA og testteamene som driver med testautomatisering ofte lokalisert i forskjellige deler av organisasjonen, uten noen naturlige samarbeidsarenaer.

La meg ta et eksempel fra min egen hverdag hvor jeg brukte RPA som testverktøy. I prosjektet mitt hadde vi behov for å automatisere en regresjonstestpakke som skulle dekke en ende til ende verdikjede gjennom flere fagsystemer. Denne oppgaven kunne ikke løses med et enkelt selenium skript, fordi testen startet i kundeportalen via en nettleser, før den gikk videre til saksbehandligssystemet  (som kun hadde støtte for IE) og til slutt gikk testen inn i kjernesystem via en unix terminal.

I tillegg til å prøve ut noen testautomatiseringsprodukter som kunne passe til dette, tok jeg også kontakt med robotiseringsteamet, som jeg tilfeldigvis ble kjent med på kick-off for prosjektet. Til min overraskelse hadde de roboter som dekket omtrent halvparten av det vi ønsket å ha i vår regresjonstest pakke. I tillegg hadde de et eget testmiljø hvor disse robotene ble utviklet og prøvekjørt. Et slikt stabilt testmiljø hadde vi ønsket oss lenge.

Det tok ikke lang tid å sette meg inn i RPA verktøyet, forstå hvordan robot skriptene ble bygd opp, utvide disse for å dekke hele verdikjeden og regresjonstest pakken. Med enkle grep var det mulig å integrere disse kjøringene i Jenkins slik at de var enkle å starte og ha som en del av Continuous Integration oppsettet. Robotiseringsteamet tok til gjengjeld deler av scripter fra regresjonstesten min og brukte de som nye steg i prosessautomatiseringen.

Det er flere grunner for å ta i bruk RPA i testingen:

  • Dersom organisasjonen planlegger å implementere GUI automatisering og det allerede finnes RPA på huset
  • Deling av kompetanse, RPA og test utfyller hverandre
  • Besparelser, kun 1 UI automatiseringsprodukt (i testmiljøer kjører RPA ofte gratis, sjekk lisens)

RPA vs. testverktøy

Det finnes noen forskjeller mellom RPA og testverktøy, men basisfunksjonalitet og betjening av GUI er veldig like. Et forsøk på å sammenligne egenskaper av begge typer verktøy er skissert i tabellen under. Men, etter at jeg gikk gjennom disse punktene med noen av mine kolleger var konklusjonen vår at vi egentlig ikke kan peke på vesentlige forskjeller, spesielt med tanke på at det finnes forskjeller også innenfor testverktøy fra forskjellige leverandører.

Så, er RPA og testverktøy egentlig så ulike?

RPA vs GUI

Jeg mener at testautomatisering og RPA fint kan fungere i symbiose, dette kan for eksempel gjøres ved å:
  • Bruke RPA som testdatakilde for autotest
  • Gjøre autotest som testdatakilde og trigger for RPA robot i testmiljø
  • Både RPA og testautomatisering stiller samme krav til GUI testbarhet (f.eks. behov for automationID), RPA har større gjennomslag for å få det på plass hvis det mangler
  • Åpner for kontinuerlig "Testing" i produksjon – ved å overvåke status på RPA kjøringer med kjente funksjonelle steg vet testteamet at funksjonalitet virker og kan eventuelt få tidlig varsel når noe stopper.

Hvordan komme i gang?

Hvis din organisasjon bærer preg av flere rutinemessige tilbakevendende oppgaver i testingen, kan RPA være lønnsomt å undersøke.

Benytt følgende steg for å komme i gang med RPA-testing:

  1. Finn ut mer om RPA prosjekter (automatisering/robotisering) i din organisasjon, ta en prat med folk som jobber med dette og identifiser mulige gevinster for begge parter.
  2. Hvor kjører robotene, i hvilket testmiljø? Har du et testmiljø som du kan bruke med roboten i eller får du lov å bruke robotens eget testmiljø?
  3. Hvordan rapporterer RPA teamet feil? Kanskje de finner feil i produktet ditt under utvikling av roboten, hvordan får du vite om disse?
  4. Kan RPA teamet samkjøres med testrutinene i ditt team? Roboten kan til gjengjeld tilpasse seg raskere til kommende endringer som dere tester før disse settes i produksjon.
  5. Sett opp robot kjøringene lokalt hos deg og tilpass til dine testbehov. Prøv deg fram!

 

Tilbake til historien innledningsvis om forretningsmannen Mr. Rossum og hans roboter. I skuespillet skaper robotenes inntreden i arbeidslivet et opprør hos folk som frykter for sine jobber og fremtiden. Skuespillet ender med det motsatte; robotens opprør for sine rettigheter. Den første frykten kjenner vi også fra vår tid. Det andre opprøret har vi heldigvis ikke opplevd - ennå. Uansett, med enkle grep kan du slutte å frykte begge disse.

Bli venn med roboten din!

 

 

Trenger du assistanse for å begynne kan du ta kontakt med en av våre rådgivere.

Ta kontakt med en av  våre rådgivere her

 

Del på sosiale medier: