A Methodology for Enterprise Resource Planning Automation Testing

Application to the Open Source ERP-ODOO

Thierno Birahime Sambe

2 a

, Stephane Maag

1 b

and Ana Cavalli

1 c

Institut Mines-T

ecom/T

ecom SudParis, Universit

e Paris-Saclay, CNRS UMR 5157 Samovar, France

Institut Sup

erieur d’Informatique, ISI-DAKAR, Dakar, Senegal

Keywords:

ERP, Business Processes, Automated Testing, Test Generation, Test Execution, Business Driven Testing.

Abstract:

This paper presents an approach for the automated testing of Enterprise Resource Planning (ERP) systems.

ERPs are complex software systems that provide a chain management covering all corporate activities. Testing

of these systems is a complex task given the close interrelation between the functionalities of system modules.

Test automation is also an important issue, in order to reduce testing time and cost. To this end, our approach

for the automation of ERP systems testing, is based on the system modeling as a set of business processes

to meet the needs of the business and reduce, for this purpose, the risks of errors. The methodology used in

this context is to combine the system modeling and the tools to manage automation of ERP-tests. Following

this approach, from the basic requirements, a number of test purposes are deﬁned and test cases are generated

using a test generation tool, which are then run on the ERP system. In order to illustrate the application of the

proposed method, test experiments have been performed on a real case study, the ERP ODOO.

1 INTRODUCTION

Enterprise Resource Planning (ERP) Systems are

complex bundle of software that are well-integrated

in such a way that they present a one stop informa-

tion bay for all operations in the organization. They

encompass many modules and with every module in-

tegration comes a challenge and an opportunity for

testing (Nagpal et al., 2015). Enterprise Resource

Planning (ERP) system is an information system that

helps the organization to coordinate and integrate in-

formation within departments (Chen et al., 2016).

ERP software automates core corporate activi-

ties, such as manufacturing, human resource, ﬁnance,

and supply chain management, by incorporating best

practices to facilitate rapid decision-making, cost re-

ductions, and greater managerial control (Holland and

Light, 1999).

As stated in (Nagpal et al., 2015), there is an ex-

ponential rise in complexity of software testing with

the increase in the number of modules implemented.

With the rise in the implemented modules, functional

complexity increases, there is an increase in the inter-

faces between the modules that lead to an increase in

the user authorizations and access rights that further

https://orcid.org/0000-0002-6594-1077

https://orcid.org/0000-0002-0305-4712

https://orcid.org/0000-0003-2586-9071

aggravate the testing complexity of ERP implementa-

tions. Many of the ERP Implementation projects fail

because of the improper test planning and testing pro-

cess. To understand the importance of ERP testing,

testing professionals need to understand the variations

of the ERP systems (Software-Testing-Help, 2018).

The software vendors have their own methodolo-

gies for testing, but these focus on process ﬂows

through conﬁgured components. Such tests prove the

software ”does what it does” (Gerrard, 2007).

ERP Testing is really critical if the testing plans

do not cover the complete road-map of the implemen-

tation phase. All the modules within the system are

completely integrated and interrelated, it means that

all the functionalities are dependent on the function-

alities of other modules or other systems. The main

challenge is in collecting input data for testing the

feature and analyzing the correctness of the output

data, which requires domain knowledge (Software-

Testing-Help, 2018).

The customization that goes along with an ERP

system, plus the amount of complex business func-

tionality involved, can make testing ERP systems a

challenge of strategic importance. ERP is not just a

software, it is also a business process. It needs a ded-

icated workforce to maintain and test it. Given the

business orientation of most of ERP tests along with

the repetitive reruns of tests necessary when there are

new releases, testing can beneﬁt greatly from mainte-

Sambe, T., Maag, S. and Cavalli, A.

A Methodology for Enterprise Resource Planning Automation Testing Application to the Open Source ERP-ODOO.

DOI: 10.5220/0007923004070415

In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 407-415

ISBN: 978-989-758-379-7

407

nance friendly automation (Christine Paras, 2018).

To tackle the shortcomings of these traditional ap-

proaches, there is a growing need for solutions to

automate testing processes. Test automation is an

ideal approach to test software quality across regres-

sion cycles with reduced efforts, time and cost. With

these evolutions from time-to-time, test automation

