RPA Testing Using Symbolic Execution

Ciprian Paduraru, Marina Cernat and Adelina-Nicoleta Staicu

Department of Computer Science, University of Bucharest, Romania

Keywords:

RPA, Testing, Symbolic Execution, Test Generation.

Abstract:

The goal of Robotic Process Automation (RPA) technology is to identify patterns in repetitive processes that

can be automated in enterprise workﬂows, and to create intelligent agents that can repeat those processes

contextually and without human effort. However, as the technology has evolved considerably in terms of

model complexity, data inputs, and output dimensionality, preserving the quality of the building blocks of the

operations is a difﬁcult task. We identiﬁed that there is a gap in testing methods and tools capable of efﬁciently

testing RPA workﬂows. In this paper, we therefore propose to address this gap by using symbolic execution

as a starting point. We focus on both the methodology and algorithms required to transfer existing research

in symbolic execution to the RPA domain, propose a tool that can be used by researchers and industry, and

present our current evaluation results for various use cases along with best practices.

1 INTRODUCTION

Robotic Process Automation (RPA) (Aguirre and Ro-

driguez, 2017), (Leno et al., 2021) aims to reduce the

workload of repetitive tasks performed by employ-

ees in organizations. Rather than intervening in the

information system itself, as is the case with tradi-

tional workﬂow optimization, RPA generally works

by identifying patterns in repetitive processes that can

be automated. The identiﬁed patterns are written in

a speciﬁc language that we refer to as RPA workﬂow

so that a software robot can perform those operations.

An RPA workﬂow consists of the identiﬁed activities

and the relationships between them. Thus, the under-

lying abstract format of these activities takes the form

of a graph in which each activity is a node (or more

precisely a hyper-node with multiple nodes). Over-

all, the purpose of RPA workﬂows is to enable both

technical and non-technical people to create and man-

age content. The operations performed as part of the

activities generally relate to interactions with user in-

terfaces (Cernat et al., 2020a), cross-enterprise func-

tionality such as database or server management, or

custom APIs that connect to client infrastructure. An

RPA robot is an entity that executes workﬂows and re-

places repetitive human activities. It executes a work-

ﬂow by processing the activities and operations spec-

iﬁed in the nodes.

Recently, RPA is considered by many companies

as one of the most efﬁcient ways to reduce costs and

achieve a high return on investment (ROI) (Ray and

et al., 2022), (Economy, 2020). RPA is being used

in industries such as manufacturing, technology and

healthcare, across a range of business sizes, from

small businesses to large enterprises. As RPA tech-

nology takes hold and workﬂows created in enter-

prises automate and connect many endpoints, it is im-

portant to test these automation processes from start

to ﬁnish. In general, RPA testing means deﬁning in-

puts and expected outcomes and verifying that the au-

tomation process works as expected. An automated

testing tool for RPA can detect common problems

such as logic errors, security vulnerabilities, or other

low-level coding issues.

The goal of our work is to provide a framework

for testing RPA workﬂows and to identify best prac-

tices based on the evaluation of the results. The work

was done in collaboration with our industry partner

UiPath

, which is currently the world-leading RPA

technology company (according to (Ray and et al.,

2022)).

Based on our literature research, our framework

brings the following innovations to the ﬁeld:

• To the best of our knowledge, this is the ﬁrst aca-

demic work describing a tool capable of testing an

RPA workﬂow from start to ﬁnish.

• We adapt existing modern symbolic execution

methods to the RPA case.

https://uipath.com

Paduraru, C., Cernat, M. and Staicu, A.

RPA Testing Using Symbolic Execution.

DOI: 10.5220/0012061000003538

In Proceedings of the 18th International Conference on Software Technologies (ICSOFT 2023), pages 269-275

ISBN: 978-989-758-665-1; ISSN: 2184-2833

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

269

• We identify best practices for testing RPA work-

ﬂows from our collaboration with industry part-

ners by applying our methods to real-world appli-

