GB2524737A

GB2524737A - A system and method for testing a workflow

Info

Publication number: GB2524737A
Application number: GB1405723.6A
Authority: GB
Inventors: Miroslaw Rakowski
Original assignee: KAINOS WORKSMART Ltd
Current assignee: KAINOS WORKSMART Ltd
Priority date: 2014-03-31
Filing date: 2014-03-31
Publication date: 2015-10-07
Also published as: GB201405723D0

Abstract

A computer-implemented method and system of testing updates to a software application where sequence of steps through the process are user- or permission-specific e.g. human resource workflow system. The system comprises a test module 105 which is in communication 115 with a target system 110 where the workflow process resides; a memory 120 storing a plurality of pre-codified test scripts wherein each precodified test script is configured for testing a corresponding step of the process; and a processor 125 for executing the test module to extract a plurality of steps from the workflow process and the processor further configured to match 130 the extracted steps with the pre-codified test scripts and to retrieve and apply said pre-codified test scripts to the workflow for testing thereof. In this way, if a specific sequence of steps in a process changes with a software update, it is not necessary to generate an entirely new test script, instead a different sequence of step-specific test scripts may be called. This system and method may be particularly suitable for human capital management or human resources software.

Description

A system and method for testing a workflow

Field of the Invention

The present teaching relates to a system and method for testing a workflow.

Background

In the context of Human Capital Management (HCM) systems, workflow processes represent models of the steps and activities performed within organisations when performing actions in relation to workers. The action of hiring a new employee, transferring them and terminating them may constitute three separate processes. Within these processes there are likely to be many individuals involved in approving and reviewing steps that have been performed. During times of system upgrade, maintenance and refresh these processes will be rigorously tested by the HCM system administrators so as to verify the integrity of these actions following a change to the underlying system. The purpose of this testing is to verify that process executions generate the same results subsequent to a system change as they did prior to a system change. During this testing exercise, the system administrators are often required to test a considerable number of these processes and will be required to authenticate with the HCM system as a number of different roles so as to exercise the review and approval steps assigned to specific inddduals. This often requires considerable time and effort, especially for the more complex processes, which are often also the most important. As a means of addressing this challenge, organisations often look to automated testing tools for efficiency gahs.

Automated testing tools require test scripts to be created for each scenario within a process. Traditional automated testing tools would require automation scripts to be created for the specific sequence of steps. If any of the steps changed, a new ailomation script would need to be codified and then executed. This is undesireable.

There is therefore a need for a system and method for testing a workflow which addresses at least some of the drawbacks of the prior art.

Summary

Accordingly, the present teaching relates to a computer implemented method of testing a workflow as detailed in claim 1. Furthermore, the present teaching relates to a non-transitory computer-readable medium as detailed in claim 19. Additionally the teaching relates to a system for testing a workflow process as detailed in claim 20. Advantageous embodiments are detailed in the dependent claims.

In one aspect there is provided a computer-implemented method of testing a workflow process, the method comprising operating a processor to: provide a test module which is in communication with a target system where the workflow process resides, associate a plurality of pre-codified test scripts with the test module; each pre-codified test script is configured for testing a corresponding event; configure the test module to extract a plurality of events from the workflow process, match the extracted events with the pie-codified test scnpts, retrieve the pie-codified test scripts which match the extracted events; and apply the pie-codified test scripts to the workflow for testing thereof.

In another aspect, a test data set on the target system is accessed by the test module. Advantageously, a test scenario is created which includes data derived from the test data set. Ideally, the test module is configured to execute the test scenario on the target system to generate test results. Preferably, the method includes associating expected results with the test scenario. Ideally, the generated test results are compared with the expected results.

In a further aspect, an indication is provided on whether the generated test results deviate from the expected results. Preferably, the indication includes indicia representative of a pass or fail.

In another aspect, a status module is provided for providing a real-time visually perceptible representation of the test case during execution thereof.

In one example, each event of the workflow process is assigned to one or more use is.

In another exemplary arrangement, the test module identifies one or more credentials associated with the one or users to whom the next event in the workflow is assigned to. Preferably, the test module extracts the pre-codified test scripts based on the data associated with the next event in the workflow process.

In a further exemplary arrangement, users assigned to respective events of the workflow have an associated username and/or password. Ideally, the test module is configured to reset the user password to a nominal password. In one example, the test module is configured to reset the user password to a random character password.

Advantageously, the username is contained in the test data set. Preferably, the username is retrieved by the test module interrogating the test system. In an exemplary arrangement, the test module is operable to log into the target system using the username and a random character password.