has not just remained a traditional testing practice, it

has evolved to become a mature, business-driven test-

ing (BDT) program that ensures better test-coverage,

scalability and productivity in the entire testing ef-

forts to deliver quality software applications and sys-

tems (TestingWhiz, 2017). To this end, our approach,

for the automation of ERP systems testing, is based

on the modeling of business processes to meet the

needs of the business and reduce, for this purpose, the

risks of error compared to business processes initially

expressed by the top level ”top management”. The

methodology used in this context is to combine a set

of modeling methods (high-level business processes)

and tools to manage automation of ERP-tests. In this

test automation approach, the top management team

and business analysts intervene right from the start of

the project to deﬁne business rules and test cases and

generate automated scripts, which are then run on the

application.

Our paper is organized as follows. Section 2

presents the related work and Section 3 introduces

the basic concepts and the tools that will be used by

our testing approach. Section 4 presents our test au-

tomation approach based on the modelling of the ERP

business processes. Section 5 presents the results of

the test experiments we have performed on a real case

study: the ERP ODOO. Finally, Section 6 concludes

this work.

2 RELATED WORKS

Testing processes have been worked for a while and

there exist several proposals in the literature for ERP

Testing. We present in the following the ones we get

inspired.

Schliesser (Schliesser, 2007) points out that tra-

ditional software testing methods are not sufﬁcient

and not designed for meeting the challenges posed by

ERP implementations. He condescends that built in

mechanisms and documentations available from the

ERP vendors can be utilized to effectively plan mean-

ingful business test cases.

Gerrard (Gerrard, 2007) has noted the lack of

research in ERP testing. Few books that exist are

more focused on product centric testing rather than on

wholesome ERP testing, thus software ‘does what it

does’. The authors bring forth that testing in ERP im-

plementations is critical, but is often neglected. They

have presented ground work to deﬁne test methods

and tools speciﬁc to ERP implementations.

Wieczorek et al. (Wieczorek et al., 2008) dis-

cussed that software development and testing of ERP

systems require methods that are dedicated to tackle

the special features of ERP systems. The complex

ERP systems make manual testing cumbersome, and

even effective automated testing requires appropriate

test data. The authors came up with challenges and

possible solutions for the test data required for auto-

mated testing in case of ERP systems.

Wieczorek and Stefanescu (Wieczorek and Ste-

fanescu, 2010) point out that system level testing is

the dominant testing approach in case of ERP sys-

tems. Recent shift of ERP systems towards SOA has

led to the demand of black box testing techniques.

They advocate more research in system testing with

speciﬁc focus on user interfaces in ERP systems.

In (Downing, 2006), a comprehensive report on

twelve mistakes that should be avoided is written.

The authors also depict Best Practices that need to

be adopted in order to manage quality in an ERP im-

plementation. Ensuring quality itself is a team effort

from the ERP vendor, implementation partner, host-

ing provider, technical and business teams.

Deanna Legge (Legge, 2011) underlined the need

for structuring a robust testing strategy in her paper on

ERP testing methodology approach. She emphasized

that since ERP systems are complex that encompass

several integration points, geographies, customiza-

tions, etc.; organizations continuously face challenges

to deliver quality ERP solutions.

3 BASICS PRELIMINARIES

3.1 Extended Finite State Machine –

EFSM Model

This section introduces the notations related to the

deﬁnition of an Extended Finite State Machine. As

deﬁned in (Maag et al., 2008), an Extended Finite

State Machine (EFSM) is an ordinary Finite State Ma-

chine (FSM) augmented with context variables, in-

put/output parameters, predicated and update func-

tions. Given input and output alphabets I and O, we

denote by Ri the set of input parameters i I, and by Qo

the set of output parameters for o O. We also denote

by R the union of Ri over all i in I and by Q the union

of Qo over all o in O. The ﬁnite set of context vari-

ables is denoted by V. As usually, we use N to denote

ICSOFT 2019 - 14th International Conference on Software Technologies

408

the set of natural numbers. An Extended Timed Finite

State Machine, in short ETFSM, is a tuple M = (S, s0,

I, O, T, δ, v0) where:

• S is a non-empty ﬁnite set of states with the initial

state s0;

• I and O are input and output alphabets;

• T is the set of transitions;