cations.

Note that more technical details on our tool are

provided in our complementary paper (Paduraru et al.,

2023), which is based on a common technical foun-

dation but provides a concolic approach, not the sym-

bolic approach presented in here.

The rest of the paper is organized as follows. Sec-

tion 2 discusses previous work in the ﬁeld of RPA

and software testing. Furthermore, Section 3 provides

an overview of the testing pipeline. Section 4 dis-

cusses how symbolic execution methods are used by

our framework in the RPA testing environment. The

evaluation of the results are presented in section 5.

The last section is dedicated to conclusions.

2 RELATED WORK

RPA and Automated Testing. By reviewing the lit-

erature on RPA and testing, we concluded that there is

a lack (from the authors understanding, because there

is no prior work at all) in white-box testing for the

RPA workﬂows. In (Cernat et al., 2020b), the authors

describe the state of the practice for testing software

robots and propose some ideas for test automation us-

ing model-based testing, without providing any fur-

ther evaluation or implementation proposal.

The strategy employed by (Chac

on Montero et al.,

2019) is to set up a testing environment by watching

how people interact with application UI interfaces

and documenting their actions with logs and pictures.

Firstly, because the method does not evaluate an

RPA workﬂow, it is more appropriate to classify it

as ”black-box testing”. It has limitations compared

to our proposed methods in two ways, despite being

interesting for our efforts: (a) it is more difﬁcult to

introduce user knowledge into the test ﬁeld, and (b)

using only computer vision approaches to record

operations can signiﬁcantly limit the coverage of

the test state space compared to white-box testing

of a given graph. Secondly, RPA was utilized in

the publications (Holmberg and Dobslaw, 2022) and

(Cernat et al., 2020b) to test graphical user interfaces.

Additionally, RPA has been used in (Yatskiv et al.,

2019) for automation and regression testing for

additional common information system components,

like web, desktop, or mobile applications, or even

API functionality testing in large-scale software.

Testing Methods. Our research focuses on white-

box testing (Godefroid et al., 2012a) using symbolic

execution approaches. We utilize current state-of-

the-art techniques, but our contribution is to inves-

tigate and assess the delta of modiﬁcations for test-

ing RPA workﬂows. For testing at the binary, source

code, or LLVM level, we have modiﬁed our proce-

dures to ﬁt existing solutions. In terms of techniques

and algorithms for symbolic execution, our work was

inﬂuenced by two popular open source frameworks:

KLEE (Bucur et al., 2011) and S2E (Chipounov et al.,

2012). We drew inspiration from tools like CRETE

(Chen et al., 2018) for testing at the LLVM represen-

tation level, which can be somewhat analogous to our

notion of annotation.

3 TESTING PIPELINE

OVERVIEW

This section gives an overview of the involved com-

ponents, pipelines, and user sides of the proposed au-

tomated RPA testing framework.

The process in Fig. 1 presents the components of

the testing tool and their relations during the execu-

tion. The implemented components are:

• XAML parser, which is a transformer from the

robot which is provided in its native XAML for-

mat to an annotated graph format, which is suit-

able for the testing tool;

• symbolic test generator using also fuzzing;

• integrating script (in Python), which connects the

above components.

The integrating script gets as input a ﬁle userIn-

put.json containing the conﬁguration for the XAML

parser and the test generator. It must be provided by

the user at the beginning of the testing process, as a

prerequisite. The purpose of the integrating script, as

its name states, is to connect the two components, the

XAML parser and the test generator. The the XAML

parser is used to parse XAML ﬁles, the result being

serialized in a .json ﬁle, which preserves only the in-

formation necessary to run the symbolic test genera-

tor. The execution of both components is performed

with the help of the integrating script having as result

the following ﬁles:

• outputXamlParser.json, representing the output of

the XAML parser;

• generatedTests.csv, representing the output of the

symbolic test generator;

• executionLogs.csv, with the purpose of giving de-

