WORKLOAD AUTOMATION COMMUNITY
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
    • IWA 9.5 Roadshows
  • About
  • Contact
  • What's new

TESTING HCL WORKLOAD AUTOMATION WEB UI USING HCL ONETEST UI

12/20/2018

0 Comments

 
Picture
Developing a Web UI Test Automation battery is usually a challenging project. By nature, a graphical interface of any product tends to evolve and change very quickly, not only to offer the users new features, but also to improve the look and feel of the application. The continuous restyling of web pages is typically reflected in unsustainable Web UI Test Automation code maintenance costs: the frequent rework of the developed test scenarios is driven by failures and analyzing the last test automation execution report consists in a “hunt for defects”. 
​

Test scenarios are not only difficult to be coded, but they often prove to be false positives, failing because of non-functional reasons but for the fragility with which the tests are developed. This is critical in terms of a substantial loss of confidence in the results of automatic execution. ​​

However, our team has invested time and resources in the automatic test, consolidating over the years an
 approach that is firmly part of our DevOps life-cycle. Different suites daily test the functional aspects of the various flavors of the product, its Rest APIs, its installation procedures and its performance, but it’s also provided a test automation of the Web UI. Automatic scenarios don’t replace manual test (which is fundamental and indispensable) but every day check that the new code does not destabilize the existing functions of the application, repeating boring operations and allowing the team to test the graphical interface in new and more complex scenarios. 

In this context, Workload Automation 9.5 (whose release is currently planned for 1Q 2019) represents a real challenge due to a complete restructuring of its graphics: a new dashboard will be introduced, the menus will be re-organized, a way to customize the pages will be proposed ... Such radical changes would not have been easily absorbed by the Web UI test automation framework used so far, for a set of reasons: 

  • The re-factoring process (based on manual interaction with browser) would have been too onerous, time consuming and error prone 
  • The tests would have been carried out in a rigid and text-based development environment (not very intuitive and difficult to document)
  • The framework would have shown instability during execution (amplifying the number of false positives)
  • The tool would prove unsatisfactory for the needs of a complex Web UI such as the Workload Automation’s

Motivated by all the above considerations, the Workload Automation Test Team decided to get back on the market to identify the tool that can best fit its new requirements. After an analysis of the various alternatives, the choice fell on HCL OneTest UI. The tool, belonging to the same Workload Automation HCL portfolio, proved to be a convincing solution, capable not only of overcoming the limits of the previous framework but also adding value to the entire suite. The aspects that represented an advantage over the competitors are mainly the following: 

  1. HCL OneTest UI offers the possibility to record the interactions with the web page under testing, associating to each action a navigable screenshot of the DOM. 
  2. The framework is an integrated solution that allows centralizing the management of Rest API calls, functional interactions and performance checks. 
  3. The tool expects to compose the scenarios in its user interface, without having to write Java code (which is auto-generated starting from the description of the actions to be performed on the web page). However, it’s possible to insert fragments of "custom code" into the scenarios, offering users with programming skills to extend the capabilities of the tool to manage complex test situations. 

However, the true added value of the new Web UI Test Automation project based on HCL OneTest UI is the “quality-oriented approach” adopted. Based on the experience of the team, we chose to follow, during the construction of the test scenarios, a set of best practices and conventions to enable important qualities, typical of code development project, but capable of giving value also in a context of test automation one. HCL OneTest UI is the tool that has best responded to this type of needs. 

BEST PRACTICES / A MODULAR APPROACH REALIZING TEST SCENARIOS 
HCL OneTest UI is based on the concepts of:  

  • Test 
  • Compound Test (proposed as Test containers, in which it is possible to organize the execution flow). For more details about Compound Test definition, see the following link. 

​We have decided to apply these two concepts in the following way:  
  • As a Compound Test, we have identified single end-to-end scenarios, executable by a Workload Automation user with an appropriate profile. 
  • As a Test, we have identified a single atomic interaction with the Web UI. 

And we were able to achieve an important level of modularity for the Test Automation project. As documented in the following images: 
Picture
Picture
The "Login" Test is used in different Compound Tests. This way of structuring the scenarios improves the degree of modifiability of the entire project. In fact, if the login procedure should be modified (or more likely, its graphical interface should be re-styled), the tester should refactor only the "Login" Test and not all the Compound Tests that use it. 