The present teaching also relates to a non-transitory computer-readable medium comprising instructions which, when executed, cause a processor operating a network node to implement a method of testing a workflow process, the method comprising: providing a test module which is in communication with a target system where the workflow process resides, associating a plurality of pre-codifled test scripts with the test module; each pre-codified test script is configured for testing a corresponding event; configuring the test module to extract a plurality of events from the workflow process, matching the extracted events with the pre-codified test scripts, retrieving the pre-codified test scripts which match the extracted events; and applying the pre-codified test scripts to the workflow for testing thereof.

The present teaching further relates to a system for testing a workflow process, the system comprising: a test module in communication with a target system where a workflow process resides, memory for storing a plurality of pre-codified test scripts which are associated with the test module; each pre-codified test script is configured for testing a corresponding event; a processor for executing the test module to extract a plurality of events from the workflow process, the processor being further operable to: match the extracted events with the pre-codified test scripts, retrieve the pre-codified test scripts which match the extracted events; and apply the retrieved pre-codified test scripts to the workflow for testing thereof.

Brief Description Of The Drawings

The present teaching will now be described with reference to the accomnying drawings in which: Figure 1 is a flow chart of an exemplary workflow.

Figure 2 is a system for testing a workflow in accordance with the present teaching.

Figure 3 is a system level diagram of the system of Figure 2.

Figure 4 is a flowchart showing exemplary steps of a method of testing a workflow process.

Figure 5 is a system level diagram illustrating the method steps for testing a workflow process.

Detailed Description of the Drawings

The present teaching will now be described with reference to an exemplary system for testing a workflow. It will be understood that the exemplary system is provided to assist in an understanding of the present teaching and is not to be construed as limiting in any fashion. Furthermore, modules or elements that are described with reference to any one Figure may be interchanged with those of other Figures or other equivalent elements without departing from the spirit of the present teaching.

Referring initially to Figure 1, there is provided a flow chart illustrating an exemplary workflow process 10. Automated testing tools require test scripts to be created for each scenario within the workflow process. The workflow process 10 displays a map of the possible paths through a simple process for hiring a worker. The three possible paths are: 1. Steps 1,2,3,4,5,6,10; 2. Steps 1,2,3,7,8,10; and 3. Steps 1,2,3,9,10.

Traditional automated testing tools would require automation scripts to be created for the specific sequence of steps in each of the three scenahos above. If any of the steps are changed for any of the three paths, a new automation script would need to be codified and then executed. The present disclosure removes the need for these design-time changes and additions to automation scripts.

Figure 2 illustrates an exemplary test system 100 comprising a test module 105 which is in communication across a network 115 with a target system 110 where the workflow process 10 resides. The test module 105 is designed to remove the need for end-users to make design-time changes to automation test scripts when testing the workflow 10.

This is achieved by the test module 105 performing real-time interrogation of the sequence of the process steps of the workflow 10 and constructing automation test script steps during the runtime operation of the automated test. A plurality of pre-codified test scripts which are associated with the test module 105 are stored in memory 120.A processor 125 of the test module 105 is configured to extract a plurality of events from the workflow process 10 on the target system 110. An event corresponds to one of the steps of the process such as steps 1-10 of workflow process 10. A matching module 130 is configured to match the extracted events with the pre-codified test scripts. The processor 125 is operable to retrieve the pre-codified test scripts which match the extracted events; and apply the retrieved pre-codified test scripts to the workflow lOon the target system 1 10 for testing thereof.

Figure 3 provides exemplary architecture of the system 100. The diagram is segmented into duties performed by the end-user and the service provider and those actions performed at design time and during run-time. There are a finite number of processes which can be performed. The key presses and button invocations required to perform each of these processes are codified in test automation scripts and form part of the test automation script library which are stored in memory 120. This library straddles both the Design Time and Run Time states. The Design Time state reflects the codification of the key presses and button invocations. The Real Time state reflects the interrogation of the process activity to determine what the proceeding step is so as to load the appropriate test automation script from the Test Script Library.

Figure 4 illustrates an exemplary implementation of the architecture of Figure 3 in operation. The test module 105 has a plurality of objects indicated by reference numerals 1, 2, 3, 4, 5, and 6. The objects 2, 3,4, Sand 6 are system components. The interaction between the system components is described at a high level below. In block 1 users collate the input data required to test the specific processes in the target system 110. This data may be input into a standard set of spreadsheet templates for processing bya test builder component 140 in Block 2. The test builder component 140 creates test cases and test runs combining the input data from the user and the specific process action to test before submitting this test run onto the test queue in block 3. The test queue 142 manages the submitted requests from users and hands these requests off to a test runner component 144 in block 4. The test runner 144 contains the library of test scripts for each process, the communication libraries for interaction with the target system 110 and browser automation software used to replicate keystrokes and bufton presses of end-users. The test runner 144 receives the test input data provided by the users from the test queue 142.

