In this article you will know some of the test automation best practices we recommend for Oracle Functional Testing of Oracle Application Testing Suite (a.k.a OATS).
Best practices for test automation with OATS are typically identified from the test engineer’s experiences and challenges. In a real time scenarios,for example: situations where multiple teams work on similar kind of test automation tasks, team(s) might want to know the guidelines or methodologies in peer teams, as they might have observed following which have helped them attain better results and success rate.
Please find below:
Best practices for test automation in Oracle functional testing of Oracle Application Testing Suite.
Covering in the areas of :
- Script Naming
- Scripting / Stabilization
- Script Execution
- Script Settings
Script Naming related best practices
|1||Script name should contain only alpha numeric characters without any special characters except “_”||To avoid unexpected errors by Openscript with special characters in a script name.|
|2||Make sure the script name is short, meaningful an less than 60 characters in total||Sometimes, Openscript might through errors to execute scripts for which the length of script name is more than 60|
Assets related best practices
|3||Try to avoid calling multi level child scripts.||Might cause some instability issues when dealing with databanks and for multiple iterations|
|4||Any re-usable assets attached, most likely have them relative to repository unless they are present inside a script folder||Helps for easy script movements from one location to another without export and import processes.|
|5||Try not to use java classes for re-usable methods or libraries as much as possible, unless for special cases.||This might need little technically skilled people and also some times Openscript might throw Object cannot be resolved error.|
Scripting related best practices
|6||Avoid index attributes to identify objects for web applications for all UI components except for document and form.
In case you are recording the scripts, try to make these index attribute removal for desired UI components in object identification for Recording > Web Functional
|Most of the times the scripts will fail if index attribute is present the list of attributes used to identify an UI component in XPath|
|7||Change all waitForPage(null) statements to waitForPage(200,true) in case you are stabilizing a recorded script.
Here 200 is an example, you can have a global variable in case you want to use across different scripts and be maintained from single place.
Or if you are writing scripts without recording, please make sure you use waitForPage with 2 parameters and 2nd parameter value to be true.
| Openscript scripts might fail in the places where the page is already loaded faster than the execution speed of script, in these cases OATS may not understand if page is already loaded and expects for the page to load, this will generally cause scripts to fail.
The moment we give true as second parameter, the script will not wait if already the page is loaded
|8||Instead of having think statements in the script, always better to have a waitFor(time) on the target object which are going to perform operation in the next step.||This will reduce the chances of failure of script for different conditions of Application under test, in the sense time taking to load the page or objects refresh in page.
This is also important for the places where AJAX requests are also there.
|9||Any objects or elements if the attributes used for identifying them are not unique / not constant, then it is better to identify those objects based on some label or prompt present near by to it.
i.e. dynamically get an objects based on any label associated to that specific object by using methods like
getElementsByTag, parent, etc..
|Brings more stability in the script as the objects are identified based on the associated labels, especially for the cases where the attribute values to identify an object are changing frequently and not unique.|
|10||Use custom verification points than the checkpoints that can be auto inserted using Openscript IDE||Most of the tool based checkpoints are static and may not work for dynamic content like table data verification. that is data present in a web table.|
|11||In case you are using scripting based test automation frameworks, it is suggested to have shared Object Libraries instead of XPaths being made as part of scripting it self.||If object attributes are part of scripting it self, it might increase the over head of maintenance, if there will be in any changes in objects / unique attribute to identify an object.|
|12||Try avoiding multi level nested looping conditions in the scripts.||It will take more time to identify if the issue for failure of execution is due to a script issue or a functional issue.|
|13||Try creating the scripts simpler and not have too much generalisation to satisfy different scenarios in one test script.||This will create challenges at the time of debugging the scripts or to make any maintenance in the scripts.|
|14||Modularize your scripts to have better re usability||Increases speed of script development as time passes on.|
|15||Try to develop individual scripts which may not run more than 30 mins, avoid as much as possible in having lengthy execution time based scripts.||With shorter execution time period scripts, the stability of the scripts is higher.|
|16||Any values captured from Application under test, try to save those values to physical location(i.e. files) and also print to log or result file to have them for reference.
|Generally when scripts fail in between and you want to continue execution of remaining part, we can assign these values and run the remaining part of the script, which otherwise we might lose the data that got captured in the script execution for resuming the scripts which have stopped abruptly for unknown reasons or some issues.|
|17||Write appropriate info statements at different parts of the script to make them visible properly in the final result file.||Helpful while debugging the scripts.|
|18||Go through your entire application and identify what are the attributes generally used to identify an object uniquely and come up with the list of attributes for each object in the application and circulate to the entire team working on this, so that every would be in sync to use the same.||Brings a standard approach for building a better scripts.|
|19||The cases where we have web tables in the application under test and if we have to perform operation(s) on an object based on values present in other columns, it is better to dynamically find the row in which the values are matching for the respective search columns and then dynamically get the target object from the target column for the same row and perform the desired operation.||Data in web tables are generally dynamic and the order of showing the data in web table will always change based on other transactions in the application under test, by writing logic like with this kind of approach can bring stability in the script.|
|20|| Regularize the attributes in the XPath, which will help to identify the object uniquely without fail.
for example: a web page / window object is identified with a title and the value for this title attribute is “Order Creation 1235”, and this is the only attribute which can help to identify this window object.
So the script might file fail the next time we execute with the same attribute value, but instead if we regularize saying “Order Creation*” then the same script can run without fail multiple number of times.
|Brings better stability in the script for multiple runs.|
Execution related best practices
|21||Have a shared location, where you can store execution results for each cycle w.r.t each test script which were executed during the cycle.
These result folders would be present in each script / Master script. Generally found in this location
Master Script > Results > SessionXYZ
Here session XYZ is something we need to figure out and keep them
|As a general practice people might delete the results post executions once they feel everything is fine, but by doing this we can have a reference any time to go back and check on need basis.|
|22||Have a practice where a script would be stabilized by one person and have another person in the team to run the same script for 3 times, out of which it has to pass at least for 2 times.||You can get better confidence on the script that every thing is working fine, which is also called as dry runs.|
Settings related best practices
|23||Based on the need if you want to have multiple child scripts to run irrespective of whether the execution of previous child script fails or passes, we need to have this setting saying continue executing the child script in the Openscript Settings.||Helps to continue to run scripts in unattended mode,there by can run scripts at the night times and can check the status of all scripts in the next day morning start doing the failure Analysis.|
|24||Enable the setting in Openscript to take screenshot on any script failure.||This will help speeding up the Execution failure analysis, especially when having the nightly / unattended script executions.|
In case of any queries, kindly reach to us through comments and we would be more than happy to help you.
Founder of TestingTools.co, constantly shares knowledge on different test automation tools. Has experience in building proof of concepts, solutions, frameworks, platforms & implementation of test automation projects.
In pursuit of building a platform with inbuilt framework and reusable components for Oracle Cloud applications ( Oracle HCM, CX, SCM, Financials clouds, Salesforce and other cloud applications )
Major accomplishments in his career:
- Product architect and development manager for test automation platforms
- Oracle Flow Builder @ Oracle
- CloudTestr @ Suneratech
- 2 times to oracle open world
- More than 20 successful POCs ( Proof of concepts )
- 100 demos
- Designed pricing models.
- Trained more than 50 members.
- Built more than 100 re-usable functions.
Worked with tools: