Process automation is now a well-known concept in digital transformation. It allows technology to automate complex business processes and increase service quality and contain cost. How does process automation fits into test automation for application testing? Is it going to make a difference?
Test Automation is about automation of test cases. If you dig deeper, the objective of application testing is to test the business processes in an application with multiple scenarios. So, you are basically testing the business processes. There is huge opportunity to leverage process automation in test automation and rip a lot of benefit from the approach. It can be a game changer in your automation strategy.
Let’s elaborate how we can adopt the process automation model.
Test case can be broken up into four parts – Pre- requisite, Action script, Test Data and Validation
Pre- requisite – The state of the application or data set up that is required before a test case can be executed.
Action scripts – It comprise of the steps in a test case covering actions the test needs to perform on the application.
Test Data – The data that needs to be entered to execute the test case.
Validation – This is to verify the outcome of the test against expected results.
We can focus on each of the area and see how we can use the process automation approach to cover them.
Adoption of process automation
Pre- requisite -Most of the time, pre- requisites are business processes itself. These are business process that needs to be executed before the test can be executed. For example, in banking application if you need to run tests related to bank account one of the pre- requisite would be to have the accounts being set up in the application. The account creation is a business process itself. You can automate the process of account creation and call the process automation to set up the pre- requisite in this case. All the tests that require the account creation can call the same process automation and execute with various data set as needed.
Action script – The steps that user would have executed to run a business are the action scripts of your tests. Action script is basically a business processes itself. You can automate the process and can keep calling the same process automation to run all your tests rather than creating separate scripts based on test cases.
Couple of features that you must keep in mind while building the process automation for action scripts:
1. Isolate any test data from process automation. Test data should be entered from external source (like how you would build your data driven tests from data file or database)
2. Process automation should cover all the possible path or flow variations that the application can take in a business process
3. You should add the feature in your process automation to be able to run the process with start and stop anywhere in the business process so long your application supports that. This is the most complex part of designing the process automation when you want to use process automation in test automation.
Each of the action script of your test suite may have a different start point and end. Unless you can use process automation to support that, you won’t be able to integrate process automation to test automation. There are approaches that can be adopted to build the feature, if you are interested to know more on these approaches, let me know. Once you implement the feature all your test cases can run the same process automation instead of running separate scripts for each test case.
Test Data – Test data should be completely externalized while designing the process automation. You should be able to pass the data from external source to the process automation. Process automation would be taking up different flows in the business process based on the data entered.
Based on the test cases you would need to set up the test data and pass it to the process automation. To make automation more accessible and adoptable for teams without automation knowledge design the test data set up process in way that anyone in the project can use it.
Validation – The last but not the least, the validation steps may be different in each test case in a test suite. The underlying business process may be same but the validation step may be unique for the test case.
There are two approaches to address it:
1. You can run the test using process automation till the validation step and cover the validation step manually. It will still be a big-time saver to use automation to cover all the steps by automation prior to validation.
If your application allows you to save the business process till the point it is executed and pick it up later from previous end, then through process automation run till the step before validation and save it. Then manually go in and verify the output from the saved automated run.
If your application allows you to save the result in dashboard or file or data base, then let process automation save the information in dashboard or file or database and you can verify the result manually later.
2. The second approach is to find a pattern within the validation types in the test suite and group them based on commonality. If you can group them into a reasonable number of common validation types, then you can create a validation method for each of the type and call them dynamically based on the test case. But if each test case has unique validation this approach will be hard to implement.
Steps to implement process automation for test automation
Here are the steps to create Process Automation and then build test automation using the process automation.
1. Analyze your test suite to find the number of business processes to cover for pre- requisite and action scripts
2. Create a common strategy for test data set up
3. Analyze the verification methods in the test suite and see if you can come up with group of verification methods based on commonality.
1. Develop one process automation for each process in pre- requisites and the action scripts
2. Develop a test data set up process
3. Develop a library of verification methods that can be used dynamically based on the test case
Process Automation mapping to test case
1.Map the pre- requisite to business process automation based on the test case
2. Map the action script to business process automation based on the test case
3. Set up data in the external data source
4. Map the verification method based on test case or plan on manual verification based on which ever approach works best.
How is process automation based automation different from data driven approach ?
Don’t confuse this approach with data driven approach. Process automation based test automation is much more than just data driven automation. Here through minimal set of automated scripts you are not only covering all your data variations but also all the flows that business process can take.
What are the limitations?
So far based on the implementation I have worked on, here are couple of scenarios which can be hard to implement.
1. If the test case goes back and forth between steps in the business process, it would be hard to implement process automation. Process automation will best fit for test cases where the test case flow is only in one direction for steps in the business process.
2. If the number of path variations in a business process is too many, it would be hard to handle it through process automation. It would need much more analysis to design the process automation and sometime may be hard to fit into single process automation.
Benefit of adoption of process automation
1. This approach is a huge time saver when you have several test cases which can be covered under same business process. Instead of creating one script per test case you are creating one script only. Development effort is significantly lower than test case based automation.
2. Maintenance is an area where we struggle most in automation. This approach lowers the maintenance effort significantly as you would mostly need to modify in one business process script for application changes instead of changing in a number of test script in test case automation approach.
3. Stability and predictability of the automation execution will be significantly higher as you are running the same script for all the test cases rather than running separate script for each test case.
4. It allows you to expand automation test coverage fast once the process is automated. Setting up a new test case is only about setting up the test data for it. No new script development is needed. So, expanding the automation coverage become faster than traditional models.
5. As you have already automated the business processes and all you need is to run the tests, is to set up the data, other teams – business, development etc. can also leverage this process to run customized automated tests based on their need and keep varying the data to fit their need.
6. Once you have developed process automation, it can be used beyond testing as well. One of the major benefits of process automation is, they can be used for robotic process automation as well for business process automation
Overall process automation is based on test automation to optimize your entire automation and test strategy and make automated test easy to set up and more accessible to various teams in the project. It is an excellent way to expand automation test coverage fast without having to worry about separate script development and maintenance effort for each test case.