tails about the execution of the symbolic test gen-

erator such as the solver strategy used and the ex-

ecution time;

ICSOFT 2023 - 18th International Conference on Software Technologies

270

Figure 1: The overview of the testing process.

• CFGraph.png, representing the control ﬂow

graph of the robot.

In addition to these components, we have created

an extra reusable RPA robot designed to execute the

integrating script and return an array of test ﬁles gen-

erated by the symbolic test generator. The resulted

test suite can be run within the test execution frame-

work provided by the RPA tool. The coverage metrics

can be extracted from there.

4 SYMBOLIC EXECUTION

STRATEGY FOR TESTING RPA

WORKFLOWS

In this section, we describe our proposal for applying

the symbolic execution methodology to the RPA do-

main, detailing both the methods and the implemen-

tation level. Our contribution in this sense is to incor-

porate them into our framework design and provide

our considerations and requirements needed for test-

ing RPA workﬂows. An important advantage of test-

ing RPA workﬂows is that the entire model, consisting

of activities and connections between them, is known.

With the help of the human in the loop, who can addi-

tionally provide what we identiﬁed earlier in the text

as annotations, the test process turns out to be com-

putationally suitable in most cases, even for methods

known to be very computationally intensive in other

use cases, such as symbolic execution. The test cor-

pus might then have the advantage of completeness,

while also being sustainable from a computational ef-

fort or time horizon perspective.

The methods described below formally assume

that the RPA workﬂow takes the structure of a di-

rected graph G in which each activity is a node. Cy-

cles can exist in this graph, and the starting activity

(i.e., node) is denoted Initial(G). The decision fac-

tor for a test case generation and execution process is

mainly related to branch points, i.e., when the next ac-

tivities are different depending on a certain condition.

The general idea is that when a branch point B occurs

on a path P of activities within G, the condition on

which the branch depends can be solved symbolically

with an SMT solver to check its feasibility. In our

case, we chose Z3 (Mendona de Moura and Bjorner,

2008) as the SMT solver for the framework. Several

strategies can be found in the literature, depending

on the complexity of the RPA workﬂow. In practice

and in collaboration with our industrial partner, we

found that most of the workﬂows used in the produc-

tion phase are small to medium in size. The sym-

bolic execution method (Baldoni et al., 2018) exhaus-

tively explores the graph G including loops. Since the

graphs of the workﬂows are usually small to medium

in terms of the number of operations (they generally

need to be evaluated visually), we have empirically

found that this method offers the best tradeoff be-

tween the completeness of the generated test corpus

and the computational efﬁciency. However, there are

rare cases where the workﬂows are very large, and in

RPA Testing Using Symbolic Execution

271

these cases concolic evaluation might have an advan-

tage as it covers the activities per unit time faster, cf.

(Paduraru et al., 2023).

Listing 1 shows the main loop of the implementa-

tion pseudocode in our framework. The process starts

with the initial activity node in the graph G ( Line 2),

inserts this initial path with a single node into a work-

list W , then extracts a promising path at each step of

the loop (with several possible customizable strate-

gies for evaluating path priorities), and continues its

forward execution, Line 7. The worklist W is a pri-

ority queue sorted by a priority of elements (paths).

By default, this priority is calculated based on how

deep in the G exploration tree the path is now. By de-

fault, paths that are at the top of the exploration tree

are promoted so that the algorithm is able to traverse a

variety of paths and activities in less time, rather than

focusing on single long paths with common activity

nodes. However, depending on the test goal, the user

is free to override this default behavior by using func-

tion hooks in our framework.

When generating new inputs to the work queue

W , the default calculation method for setting their

priority is based on the location (depth index) in the

tree where the branching constraint is reversed. Thus,

when sorting the priority queue W by priority, the de-

fault behavior is to promote changes to paths at the be-

ginning of previous paths. This is also used in (Gode-

froid et al., 2012b), but the user is free to override this

functionality with a hook function as needed.

1 // In i t the st a rt e x pl ora ti o n pat h with the e ntry n ode of

the w o rk f lo w grap h

2 star t_p at h = SM T Pa t h ([ G. e nt r y_ n od e ], p r io r ity =

MA X_P RI O RI T Y )

3 // Add t h is to t h e cur ren t Wo r kli st

4 W . a d d ( s ta rt_ pat h )

5 w hil e W . not Emp ty () :

6 c urr Pat h = W . e x tra c t ()

7 E xe c ut ePa th ( cu r rPat h , W )

Listing 1: The main loop of Symbolic execution using DFS

strategy

The code for continuing the execution of a given

path is shown in Listing 2. An execution path in this

purely symbolic model is abstracted by the code of

class SMT Path. Given knowledge of an initial set

of constraints on the variables in the DataStore (e.g.,

those propagated from annotations), Line 6 adds them

to the state of the SMT solver. Next, the implementa-

tion parses the current node to make the continuation

decision, Line 9.

When a branch node occurs, Lines 15-41, the cur-

rent path is cloned and split in two: one takes the

True branch and the other takes the False branch.

We add only the feasible paths to the future work-

list after calculating their priority and setting up the

next node for execution according to the considered

branch. It is important to note that for one of the

paths, the DataStore instance is also duplicated, Line

38. This ensures that both operate on different data

context values. This is also beneﬁcial for paralleliza-

tion, as branches from the worklist can then be exe-

cuted in parallel. Note that the implementation pre-

sented is depth-ﬁrst search (DFS) style, as the next

highest priority path continuation is the currently ac-

tively executing path, while the other is added to the

worklist and possibly executed later in the process,

Line 40.

1 Exec ut e Pa t h ( pat h : SMTPa t h , W : Wo rkl ist )

2 // Eac h p ath s t ore s the nex t n ode to ex e cut e ( i nit ial

is the ent ry nod e of the p a th )

3 c urr Nod e = pat h . ne xt N od eT o Ex ec u t e

5 // First , add all the c on s tr a in ts g i ven by the

Da t aS t or e ob j ect s re st r ic t io ns g iven by a nno ta t io n s

6 p a th . co nd i ti on s _s m t = D a t aS to r eT em p la te .

ge tV a r i ab le s As se rt i on s ()

8 // The no d e will a dva nce to the end of the W o rk f lo w

gra p h G at each i te r at i on of the pa t h

9 w h ile c ur r No d e != None :

10 // i f c urr ent n ode is not a br anc h type , jus t exe c ut e

it and ad v an c e to t he next n o de in t h e wo r kf l ow

11 if cu r rN o de . ty p e ! = B RAN C H :

12 Wo rk f lo wE x ec ut o r . Ex ecu t e ( cu rrN o de )

13 cu r rN o de = c ur r No d e . next ( )

14 // I f t h e cur r ent n ode is a branch ,

15 el s e :

16 // If br anc h n ode but t here is no sy m bo l ic v ar i abl e

use d in its c on d it i on e xp r es s io n the n j ust a d va n ce

17 if no t Ha s Sy mb o l i cV ar i ab le s ( c u rrN ode . c on d it i on )

18 // Get the re sul t of the e va l ua tio n and a d van ce

19 R e sul t = W o rk fl o wE xe c ut or . E x ec u te ( c u rr N od e )

20 c u rr N od e . ad v anc e ( Res u lt )

21 c o nt i nu e

23 // N o de has s y mb o li c vari a bles , b uild t h e

co nti nu a ti o n of the c u rre n t pa t h o n b o th

24 // T r ue and F a lse b ran che s with th e n ext no des and

SMT a sse rti on s nee d ed

25 ne wP a th _ on Tr u e = S MTP ath ( n o des = c u rr P at h . n ode s +

cu r rN o de . n e xt N od e ( T rue ) ,

26 co nd i ti o ns _s m t = cu r rP a th .

co nd i ti o ns _s m t + c ur r Nod e . co n di t io n )

