Script-less Automation Testing
Test automation can be categorized into:
· Scripting
· Script-less
· Advanced automation using AI
With the arrival of Agile and DevOps the manner we write and test software has severely transformed. Regular releases have become a must to maintain the progress at the same speed in a progressively competitive atmosphere. The necessity for automated testing is immediate, but the route to test automation has an explicit set of expertise which are traditionally mandatory and comes at a heavy cost with reference to writing scripts and the efforts in maintaining them.
Working with the uncountable and frequent sporadic issues among operating systems and the web browsers where test execution has directed many of us into circles of trial and error when things are not working as expected. For instance, as soon as an element on a page is moved/ changed or when a new feature is included which results in numerous broken tests, we identify affected scripts and update them manually.
What if we generate automated UI tests without scripting them manually by hand?
Tools for ‘Script-less’ testing
A Script-less Test Automation platform should allow the test scripts to be:
· created in a smart “no-code” manner
· executed in different devices and operating systems without interruptions or breakings
· exported in a standard way in order to avoid lock-in by vendors (The best example is how Appium exports the test scripts in mobile testing)
In addition, a script less test automation tool should provide the features to create tests including:
Create test steps of the test cases,
Store elements which can be reused,
Record the test cases,
Execute test cases in different versions of operating systems and web browsers,
Execute the tests both locally and remotely (cloud based), to handle the differences or conflicts of test data, to generate reports on test results and integrate with the other tools which are being used.
Below are some examples of script-less automation tools which can be used in mobile testing.
Let’s look at the high-level architectural components of a Script-less Automation Framework.
Test Input Interface: This is the front-end module which is from the point of view of the customer. This is the place that the testers could enter all the test inputs. Few examples: test conditions, steps of the test case, test data, expected results, etc.
Test inputs should be provided in order to execute the tests. These test inputs would be defined by the framework engine. Test inputs can be in different file types (Excel, XML) and test schemas such as test steps, test data fields, data types, etc. would also be defined by the framework engine.
The consumers have the ability to provide the test details for the relevant text fields via GUI for each test execution. Visual editor-based inputs such as flow charts are also a possible method for the consumers to provide test inputs which supports logics such as loops and conditions. As a matter of fact, although it takes more time to develop such interfaces this method has become the most trending method to enter the inputs.
Framework Core Engine: The central component of the script less automation framework is the Framework Core Engine. This does the main heavy tasks of the validations, automation logic, interfaces to the other framework components, etc. In addition, this supports to third-party apps/scripts for customized test configurations and executions as well. The action handler gets all the test inputs to process the actions on the AUT (Application Under Test). Choosing the correct technology and programming knowledge to develop this engine is a must.
Test Output Interface: As the name itself suggests this specific component is created to output the test logs, results, reports, defect logs, dashboards, etc. The results which are being forwarded from the framework’s core engine comes to the output logger and is then exited by the Output interface.
When scripting or defining a test case, we focus on “how it needs to happen”. Instead, in script less tools you would identify “what needs to happen”. For example, you might search the action “Click” and then identify what you need to click. You might have to fill out some text fields on a page, simply say which values to type in each text field on the page, that’s it! No need to wait for the elements to be visible on the page, to define the csspath/ xpath in order to locate the page elements or to focus on input fields. What you need to do is, clearly describe each step of the test case clearly.
Let’s focus on a simple example to get an idea of how the script-less automation works.
1. Openwebpage
2. Enter User in the Username field
3. Enter Password in the Password field
4. Click Login button
Each of the above are keywords that are supported by Script-less frameworks.
Openwebpage “www.gmail.com”
Enteruser testuser
Enterpassword testpwd,mask=true
Click Login
Openwebpage, Enteruser, Enterpassword and Click are the keywords which accept arguments in order to perform actions. The keyword Enterpassword accepts 2 arguments.
Benefits of Script-less Test Automation
· Programming skills are not a mandatory requirement for the testers.
· The framework can be extended for the use of not only the testers but also the product owners and business analysts. User Acceptance Tests (UAT) can also be executed using this framework.
· Since the automated tests can be developed quicker this framework is an acceptable fit for the Agile process.
· This framework is flexible in a way that both advanced and native users can work.
· The time we usually spend on fixing and debugging test related issues can be reduced. The reason for this is, this framework is tested thoroughly, so there are less ‘test’ related errors.
· The effort we put on maintaining the overall automation suite would be less.
Myths About Script-less Automation
Script-less Test Automation Framework is 100% script-less: This is not 100% correct. It is not practical to achieve the target of making the tests 100% codeless.
Testers do not need programming knowledge or skills at all to use Script-less Test Automation Framework: This fact is not 100% correct when it comes to the practical world. Basic programming and logical knowledge skills are needed. For instance, in order to test mobile or web-based applications, the testers require knowledge about the classes and objects to some extent as it is included in the customized scripts.
There are few tools which support features such as drag and drop and Quality Assurance engineers are not required to have a knowledge on programming. Ex: TestCraft
Can rely on record and playback completely: This not true at all. Record and playback outputs a working script with flows and value inputs which are hardcoded and can be customized later.
Conclusion
Building a script-less automation framework is a challenging as well as an interesting task. These frameworks can be created to test different types of applications such as mobile apps, web-based applications, GUI, web services, database, etc. In order to build a reliable, stable and high-performance script-less automation framework, it mandatory to select the correct programming language and technology.
References
https://www.blazemeter.com/blog/what-is-scriptless-testing
https://www.cigniti.com/blog/script-less-testing-myths/
https://www.softwaretestinghelp.com/scriptless-test-automation-framework-tools/#more-48549