Then, the tests become reusable even in completely new scenarios. When the project reaches a certain maturity (and in the Test library it is possible to choose from a wide range of already recorded interactions), developing a new scenario consists in composing and reorganizing already available "modules": it will be necessary to record only new interactions, with a substantial reduction in development and code-maintenance time. 

SELF CONTAINED SCENARIOS 
Each end-to-end scenario provides (one or more) tests which can verify if a particular functionality, object of the test, is working in the expected way. Each scenario is designed to be minimal, therefore corresponding to a single behavior to be tested. 

Regardless of its outcome (of success or failure) each test is self-contained: its eventual failure does not depend on the outcome of the previous tests, nor its result does not impact the execution of the subsequent tests. It’s a good practice to structure each end-to-end scenario, placing a block of setup (in which the test scenario is prepared) and concluding the scenario with a set of teardown procedures (with which it’s ensured, regardless of the results of the test, the resulting environment is identical to the existing one before execution). 

To implement this concept in HCL OneTest UI we used: 

  • (tests of) Rest API, useful for quickly creating (and deleting) the "objects", even complex ones, with which it was necessary to interact in each specific scenario, 
  • the Verification Points, useful for determining the outcome of the test in an accurate manner, not limited to verifying the return code but verifying that the contents of the various interactions with the application were indeed those expected. 

A Compound Test structure following this set of best practices is presented as follows: 
Picture
In compliance with these best practices, each scenario can be executed at any time, without having to respect any rigid order. Debugging failed scenarios also turned out to be simpler and faster. 

DATA DRIVEN TESTING 
HCL OneTest UI allows to store data in Datapool, tables whose values ​​can be used during the execution of the scenarios. 

It’s evident that data can be used for checks (and then used by Verification Points). For example, in our case, it was necessary to verify that the object initialized with the Rest APIs was correctly displayed on the Web page. It’s less evident how this functionality can have implications also in terms of quality. By structuring the tests to make them exposing variables, it is possible to generalize different interactions in a single test: it is sufficient to adequately initialize the variables within the Compound Test to change their behavior.  

An example of this use of the Datapool could be the following. In 2 scenarios, the same Test is used to click on 2 different "objects" basing the interaction on the value with which the JSName variable is initialized: 
Picture
Picture
The benefits are relevant: 
  • reusability of the tests is improved 
  • need for duplicate code is limited 
  • cost of modification and maintenance is minimized 
 
LIMIT THE USE OF DELAYS 
A concrete problem of Web UI testing is that the interactions with the elements used during any scenario are never instantaneous: this means that after clicking on a button, after closing a pop-up or simply after changing the active page the effects of the actions cannot be verified immediately. It is evident that in an automatic execution context this problem is even more decisive. 

Since the update time of the page is not predictable a priori (it may depend on countless factors, such as network delay, the load status of the machine at a given time, the complexity of the calculation that must be performed ...), using delay with a predefined waiting time is a highly-discouraged practice to solve this type of problem. 
​

Once again, the solution we adopted is based on Verification Points. Using them in a clever way, the tester can force HCL OneTest UI to wait for a certain element to be visible on the page:
Picture
Obviously, the element must be significant in terms of completing the operation and the maximum time (chosen as a timeout beyond which the action must be considered as failed) should be chosen in a pessimistic way. 

It is important to remember that the use of delays must not be banned at all: there are situations in which forcing the execution of the test to stop for a fixed amount of time is essential. In our case, for example, it is needed to wait some time for the WA engine to complete operations on the objects it manages before monitoring their status with the Web UI. 

ELEMENT IDENTIFICATION STRATEGY  
The solidity of test automation scenarios depends strictly on the way the elements are identified by the automation tool. We’ve limited the impact of Web UI rework, basing our identification strategy on the ID (or the “class”) of the HTML elements in the page. In this way, even when the page layout is reconfigured, the test scenarios continue to work. Only in the rare cases in which the developers choose to change the ID of the elements, the execution of the tests shows false positives and requires to be reworked. 

To support this kind of approach, HCL OneTest UI offers 2 ways to browse the objects registered on the page: 

  • Screen capture, with which the tester can graphically identify the element that he wants to interact with. 
  • Elements, with which the tester can explore the DOM to find around the element. This is the most stable way to identify it. 
Picture
Picture
Once the object identification procedure has been chosen, in the screen capture view the tool uses: 
  • red color to highlight an element if the identification is unique, 
  • yellow color to highlight different elements if the identification needs to be refined 