27 ne wP a th _o n Fa l se = SM T Pa t h ( nod e s = cu r rPa th . no d es +

cu r rN o de . n e xt N od e ( F als e ) ,

28 co nd i ti o ns _s m t = cu r rP a th .

co nd i ti o ns _s m t + No t ( c urr Nod e . co n di t io n ) )

29 // T h en ch e ck wh i ch of them a r e f easi b le ,

pri o rit i ze , set th e n e xt s t ar t ing n o d es , c l one th e

30 // d a ta st o re i n st a nc e s su c h that t h ey co u ld wo r k

in para l lel , and add t h em to t he wo r kl i st

31 so lv a bl eN e wP at h s = []

32 if S MT S ol v er ( n ew Pat h_ o nT ru e ) h a s so l uti on :

33 s ol v ab le N ew Pa t hs . a d d ( n ew Pa t h_ on T ru e )

34 if S MT S ol v er ( n ew Pa t h_ o nF al s e ) has so lut i on :

35 s ol v ab le N ew Pa t hs . a d d ( n ew Pa t h_ on F al se )

36 for ne w Pa t h in so l va bl e Ne wP a th s :

37 n e wP a th . s c or e Pa t h ()

38 n e wP a th . d a ta _ st ore = cu r rP a th . d ata _st or e . c lon e ()

39 n e wP a th . n ex t No de T oE xe c ut e = c u rr N od e . ne x tN o de (

Tru e if n e wP a th == n e wP at h _o n Tr ue e l se Fa l se )

40 W. add ( n ew P at h _o nF a ls e )

41 bre a k

42 // I f at the end of the path , th e n st r eam ou t t h e

mod e l v a ri a bl e s

43 S t re a mO u t ( c u rrP ath )

Listing 2: The main loop of symbolic execution using DFS

strategy

Other implementations might also consider

breadth-ﬁrst-search (BFS) style, i.e., after a branch,

both branches are added to the worklist according

to priority, and a new path must be considered at

ICSOFT 2023 - 18th International Conference on Software Technologies

272

Figure 2: The ﬁgure shows the difference between the exe-

cution types DFS and BFS. Frontier nodes are represented

by broken circles, while the remaining nodes are consid-

ered visited nodes. The path in bold is the current (i.e., in

execution) path. In BFS-style execution, both new bound-

ary nodes are added to the priority queue worklist, and the

next iteration selects the top continuation node (by priority)

- possibly even the unexplored node on the left side of the

workﬂow graph. In DFS fashion, one of the two new nodes

is added to the work queue and further execution continues

on it.

each step. Figure 2 visually explains the difference

between the two.

5 EVALUATION

We evaluate the framework by providing metrics and

some other best practices that we identiﬁed while

working on a number of real-world applications au-

tomated by RPA workﬂows. A brief description of

these applications can be found below:

• BankLoanCheck: The automation of the eligibil-

ity check of customers based on features such as

the amount requested, loan term, existing credit

cards and loans.

• BankLoanRequest: The automation of the credit

processing as a continuation of the above process

after the credit check.

• EmployeesManagement: The automation of vari-

ous HR processes for employees within an orga-

nization.

• PrivateHospital: The automation of some pro-

cesses managing the relationship between a hos-

pital and its customers.

• InvoicesProcessing: The automation of a

producer-consumer paradigm that processes

invoices in PDF format and sends them to a

queue that automatically processes their inputs in

a connected database and operations.

Metrics and Discussion. To get an overview of

the complexity of the applications evaluated, Table 1

Table 1: The number of nodes (workﬂow activities) and

branch points for each evaluated application.

Model tested Nodes Branch nodes

BankLoanCheck 32 6

BankLoanRequest 20 11

EmployeesManagement 23 8

PrivateHospital 42 14

InvoicesProcessing 32 5

Table 2: The time needed (in minutes) for each application