• δ : S −→ S×{N ×{∞}} is a timeout function; and

v0 is the vector of initial values of the context vari-

ables

3.2 IF-Language

3.2.1 IF-Model

IF is a formal method based on communicating timed

automata in order to model asynchronous commu-

nicating real time systems (Bozga et al., 2002). In

IF, a system is expressed by a set of parallel pro-

cesses communicating asynchronously through a set

of buffers.

A process instance can be created and destroyed

dynamically during system execution. An IF process

is described as a timed automaton extended with dis-

crete data variables. A process has a set of control

states and a private buffer for input messages, and can

have local data, such as discrete variables and clocks.

There are two types of control states: stable states and

unstable states. An unstable state is a temporary state

where no interleaving between processes is possible.

In other words, if a process moves to an unstable state

by an action, the atomicity of the execution is guaran-

teed until it reaches a stable state.

Transitions describe the behavior of a process on

stimuli. A transition can be triggered either by (timed)

guards or by an input message where an urgency at-

tribute (eager, delayable or lazy) deﬁnes the priority

of the transition execution over time p.

When an eager transition is executable, time

progress is blocked until the transition is executed.

If there is an executable delayable transition, time

can progress as long as the transition is executable.

If time progress makes the delayable transition

non-executable, time progress is blocked until the

transition is executed. For lazy transitions, time

can progress although the transitions become non-

executable. The action of a transition may include

sending output messages, setting/resetting clocks, as-

signment of variable values, and creation/destruction

of processes.

3.2.2 IF Toolset

The IF toolset (Bozga M, 2004) provides an environ-

ment for modeling and validation of an IF speciﬁca-

tion. The core components of the toolset are the IF

static analyzer and the IF exploration platform. The

IF static analyzer transforms an IF speciﬁcation into

an abstract syntax tree which is a collection of C++

objects. The IF exploration platform performs the

simulation of process executions using the abstract

syntax trees. A set of APIs is provided by the IF ex-

ploration platform, which allows implementation of

user-speciﬁc exploration.

In the IF toolset, it is possible to check if given

properties hold for an IF speciﬁcation using ob-

servers. Once a property is described in the IF lan-

guage using a speciﬁc syntax for observers, e.g. mon-

itoring of events and cutting off generation of irrel-

evant states, it is executed in parallel with the target

system.

3.3 Selenium Webdriver

• Selenium

Selenium IDE is a one of the most popular free open-

source automated testing tool which provides a test-

ing framework for testing web applications and sup-

porting multiple kinds of frameworks. It can be eas-

ily downloaded from internet as a plug-in for some

browsers. It is basically used by the web devel-

opment community to perform automated testing of

web applications. We choose in our study Selenium

Webdriver because Selenium IDE does not support

record-playback feature and also it is most supported

for web-application testing (Monier and El-mahdy,

2015).

Selenium is a web testing tool which uses simple

scripts to run tests directly within a browser (Holmes

and Kellogg, 2006). It uses JavaScript and iframes

to embed the test automation engine into the browser.

This allows the same test scripts to be used to test

multiple browsers on multiple platforms. Selenium

gives the user a standard set of commands such as

open (a URL), click (on an element), or type (into

an input box); it also provides a set of veriﬁcation

commands to allow the user to specify expected val-

ues or behavior. The tests are written as HTML ta-

bles and run directly in the browser, with passing

tests turning green and failing tests turning red as

the user watches the tests run. Because Selenium

is JavaScript-based and runs directly in the browser

(the user can see the test running), it overcomes some

of the problems encountered by users of HttpUnit or

Canoo WebTest, particularly problems related to test-

A Methodology for Enterprise Resource Planning Automation Testing Application to the Open Source ERP-ODOO

409

ing JavaScript functionalities. Two additional useful

tools are also available for use with Selenium: 1. the

Selenium IDE (originally called the Recorder), which

allows users to navigate their applications in Firefox

and record their actions, forming tests; and,

2. a “Remote Control” server which allows users

to write test directly within the programming lan-

guage of their choice – thus enabling conditional

logic within tests, try/catch blocks, and other power-

ful functionalities available only within programming

languages.

Selenium allows the identiﬁcation of elements us-

ing the browser’s DOM object, the test can be writ-