If the test stops working due to a change in the page, the tester has only to register its latest version and choose another method of identification. This code maintenance step can be simplified by a feature that has been added in one of the latest versions of HCL OneTest UI: the Guided Healing. 
 
CODE ORGANIZATION 
HCL OneTest UI gives the tester the possibility to organize artifacts in directories. At first use, this procedure may seem like only a way to distinguish between several types of objects: Compound tests, Tests, Datapools ... 

But this functionality can concretely increase reusability of the already registered tests (thus avoiding the duplication of the code). We have chosen to organize the artifacts closely following the different functional areas of our product: administration, design, monitoring, reporting ... We have grouped the tests from a logical point of view: interactions with Jobs, Job Stream, Calendars… 

The result is a structured and navigable project that facilitates the identification of available tests (also thanks to the choice of "speaking" names). 
Picture
PORTABILITY OF THE PROJECT 
The quality of a test automation project also depends on the simplicity with which the execution: 
​

  1. can be directed to a particular test environment (in our case towards a certain Web UI and a certain Engine), 
  2. can be moved to a particular execution machine (in our case a machine on which HCL OneTest UI was installed). 
​
In this regard, it was necessary to consolidate few modification points, to prefer configuration files to hard-coded string and to structure the execution on a parameterized and flexible Jenkins-based architecture. However, these aspects deserve to be treated and analyzed separately in a different blog. 

CONCLUSIONS 
With this approach, in the last 4 months we were able to finalize the porting of the entire automatic suite implemented in the years with the framework adopted so far. Moreover, HCL OneTest UI helped us to achieve 35% increase of the suite’s coverage with new test scenarios. With more than 600 testsuites already recorded, the team has a stable library of basic operations: at operating speed a new scenario can be added to the suite in the order of hours.  

The suite has been implemented to be executed on the different flavors of the Web UI with low configuration cost. At the moment, the Web UI Automation Project counts 175 end-to-end scenarios and it runs daily as soon as the latest build of product is ready. So far, the automation process highlighted more than 40 defects during the development cycle of the product, and it will be really helpful in the next future while the team will be involved in the SVT activities.
 


Picture
Ciro Oliviero
Software Engineer
​
Ciro is involved in Web UI test automation, as member of Workload Automation test team.
Ciro graduated in Software Engineering at Roma Tre University and works in the HCL Products and Platforms Rome software development laboratory.
Picture
Maria Teresa Caira 
Senior Software Engineer
​
Maria Teresa is a Software Engineer with a long standing experience in software development. Currently Maria Teresa works as Software Test Engineer in the Workload Automation team, where she takes the ownership of Dynamic Workload Console Test Automation project. Maria Teresa has a University Diploma in Computer Science and she is currently based in the Rome Software Development Laboratory HCL Products and Platforms.

Picture
Giorgio Corsetti
Technical Architect 

Giorgio works as Performance Test Engineer in the Workload Automation team. In his role, he works to identify bottlenecks in the architecture under analysis assessing how the overall system works managing specific loads and to increase customer satisfaction providing feedbacks about performance improvements when new product releases become available through technical documents publications. Starting from April 2018 he added a new responsibility covering the role of Test Architect for Workload Automation Products family. Giorgio has a degree in Physics and is currently based in the HCL Products and Platforms Rome software development laboratory
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Archives

    March 2023
    February 2023
    January 2023
    December 2022
    September 2022
    August 2022
    July 2022
    June 2022
    May 2022
    April 2022
    March 2022
    February 2022
    January 2022
    December 2021
    October 2021
    September 2021
    August 2021
    July 2021
    June 2021
    May 2021
    April 2021
    March 2021
    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    June 2020
    May 2020
    April 2020
    March 2020
    January 2020
    December 2019
    November 2019
    October 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017

    Categories

    All
    Analytics
    Azure
    Business Applications
    Cloud
    Data Storage
    DevOps
    Monitoring & Reporting

    RSS Feed

www.hcltechsw.com
About HCL Software 
HCL Software is a division of HCL Technologies (HCL) that operates its primary software business. It develops, markets, sells, and supports over 20 product families in the areas of DevSecOps, Automation, Digital Solutions, Data Management, Marketing and Commerce, and Mainframes. HCL Software has offices and labs around the world to serve thousands of customers. Its mission is to drive ultimate customer success with their IT investments through relentless innovation of its products. For more information, To know more  please visit www.hcltechsw.com.  Copyright © 2019 HCL Technologies Limited
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
    • IWA 9.5 Roadshows
  • About
  • Contact
  • What's new