to obtain a 100% coverage.

Model tested Time

BankLoanCheck 30.23 min

BankLoanRequest 15.44 min

EmployeesManagement 117.4 min

PrivateHospital 73.10 min

InvoicesProcessing 29.14 min

shows the number of total activity nodes and branch

points for each of these applications

Also, Table 2 shows the time needed for the fuzzer

to achieve full coverage of the activities (nodes) and

branches. We leave the evaluation of the coverage of

pairs of state values to future work in the next version

of our testing framework. One observation that can be

made to this point is that the time required to achieve

the full coverage discussed is not directly proportional

to the number of nodes. As a concrete example, the

time required to achieve full coverage for the Ban-

kLoanRequest and EmployeesManagement models is

very different, even though the corresponding com-

plexity of the underlying graphs is almost the same.

The main reason for this is that the latter component

requires certain input ranges and patterns to be pro-

posed by a producer component in order to trigger

some branch points at the consumer component.

On the other hand, as we have observed in prac-

tice, it is important to obtain good metric coverage

within a short time to meet today’s requirements in

agile development processes, e.g., continuous inte-

gration processes, smoke testing, evaluation of local

changes before submission, etc. To evaluate the pro-

posed set of applications and our testing framework

considering these requirements, we run the tool on

each application for a ﬁxed time of 60 minutes to un-

derstand how deep the testing process goes. The re-

sults are shown in Table 3.

Other Lessons Learned Identiﬁed During the

Evaluation Process. The following are additional

features implemented in our framework that have

been helpful in validating results and usability for in-

dustry.

• Seeds: Setting ﬁxed seeds for the fuzzer helped

RPA Testing Using Symbolic Execution

273

Table 3: Coverage of the evaluated applications obtained

after letting the fuzzer run for a ﬁxed time of 60 minutes.

Model tested Coverage (%)

BankLoanCheck 100%

BankLoanRequest 100%

EmployeesManagement 69%

PrivateHospital 93%

InvoicesProcessing 100%

the testing process both in implementation and de-

bugging, and in validating and reproducing results

while problems were observed.

• Results streaming support: This greatly facilitated

the evaluation process in practice.

• Results display options: Various options such as

displaying the variable context even if it is not

used in the branching processes, support for log-

ging to see the path of the current state in the

test process, debug images to visualize the trans-

formed graph between the pipeline components.

• Extensible, user-friendly annotations and mock-

ing support.

6 CONCLUSION AND FUTURE

WORK

In this paper we presented a framework for gener-

ating test suites suitable for RPA workﬂows testing.

The motivation started by the growing acceptance ra-

tio of RPA in different sectors and ranges of organi-

zation sizes. Our main contribution was to research,

observe, and adapt existing state of the art methods

for the RPA testing ﬁeld. The results and best prac-

tices identiﬁed could be valuable further both for aca-

demic and industry communities. We believe that this

is only the starting point and there are many future

ideas that can be investigated and implemented. For

instance, we will apply concolic execution for larger

suites of input workﬂows and bring in more machine

learning methods to testing, such as reinforcement

learning agents that can guide the testing process to-

wards certain goals faster. Also, we would like to add

more human-in-the-loop features in the testing phase,

to direct better the computational efforts. In the tech-

nical ﬁeld, we would like to increase the framework’s

chance of being adopted easier via a smoother integra-

tion of existing implemented workﬂows, which were

not previously authored for being tested (e.g., no an-

notation support).

ACKNOWLEDGEMENTS

We thank UiPath for their collaboration and sup-

port during the research and development of the pro-

posed methods. This research was supported by the

European Regional Development Fund, Competitive-

ness Operational Program 2014-2020 through project

IDBC (code SMIS 2014+: 121512).

REFERENCES

Aguirre, S. and Rodriguez, A. (2017). Automation of

a business process using robotic process automation

(RPA): A case study. In Proc. of Applied Computer

Sciences in Engineering - 4th Workshop on Engineer-

ing Applications, volume 742 of CCIS, pages 65–71.

Springer.

Baldoni, R., Coppa, E., D’Elia, D. C., Demetrescu, C., and

Finocchi, I. (2018). A survey of symbolic execution

techniques. ACM Comput. Surv., 51(3):50:1–50:39.

Bucur, S., Ureche, V., Zamﬁr, C., and Candea, G. (2011).

Parallel symbolic execution for automated real-world

software testing. In Proc. of the 6th Conf. on Com-

puter Systems, EuroSys’11, pages 183–198. ACM.

Cernat, M., Staicu, A., and Stefanescu, A. (2020a). Improv-

ing UI test automation using robotic process automa-

tion. In Proc. of the 15th Int. Conf. on Software Tech-

nologies (ICSOFT’20), pages 260–267. ScitePress.

Cernat, M., Staicu, A., and Stefanescu, A. (2020b). Towards

automated testing of RPA implementations. In Proc.

of 11th Int. Work. on Automating TEST Case Design,

Selection, and Evaluation (A-TEST’20), pages 21–24.

ACM.

Chac

on Montero, J., Jimenez Ramirez, A., and Gonza-

lez Enr

ıquez, J. (2019). Towards a method for auto-

mated testing in robotic process automation projects.

In AST’19 Workshop, pages 42–47.

Chen, B., Havlicek, C., Yang, Z., Cong, K., Kannavara,

R., and Xie, F. (2018). CRETE: A versatile binary-

level concolic testing framework. In 21st Int. Conf.

on Fundamental Approaches to Software Engineering

(FASE’18), volume 10802 of LNCS, pages 281–298.

Springer.

Chipounov, V., Kuznetsov, V., and Candea, G. (2012). The

S2E platform: Design, implementation, and applica-

tions. ACM Trans. Comput. Syst., 30(1):2:1–2:49.

Economy, A. (2020). Executive summary - the 2021 state

of rpa survey report. Report G00319864. Gartner.

Godefroid, P., Levin, M. Y., and Molnar, D. (2012a).

SAGE: Whitebox fuzzing for security testing. Queue,

10(1):20:20–20:27.

Godefroid, P., Levin, M. Y., and Molnar, D. A. (2012b).

SAGE: whitebox fuzzing for security testing. Com-

mun. ACM, 55(3):40–44.

Holmberg, M. and Dobslaw, F. (2022). An industrial case-

study on gui testing with rpa. In 2022 IEEE Int. Conf.

on Software Testing, Veriﬁcation and Validation Work-

shops (ICSTW), pages 199–206.

ICSOFT 2023 - 18th International Conference on Software Technologies

274

Leno, V., Polyvyanyy, A., Dumas, M., Rosa, M. L., and

Maggi, F. M. (2021). Robotic process mining: Vision

and challenges. Bus. Inf. Syst. Eng., 63(3):301–314.

Mendona de Moura, L. and Bjorner, N. S. (2008). Z3: an

efﬁcient SMT solver. In 14th Int. Conf. on Tools and

Algorithms for the Construction and Analysis of Sys-

tems (TACAS’08), volume 4963 of LNCS, pages 337–

340. Springer.

Paduraru, C., Cernat, M., and Staicu, A.-N. (2023). Con-

colic execution for RPA testing. In 27th Interna-

tional Conference on Engineering of Complex Com-

puter Systems (ICECCS’23). IEEE, to appear.

Ray, S. and et al. (2022). Gartner magic quadrant for robotic

process automation. Report 4016876. Gartner.

Yatskiv, S., Voytyuk, I., Yatskiv, N., Kushnir, O., Trufanova,

Y., and Panasyuk, V. (2019). Improved method of

software automation testing based on the robotic pro-

cess automation technology. In 9th Int. Conf. on Ad-

vanced Computer Information Technologies (ACIT),

pages 293–296.

RPA Testing Using Symbolic Execution

275