ten using speciﬁc identiﬁers of the necessary element,

such as name, id, or xpath (Holmes and Kellogg,

2006) (Table 1).

Table 1: Input data for a Selenium Test.

type name=theField Text to submit

clickAndWait id=SubmitButton

assertText xpath=//h1/span Success!

This test might be written for an HTML page as

simple as (Fig. 1):

Figure 1: HTML test cases in selenium.

When the test is run, each command is highlighted

as it executed, and the assert steps turn red or green

to indicate success or failure. After the whole test is

complete, the test is marked as red or green in the

Suite.

• Robot Framework

Robot Framework (Pajunen et al., 2011) is a generic

keyword-driven test automation framework meant for

acceptance level testing. The tool uses keyword ab-

straction for test design. Keywords are divided into

higher-level user keywords and lower-level library

keywords. The user keywords are built by creating

combinations from the keywords presented in the key-

word libraries. Test cases are described with scripts

that use the keywords and control structures, such as

loops. The available keywords of Robot Framework

are deﬁned in libraries. New libraries can be imple-

mented with Python or Java. There are two types of li-

braries: standard and external. The standard libraries

are distributed with Robot Framework and the exter-

nal libraries are released in separate packages:

Standard libraries

- BuiltIn: Keywords for generic testing needs,

such as variable veriﬁcation, conversions and delays.

- Operating System: Keywords for operating sys-

tem tasks,such as ﬁle system operations and executing

commands.

- Telnet: Keywords for Telnet connection han-

dling.

- Collections: Keywords for handling lists and

dictionaries.

- String: Advanced string handling keywords.

- Dialogs: Keywords for getting user input during

test execution.

- Screenshot: Keywords for capturing and storing

screenshots.

4 ERP TEST AUTOMATION:

APPROACH BASED ON THE

MODELING OF HIGH LEVEL

BUSINESS PROCESSES

4.1 Approach based on Business Process

Modeling (Business Driven Testing)

The problem to be solved is how to manage the au-

tomation of ERP systems tests, based on the modeling

of business processes to meet the needs of the busi-

ness and to reduce, for this purpose, the risks of error

compared to business processes initially expressed by

the top level ”top management”.

The methodology used, in this context, consists

of combining a set of modeling methods (high-level

business processes) and tools to manage test automa-

tion of ERP, which involves the following different

steps:

Step 1: We use Business Driven testing (BDT) to

Model the High Level Business Processes deﬁned by

the Top Management; which we have called ”HLBP”

in our architecture, to contribute to approach based on

business needs. Behavior Driven Tests (BDT) focus-

ing on high level design, not on the technical imple-

mentation nor the technical terminology. Stakehold-

ers or Users, Business Analysts, Testers, Developers

will involve and perform their Respective roles. Users

and business Analysts participate in test cases review

process and give their feedback to enhancement. Be-

haviour driven tests (BDT) are easier to modify and

hence. It is then very easy to maintain.

In this step, it is a question of referencing (gath-

ering) all the Business Processes deﬁned by mutual

ICSOFT 2019 - 14th International Conference on Software Technologies

410

Figure 2: Level Business Process Model.

agreement between the various stakeholders. Then

we proceed to the tree of these processes starting with

those of rank 1 (high-level process) then by the pro-

cesses of the following ranks. At this stage, the fol-

