Codeless Web testing: a keyword-driven example with Excel

© 2020 Maveryx srl.
All rights reserved.
Codeless Web testing:
a keyword-driven example
with Excel
Alfonso Nocella

Summary
• Benefits;
• Limits;
• Challenges;
• The Idea;
• A Keywords-driven Example;

Saving Time: less time to execute tests and improved
communication with other departments
Reducing Costs: fewer resources are spent on testing
Improving Functional Coverage: using saved time to
improve test coverage
Faster Time to Market
Benefits (1)

Reusability of Test Suite: once you have defined your
suite, it’s very straightforward to reuse tests
Improved Accuracy: automated tests produce the same
result every time
Faster Feedback Cycle: without automation, feedback
for newly developed features can take a while
Less Stress on QA Team
Benefits (2)

GUI ID are not fixed or consistent: missing GUI element
IDs, IDs dynamically updated and in general frequent
changes in ID are quite common
Dynamic Contents: GUI or content of the application
changes too frequently resulting in changes of locators
and thus failures of the scripts
Compatibility issues: when executing test scripts in
different browsers.
Limits (1)

Synchronization Issues: many times elements take
time to load because of the application structure,
network bandwidth, etc. If web elements are not
founded timely during script execution, the test fails
How much to Automate: automating everything can
become a pain later in maintenance and execution
Learning curve: test automation tool know how and
programming skillset of the team
Limits (2)

Following we will challenge some of those limits:
• GUI ID are not fixed or consistent and Dynamic
Contents are typically challenged by creating and
mantaining maps, object repositories, etc, or by
Instrumenting the AUT code
• Compatibility issues are generally challenged by
creating and maintaing different test suite or test data
sources
Challenges (1)

• How much to Automate: to reduce maintenance very
often some functionality have to be tested non
automatically or not 100% automatically
• Learning curve: generally to reduce the know how time
acquisition and involve all the tester team, even non
programmers, generally a record and playback
approach is preferred to other, introducing statical
artefacts
Challenges (2)

• Creating and maintaining test artefacts (maps, objects
repositories, recordings, etc…)
• Instrumenting the AUT (Application Under Test) code
• AUTs in different technologies and different browsers
Challenges (3)

The Idea
A technology able to operate as a person
– no artefact
– no code instrumentation
– no programming skills.
A technology able to test AUTs from design
– no matter the development technology
– no matter the execution environment

 No GUI Maps or Object Repositories
 No pre-recording or UI element capture
 No AUT code instrumentation
 No programming skills needed
 Recognition of objects in the User Interface by Images
Inspection «On-The-Fly»

Codeless Testing
• No programming skills are needed;
• Easy to learn and use;
• Promotes an improved functional coverage;
• Favours the participation of all the stakeholders;

The Maveryx Test Automation Framework
innovates automated testing for:
 Functional Testing
 Regression Testing
 Keyword-Driven Testing
 Data-Driven Testing
 Continuous Integration
The Framework

Create and run a keyword-driven test
1. Create a Maveryx Web AUT Launch File
2. Write the test case
3. Run the test

To execute a Web Application-Under-Test it is necessary to
create the related AUT launch file.
Web AUT Launch File
Set the path of the browser
you want to use for your tests
Set the URL of the AUT

Create and run a keyword-driven test
1. Create a new Maveryx Test Project
2. Write the test case
3. Run the test

The Sample AUT

Test Case : TC_01
1. Start the Application
2. Enter valid username
3. Enter valid Password
4. Click “Login” button
5. Check the results: Hi "username”
6. Click “OK" button
7. Close the Application
Test Case #001

7. Close the AUT
5. Check the results
4. Click "Login" button
3. Enter Password
2. Enter username
1. Start the AUT
Close
Has_Text
Click
Set_Text
Start
Keywords
Test Case
Identify Keywords

Test Case : TC_01
5. Check the results: “Hi
alfonso”
Keyword Data / Input Description
START AUT lauch file path Launch the AUT
Design Test step 1

Test Case : TC_01
alfonso”
Keyword Data /
Input
Description
SET_TEXT Text Set the text into a text field
Design Test step 2 & 3

Test Case : TC_01
alfonso”
Keyword Data /
Input
Description
CLICK Click the button
Design Test step 4

Test Case : TC_01
alfonso”
7. Close the Application Keyword Data /
Input
Description
HAS_TEXT Text Check whether the given
LABEL has the actual Text
Design Test step 5

Test Case : TC_01
5. Check the results:
“logged in”
Keyword Data /
Input
Description
CLICK Click the button
Design Test step 6

Test Case : TC_01
5. Check the results:
“logged in”
Keyword Data / Input Description
CLOSE Close the AUT
Design Test step 7

a. Create a new object
KeywordDrivenTestManager
b. Call the method run()
specifying the path of the
Excel file
Create the Driver Script

1. Click on the test class or package you
want to run
2. Select File → Run As → JUnit Test
Run a Test Script

Alternatively
By command line KeywordDrivenTestingCLI with the following arguments:
For example:
KeywordDrivenTestingCLI –o "C:Report" "C:Testtest001.xls"
The test script C:Testtest001.xls is executed and the test report is stored
in C:Report
Or:
KeywordDrivenTestingCLI –o "C:Report" –e
"C:Testtest001.xls " "C:Test"
All test scripts in C:Test (including subfolders) are executed except
C:Testtest001.xls and the test report is stored in C:Report

Thank you
alfonso.nocella@maveryx.com

Codeless Web testing: a keyword-driven example with Excel

Recommended

Recommended

More Related Content

Similar to Codeless Web testing: a keyword-driven example with Excel

Similar to Codeless Web testing: a keyword-driven example with Excel (20)

More from Maveryx

More from Maveryx (7)

Recently uploaded

Recently uploaded (20)

Codeless Web testing: a keyword-driven example with Excel