The interaction between the test runner 144 and the target system 110 is performed at two levels -using the user interface (UI) and the application programming interface (API). The browser automation software performs the UI interaction to identify thecurrent context of the automated test and to input the test data provided by the users through the use of the library of test scripts for each process. Upon completion of the automation the test runner 144 records the results of the execution ma shared data repository in block 6.

The method being described is implemented primarily by the test runner 144. The test runner interfaces with the target system 110 to allow data-driven automated tests to be performed without the need for users to amend test scripts. The underlying workflow engine performs the assignment of tasks within each process to specific individuals within the target system 110. Upon step completion, the method reads the workflow assignment summary to identify to whom the next step in the process is assigned and then uses the public API to retrieve the process event details for the next steps and the details of the assigned user. With this real time information, the ability exists to cater for all and any combinations of process steps.

Exemplary steps of the test runner 144 are illustrated in Figure 5. Step 1 the specified process for testing and test input data are retrieved from the test queue 142. Step 2, the associated process test script library is loaded based on the input data provided by the user. Step 3, a web browser is launched and the URL of the destination target system is used to display the login page. Step 4, the username of a user specified in the input data is identified. Step 5, the password for that user is reset to a random set of characters using the target system API. Step 6, the username and random-character password are used to login to the target system 110 through the generated browser process. Step 7, the first system screen is displayed and the first action in the script is performed as defined in the process test script library. Step 8, the requisite data for that screen is entered through the process of mapping what was entered by the user to the controls on the screen, again using the test script library. Step 9, the first step in the process workflow execution is completed and the submit action is clicked on the screen within the browser, moving the process to the next step in the sequence. Step 10, the next step that is required is calculated by the test system 100 based on the configuration of the current process and the input data provided. Step 11, the details of the next step are provided on a summary screen indicating that a subsequent event is requiring attention by a specific user Step 12, the details of this event are then retrieved using the target system API where extended event details are retrieved using the unique identifier of the event Step 13, the extended details of the event indicate what the proceeding action is what must be performed and which user should perform it. Step 14, the proceeding action is then correlated with the library of automation scripts to identify the logic to be executed for the next step. Step 15, the current user is logged out of the test system 100 and the login page is again displayed. Step 16, the next user assigned the task has their password reset to another random set of characters. Step 17, the user and password are used to log the second user in the process flow onto the target system 110. Step 18, the second system screen is displayed and the second action in the script is performed as defined in the process test script library Step 19, the requisite data for that screen is entered through the process of mapping what was entered by the user for the second screen to the controls on the second screen, again using the test script library. Step 20, this process is repeated until all steps in the process have completed.

It will be understood that what has been described herein is an exemplary system for testing a workflow. While the present teaching has been described with reference to exemplary arrangements it will be understood that it is not intended to limit the teaching to such arrangements as modifications can be made without departing from the spirit aid scope of the present teaching.

It will be understood that while exemplary features of a test system in accordance with the present teaching have been described that such an arrangement is not to be construed as limiting the invention to such features. The method of the present teaching may be implemented in software, firmware, hardware, or a combination thereof In one mode, the method is implemented in software, as an executable program, and is executed by one or more special or general purpose digital computer(s), such as a personal computer (PC; IBM-compatible, Apple-compatible, or otherwise), personal digital assistant, workstation, minicomputer, or mainframe computer. The steps of the method may be implemented by a server or computer in which the software modules reside or partially reside.

Generally, in terms of hardware architecture, such a computer will include, as will be well understood by the person skilled in the art, a processor, memory, and one or more input and/or output (I/O) devices (or peripherals) that are communicatively coupled via a local interface. The local interface can be, for example, but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the other computer components.

The processor(s) may be programmed to perform the functions of the method as described above. The processor(s) is a hardware device for executing software, particularly software stored in memory. Processor(s) can be any custom made or commercialy available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with a computer, a semiconductor based microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device fcr executing software instructions.

Memory is associated with processor(s) and can include any one or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, memory may incorporate electronic, magnetic, optical, and/or other types of storage media. Memory can have a distributed architecture where various components are situated remote from one another, but are still aessed by processor(s).