lowing elements will be retained (illustrated by Figure

• Objectives of the process

• Purpose of the process

• Main actor(s) of the process

Step 2: Explode all Rank 1 processes (high level)

in Tier 2 processes that will cover all processes and

behaviors of the business processes of Rank 1. We

will apply the Behavior Driven Testing (BDT) from

model based testing by using the IF-language. The

automation of tests generation from a formal model,

also known as a formal model-based testing, was inte-

grated into the software development process and was

adopted in this step in our test automation architec-

ture. This technique is known as model-based testing

and it refers to the ability to detect failures which are

not conform to a model. There are several approaches

used for model-based testing that include ﬁnite state

machines -FSM- and labeled transition systems -LTS-

with several extensions and variations. The use of ﬁ-

nite state machines is the traditional technique used

for testing, originating in the domains of communi-

cation protocols and sequential circuits. The formal

model proposed for ERP-Testing Automation is based

on ﬁnite state machines augmented with time and pa-

rameters, allowing the representation of basic units of

the real-time system. In order to represent temporal

requirements, timeouts are used since they allow the

easy modeling of some internal critical issues of the

system. The Figure 3 illustrates the concept of a ﬁnite

state machine with timeouts.

The fundamental components of ﬁnite State Mod-

els include:

• State represents the “mode of being” for the sys-

tem at any given time.

• Transition describes a single pathway from a state

to another state. The set of all Transitions describe

all possible paths among the deﬁned states. A

Transition contains an event that it is subscribing

Figure 3: Finite state machine with timeouts.

Figure 4: Tier 1 ”Manage Store Trade” process.

to (the event that triggers execution of the Tran-

sition), a Condition and an Action. A Transition

also contains references to the state from which

the Transition is exiting (i.e. the “from” state) and

the state to which the Transition is entering (i.e.

the “to” state).

• Event is the mechanism that the system uses to

interact with external systems and with itself.

• Condition represents a set of logic that evaluates

to a Boolean result. A Condition is used to deter-

mine if a Transition is to be executed.

• Action is the logic to be executed when a Transi-

tion is executed.

Example: for an ERP of commercial manage-

ment of a store, where the top management decides to

”Manage the store’s trade”. We deﬁne all processes

and activities in the Tier 1 ”Manage Store Trade” pro-

cess (Fig. 4).

• Step 3: it consists in deﬁning the test objectives

emanating from the activities and behavior of the

business processes.

A test objective describes a particular function-

ality of the implementation under test, by spec-

ifying the property to be checked in the system

implementation. It is an observable action of the

system that once described in IF-language is used

for guiding the space exploration of the system’s

states. A test objective is described as a conjunc-

tion of conditions, including optionally the fol-

lowing: an instance of a process with an iden-

tiﬁer, a state of the system (a source state or a

destination state), an action of the system (a mes-

sage sent, a message received, an internal action),

A Methodology for Enterprise Resource Planning Automation Testing Application to the Open Source ERP-ODOO

411

a variable of the process or a clock of the process,

specifying a value and its state (active or inactive).

A test objective obj is formally described as in the

ﬁgure below (Figure 5):

Figure 5: Test-objective structure.

• Step 4: derivation of objective, measurable and

manageable test objectives with the TestGen-IF

tool (hwa, 2009). The tool was deﬁned and

implemented for modeling and simulating asyn-

chronous timed-systems such as telecommunica-

tion protocols or distributed applications. It is

based on active testing techniques, allowing au-

tomatic generation of test cases from a formal de-

scription of the studied system. The generation is

made according to speciﬁc objectives called test

purposes, which are described more in detail in

the next section.

TestGen-IF tool allows to construct the accessi-

bility graph from an IF speciﬁcation. Therefore,

the inputs necessary for TestGen-IF tool are the

formal functional speciﬁcation of the system and

the speciﬁcation of test objectives that we wish

to check on the system implementation. Then, the

tool makes a partial exploration of the states space

of a model, guided by the tests objectives (Fig. 8).

Illustration 1: Example Process Model: in Sale

Module on ERP

Figure 6: Process Model : in Sale Module on ERP.

In this example (Fig. 6), we will build an overly

simpliﬁed control process. The order process is:

order received, inventory control, cancel the order

if the product is not in stock. Otherwise, complete

the command.

Illustration 2: Example Process Model Processes

and Asynchronous Events : Unlike our ﬁrst exam-

ple which showed a very simple order manage-

ment process. In this example (Fig. 7), the pro-

Figure 7: Sale Order: in Sale Module on ERP.

cess is short-lived and synchronous - as soon as it

is started, it runs without any dependency on in-

coming events. The second example is similar to

the ﬁrst, but with added asynchronous behavior.

In this example, the process waits and responds

to asynchronous events that indicate changes to

the inventory. When the command is created, if

the stock is available to execute the command, the

command is terminated normally. Otherwise, the

process waits until it receives a notiﬁcation that

the appropriate inventory is available when the

process is complete. The new state template is

shown below:

• Step 5: It translates the Objectives into the

Automation Tool ”Selenium” with WBA (Web

Brother Automation) for the automatic execution

of test cases in ERP;

• Step 6: A verdict is provided by the system to con-

ﬁrm if the tests are ”OK” or ”NOK”

5 EXPERIMENTS: APPLICATION

TO THE ERP-ODOO

Odoo is not simply an ERP software shipped by Odoo

SA. It is an open source project with an important

community of partners, clients, individuals or com-

panies, who believe in the value of sharing: code of

course, but also tips and ideas.

How to make and execute the tests: Recording ac-

tions using Selenium :

• We install Selenium on Odoo (Selenium, 2018).

This addons adds tags in the XML of Odoo that

help Selenium recorder to understand the HTML

structure and record it. .

• We install selenium recorder on Firefox (Builder,

2018). This addons adds in your browser an op-

tion to ”start recording”|”stop recording”.

• 1. Add context in HTML code : ﬁrst, the web-

selenium Odoo module generates semantically

richer HTML elements. By using Odoo’s tem-

plate extending mechanism, this module adds the

ICSOFT 2019 - 14th International Conference on Software Technologies

412

Figure 8: Our TestGen IF tool.

Figure 9: ERP-System Test Automation.

A Methodology for Enterprise Resource Planning Automation Testing Application to the Open Source ERP-ODOO

413

Figure 10: The Web-Selenium module.

model’s name as an attribute of each related ele-

ments.

5.1 Test Automation: Workﬂow Sale

Order in the ODOO ERP System

We automatically create a Sale Order, conﬁrm it and

deliver it as illustrated on the Figure 7.

• Install and conﬁgure ODOO;

• In ODOO, activate the modules Sale and Stock,

with demo data;

5.2 Web Selenium Module Setting

Go to a directory set in the –addons-path of Odoo.

In the application, go to ”Settings>Users”, ”Edit Ad-

ministrator” and tick the “Enable Technical Features”

checkbox. Save and refresh the page: an “Update

Modules List” entry appears in the left menu. Pro-

cess with the update. You are now enable to ﬁnd and

install the Web-Selenium module (Fig. 10). Inspect

the “Create” button from ”Sales > Sales Orders List

View”: a data-bt-testing-model-name attribute set to

“sale.order” is now set up.

5.3 Odoo Robot Framework

• Install Robot Framework ﬁrst;

• Robot Framework start-up script pybot is now

available;

• Setting Firefox Proﬁle : Firefox is used as the de-

fault browser for our tests. Whenever Pybot ex-

ecutes the Open Browser keyword, Selenium cre-

ates a brand new Firefox proﬁle;

• Get odoo-robot-framework.

Now we are ready to run the test suite (Fig. 11).

6 CONCLUSION

The paper presented an automated model-based test-

ing approach for the test of ERP systems. A number

Figure 11: PyBot demo-80-full-workﬂow.robot.

of major activities in model-based testing are included

in the experiments: modeling, test generation and test

execution. A number of basic requirements are identi-

ﬁed from the ERP speciﬁcation and then described as

properties in the IF language. From the basic require-

ments, a number of test purposes are deﬁned and test

cases are generated using the TestGen-IF tool where

the generated test cases satisfy the transition coverage

criterion. This approach offers several advantages:

- it covers all the steps of the software develop-

ment cycle, from the business process modelling to

the test generation and test execution;

- it is based on the modelling of business pro-

cesses, specifying their requirements and reducing the

risk of errors when compared with other models (for

instance these based on the top management level);

- it provides a testing methodology that combines

a set of modeling methods (high level business pro-

cesses) and tools to manage the automation of ERP

test generation and execution;

- it reduces time and cost of the testing procedure

for ERP System.

The approach has been applied to a real case study,

the ERP ODOO, and the experimental results are very

promising concerning the use of model-based testing.

As future work, we plan to complete the test ac-

tivity by:

- the application of monitoring techniques to ana-

lyze the behavior of the system without disrupting its

operation;

- implementing an algorithm for the test architec-

ture and measuring its complexity;

- the implementation of the improved Selenium

ICSOFT 2019 - 14th International Conference on Software Technologies

414

script.

We will perform other experiments applied to

much more complex work ﬂows. In the future applied

to proprietary ERP like SAP and People soft. Also a

comparative study will be carried out with similar re-

search.

REFERENCES

(2009). Blind review. In Formal Techniques for Distributed

Systems, pages 122–136. Springer.

Bozga, M., Graf, S., and Mounier, L. (2002). If-2.0: A val-

idation environment for component-based real-time

systems. In International Conference on Computer

Aided Veriﬁcation, pages 343–348. Springer.

Bozga M, Graf S, O. I. S. J. (2004). The if toolset, lecture

notes in computer science, vol. 3185. In 2004, The IF

toolset, SFM-04 (Lecture Notes in Computer Science,

vol. 3185). Springer: Berlin, 2004; 237–267.

Builder, G. S. (2018). Githup web selenium builder.

https://github.com/SeleniumBuilder/selenium-

builder/.

Chen, S., Elbashir, M., Peng, X., and Zhu, D. (2016). The

effect of erp systems competences on business process

and organizational performance. International Jour-

nal of Management Theory and Practices, 17(1):5–35.

Christine Paras, T. N. (2018). How to automate or-

acle erp testing. In 2018, How to Automate

Oracle ERP Testing; Posted in Test Automa-

tion. https://www.logigear.com/magazine/test-

automation/how-to-automate-oracle-erp-testing//.

Downing, D. (2006). White paper: Managing quality in

your erp project: 12 mistakes to avoid & best prac-

tices to adopt. In 2006, White paper Mentora Group.

Mentora Group, www.mentora.com.

Gerrard, P. (2007). Test methods and tools for erp im-

plementations. In Testing: Academic and Indus-

trial Conference Practice and Research Techniques-

MUTATION (TAICPART-MUTATION 2007), pages

40–46. IEEE.

Holland, C. and Light, B. (1999). A critical success fac-

tors model for erp implementation. IEEE software,

16(3):30–36.

Holmes, A. and Kellogg, M. (2006). Automating functional

tests using selenium. In AGILE 2006 (AGILE’06),

pages 6–pp. IEEE.

Legge, D. (2011). White paper: Erp testing methodol-

ogy approach and leading practices. In 2011, White

Paper, Hitachi Consulting, www.hitachi.com. Hitachi

Consulting, www.hitachi.com.

Maag, S., Grepet, C., and Cavalli, A. (2008). A formal vali-

dation methodology for manet routing protocols based

on nodes’ self similarity. Computer Communications,

31(4):827–841.

Monier, M. and El-mahdy, M. M. (2015). Evaluation of

automated web testing tools. International Journal

of Computer Applications Technology and Research,

4(5):405–408.

Nagpal, S., Khatri, S. K., and Kapur, P. (2015). Prioritiza-

tion and ranking of erp testing components. In 2015

4th International Conference on Reliability, Infocom

Technologies and Optimization (ICRITO)(Trends and

Future Directions), pages 1–6. IEEE.

Pajunen, T., Takala, T., and Katara, M. (2011). Model-

based testing with a general purpose keyword-driven

test automation framework. In 2011 IEEE Fourth In-

ternational Conference on Software Testing, Veriﬁca-

tion and Validation Workshops, pages 242–251. IEEE.

Schliesser, S. (2007). An approach to erp testing us-

ing services. In IEEE International Conference on

Software-Science, Technology & Engineering (Sw-

STE’07), pages 14–21. IEEE.

Selenium, G. W. (2018). Githup web selenium.

https://github.com/brain-tec/web selenium.

Software-Testing-Help (2018). The beginner’s guide to

erp testing (sap testing). In 2018, Last Update,

The Beginner’s Guide to ERP Testing (SAP Testing)

– Part 1. https://www.softwaretestinghelp.com/guide-

erp-testing-sap-testing-1/.

TestingWhiz (2017). Creating Business Value with

Business-Driven Test Automation. Technical report,

TestingWhiz.

Wieczorek, S. and Stefanescu, A. (2010). Improving test-

ing of enterprise systems by model-based testing on

graphical user interfaces. In 2010 17th IEEE Interna-

tional Conference and Workshops on Engineering of

Computer Based Systems, pages 352–357. IEEE.

Wieczorek, S., Stefanescu, A., and Schieferdecker, I.

(2008). Test data provision for erp systems. In Soft-

ware Testing, Veriﬁcation, and Validation, 2008 1st In-

ternational Conference on, pages 396–403. IEEE.

A Methodology for Enterprise Resource Planning Automation Testing Application to the Open Source ERP-ODOO

415