The software in memory may include one or more separate programs. The separate programs comprise ordered listings of executable instructions for implementing logical functions in order to implement the functions of the modules. In the example of heretofore described, the software in memory includes the one or more components of the method and is executable on a suitable operating system (O/S).

The present teaching may include components provided as a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, the program needs to be translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory, so as to operate properly in connection with the 0/S. Furthermore, a methodology implemented according to the teaching may be expressed as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedural programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, Pascal, Basic, Fortran, Cobol, Perl, Java, and Ada.

When the method is implemented in software, it should be noted that such software can be stored on any computer readable medium for use by or in connection with any computer related system or method. In the context of this teaching, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. Such an arrangement can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. Any process descriptions or blocks in the Figures, should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, as would be understood by those having ordinary skill in the art.

It should be emphasized that the above-described embodiments of the present teaching, particularly, any "preferred" embodiments, are possible examples of implementations, merely set forth for a clear understanding of the principles. Many variations and modifications may be made to the above-described embodiment(s) without substantially departing from the spirit and principles of the present teaching. All such modifications are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.

While the present teaching has been described with reference to exemplary applications and modules it will be understood that it is not intended to limit the teaching of the present teaching to such arrangements as modifications can be made without departing from the spirit and scope of the present invention. It will be appreciated that the system may be implemented using cloud or local server architecture. In this way it will be understood that the present teaching is to be limited only insofar as is deemed necessary in the light of the appended claims.

Similarly the words comprises/comprising when used in the specification are used to specify the presence of stated features, integers, steps or components but do not preclude the presence or addition of one or more additional features, integers, steps, components or groups thereof.

Claims

Claims 1. A computer-implemented method of testing a workflow process, the method comprising operating a processor to: provide a test module which is in communication with a target system where the workflow process resides, associate a plurality of pre-codified test scripts with the test module; each pre-codified test script is configured for testing a corresponding event; configure the test module to extract a plurality of events from the workflow process, match the extracted events with the pre-codified test scripts, retrieve the pre-codified test scripts which match the extracted events; and apply the pre-codified test scripts to the workflow for testing thereof.
2. A method of claim 1, wherein a test data set on the target system is accessed by the test module.
3. A method as claimed in claim 2, wherein a test scenario is created which includes data derived from the test data set.
4. A method as claimed in claim 1 or 2, wherein the test module is configured to execute the test scenario on the target system to generate test results.
5. A method as claimed in claim 4, further comprising associating expected results with the test scenario.
6. A method as claimed in claim 5, further comprising comparing the generated test results with the expected results.
7. A method as claimed in claim 6, further comprising providing an indication on whether the generated test results deviate from the expected results.
8. A method as claimed in claim 7, wherein the indication includes indicia representative of a pass or fail.
9. A method as claimed in any one of the preceding claims, further comprising providing a status module for providing a reakime visually perceptible representaon of the test case during execution thereof.
10. A method as claimed in any preceding claim, wherein each event of the workflow process is assigned to one or more users.
11. A method as claimed in claim 10, wherein the test module identifies one or more credentials associated with the one or users to whom the next event in the workflow is assigned to.
12. A method as claimed in claim 11, wherein the test module extracts thepre-codified test scripts based on the data associated with the next event in the workflow process.
13. A method as claimed in claim 11 or 12, wherein the users assigned to respective events of the workflow have an associated username and/or password.
14. A method as claimed in claim 13, wherein the test module is configured to reset the user password to a nominal password.
15. A method as claimed in claim 13, wherein the test module is configured to reset the user password to a random character password.
16. A method as claimed in claim 1401 15, wherein the username is contained in the test data set.
17. A method as claimed in claim 14 or 15, wherein the username is retrieved by the test module interrogating the test system.
18. A method as claimed in claim 15, wherein the test module is operable to log into the target system using the username and a random character password.
19. A non-transitory computer-readable medium comprising instructions which, when executed, cause a processor operating a network node to implement the method as claimed in any one of claims ito 18.
20. A system for testing a workflow process, the system comprising: a test module in communication with a target system where a workflow process resides, memory for storing a plurality of pre-codified test scripts which are associated with the test module; each pre-codified test script is configured for testing a corresponding event; a processor for executing the test module to extract a plurality of events from the workflow process, the processor being further operable to: match the extracted events with the pre-codified test scripts, retrieve the pre-codified test scripts which match the extracted events; and apply the retrieved pre-codified test scripts to the workflow for testing thereof.