SPAN’s Testing of Dynamic Applications – Automation Test Solutions

By Mahendra Kumar D, Mohit Verma, Sowmya BS, Awadh Narayan, Poornashree A, and Suprith Rao

It has always been a challenge to automate dynamic applications and objects on the screen that changes its properties and behavior in run-time. In this technical paper, we make an effort to compile different solutions and approaches implemented at SPAN across different situations over the years using different Test Automation tools.

Due to the technological advancements and change in the nature of applications, most of the applications that we test are dynamic in nature. In some of the applications, the screen objects are dynamically created based on the business and configuration rules. 

The reason for this dynamism in the applications is due to one of the following reasons:

• The nature of the application business demands that the web pages/screens or even the objects on the screen to be created dynamically. For instance, in a Content Management System, all the pages that are created are specific to the context. This dynamism poses a challenge for automated testing.
• Dynamism is imposed by the application frameworks on the objects’ attributes such as title, IDs, etc., which are used by the automation tools and scripts to identify them uniquely. This makes the automation scripts fragile, posing a challenge to automate and maintain the scripts. The dynamic IDs usually are of a specific pattern depending on the framework or application logic. This includes auto-incremented numbers, for example, ext-gen-123, treepicker-1038-inputEl, view: _id1:_id2: content. These numbers can change from session to session or from one application version to another, which creates difficulties for object identification.

Depending on the testing tool, application technology stack, pattern of the dynamic objects or the application and other important aspects of the context, there are multiple solutions that can be implemented to solve this problem. Although handling dynamic objects is a common problem that one would encounter during automated testing, it demands critical thinking with required exploration and technical acumen to understand the problem pattern and devise the solution to tackle it.

SPAN has been tackling these problems over a decade with multiple tools and technologies and has a wide variety of unique solutions to address the problem in context. Outlined below are a few example stories that describe the time-tested approaches implemented at SPAN.

Testing Story 1: Automation testing of web application (KendoUI) with dynamically changing object properties

Context:
A Nordic based legacy HR application migrated from COBOL to .NET web application. SPAN provided a solution by developing a migration tool, which does the code conversation from COBOL to .Net technology. The migrated web application is an ASP.NET MVC application with a KendoUI front-end. Dealing with front-end objects at UI automation was a challenge due to the dynamically changing object properties that was changing between sessions.

Automation testing was implemented with Smartbear TestComplete tool. SPAN has successfully handled this challenge by analyzing the pattern of changes in the object properties and using appropriate, regular expressions and strategies described below.

• Issue 1: Not able to select values from Kendo drop down – Month, Year drop down

Solution Approach: The KendoUI date selector object was seen as 3 different objects (textbox area, dropdown arrow, dropdown list) by TestComplete. Select methods provided by the tool, such as SelectByValue(String Value), SelectItem(int Item) etc., did not work and there was no support provided by the tool to select the values from the drop down. Selecting values from this drop down was critical for the test case execution.

Based on the exploration and understanding of the KendoUI framework, we devised a logic for selecting the drop down in an indirect way, using keyboard strokes and implemented it aptly to work for the context that resolved the problem.

• Issue 2: Script failure due to dynamically changing (between sessions) object properties 

Solution Approach: Automation scripts were failing because of the dynamically changing object properties that were changing every time the page was loaded/refreshed. Random numbers were getting appended to the ID property, making our scripts unable to identify the objects on screen.

Using TestComplete Namemaps for storing the object properties would have been a difficult option for the context. We used TestComplete methods - Find(), FindAll() and FindChild() as required by passing the class and object type, creating the automation objects dynamically at runtime based on matching the combination of properties such as inner text/value etc., This way, the created dynamic objects never failed to identify themselves to the automation scripts uniquely, and thus, resolved the object identification problem.

Inference:
In the above context, for Issue 1, there was no tool support for the drop down list selection. Experienced programming skills for the context, solved the problem. In Issue 2, use of alternate functions in TestComplete with pattern matching resolved the object identification problem.

Testing Story 2: Enterprise Automation testing of applications with dynamically changing object properties

Context:

A US based Independent Software Vendor (ISV) sought SPAN’s help for automated testing of their portfolio with about 43 .NET smart client applications. SPAN proposed a framework built by using TestComplete.

Technology used: .Net, Devx Controls and Citrix like environment.

Problem description:
TestComplete tool failed to identify objects and navigate to the required screen for testing as the menu bar and ribbon was considered to one object although it was a group of several objects. For example, we had to take the navigation path QA  QA Testing  Survey Audits to open Audit Survey Report and test. We could not have written multiple lines of codes to navigate to different forms and multiple applications.

Below is the line of code which identifies the above mentioned Survey Audits control in TestComplete. In the code below, there are several dynamic portions that change over time between screens and applications. A few dynamic portions are highlighted.

Sys.Process("CMCLITS.ClientQA").WinFormsObject("frmMain").WinFormsObject("ribbon").SelectedPage.Collection.Item(9).Groups.Item(3).ItemLinks.Item(7).Item.Links.Item(0).Edit.Buttons.Item(1)

Solution:
TestComplete shows the entire application as a single window (inside its object browser tree) without any child windows/controls. SPAN utilized the Microsoft Active Accessibility (MSAA) mechanism and some TestComplete methods such as Find(). FindAll(), FindChild() etc., succeeded in automating all the controls on the above mentioned application. The implementation tackled the dynamic object identification across all the screens and all the applications in the portfolio, making our enterprise automation framework a success.

Testing Story 3: Automation testing of a banking application with dynamically changing objects

Context:
A Norway based client had requirements for automating its electronic signature system used by different customer banks. The application had 2 portals, one for creating signing contracts and sending it to the recipients for signing. The second portal took care of the actual signing procedure.

Creating signed contracts was a stepwise workflow procedure, which was designed in the form of wizards. Each of the wizard pages had dynamic input fields based on (a) the type of recipients that the contract is being sent, (2) the number of recipients and (3) the number of document attachments allowed. Each of the next pages in the wizard was rendered based on the input supplied in previous page. To add to this, the display of controls and the inputs were mandated and configurable by the customer banks. This feature of the application and its nature of behavior introduced dynamism to the objects challenging the automation testing.

Solution Approach: When SPAN team started to look at the requirements, though there seemed a number of problematic areas in the design of test flows, the root was at - How to deal with the dynamic nature of the display controls on the application pages? Different approaches were thought of and suitable ones were applied such as –

1. Regular expressions (objects) were used to formulate the wizard titles and text verifications 
2. Display controls were descriptively created using description objects when the control properties were known or could be derived 
3. Controls were identified as child objects using the parent hierarchy such as browser, page, frame, and WebTables etc.

With the above said different approaches followed, we were able to design different scenarios as listed below into one single test flow.

1. Create a signing contract order for single signatory with a single document 
2. Create a signing contract order for single signatory with multiple documents 
3. Create a signing contract order for multiple signatory with a single document 
4. Create a signing contract order for multiple signatory with multiple documents

Identified approaches were able to address the problematic areas successfully in the automation test design and produce light weight scripts in a short period of time. We used VBScript and QTP tool to tackle this problem.

Testing Story 4: Use of TestComplete namemaps and ‘NativeWebObject.Find’ to tackle dynamic objects identification

Context:
A US-based leading provider of talent management software for the healthcare industry needed automation of its application testing with TestComplete. The functionality lined up for testing was web pages related to talent management applications. Customer had trouble automating the functionality in the web page as the page title was changing for each page and with frequent application builds. Having all the page titles identified as objects within name mapping in TestComplete were slowing the script execution as well as adding a lot of code conditions within the test script for object identification. Hence, it was increasing script fragility. Added to this were multiple instances of the application that had instance specific text appended with title for every page in the application.

Solution Approach: After analyzing the given scenario, SPAN suggested and then implemented a better way of adding objects into name mapping via regular expression. Having just a few high level page objects into name map, dynamically creating the objects and identifying HTML controls on page using ‘NativeWebObject.Find’ property was possible.

Inference:
The page objects, having different titles/names were added using regular expressions, which drastically reduced -

• The number of objects that had to be added into name mapping, reducing the script fragility. 
• The number of lines of code for conditional checks on desired page load in UI, improvising the maintainability. 
• The script execution time.

Testing Story 5: Automation testing of applications with dynamically changing object properties

Context:
A US based leader, providing HR software solutions for the healthcare industry required automating its application testing with Telerik WebAii. The functionality lined up for testing was web pages related to talent management applications. Customer’s QA team had trouble automating the functionality of the web page, where the controls (such as buttons, links etc.) in the HTML grid was assigned with dynamic attributes. The Test Scripts developed in a build (say X) was failing in another build (say Y) due to changed attributes for controls in grid.

Solution Approach: After analyzing the given scenario, SPAN implemented the solutions to identify the HTML controls using the partial match concepts, which is supported by Telerik WebAii and logic to identify all the input controls (such as Text Boxes, Radio Buttons, Checkboxes, Text Areas etc.) without knowing the control identifiers, store them into a collection and then use it for appropriate actions based on the test case need.

Inference:
With the implemented solution, page controls’ objects identification became more robust, script execution performance increased, and the number of lines of code reduced as the controls identifiers were not stored in the Test Solution.

Testing Story 6: One automation solution for 13 different bank applications

Context:
Our customer, a Nordic software services giant, provides services to multiple banks all across the Nordic region. They approached us to automate the testing of different bank applications in IE, Firefox and Chrome browsers. There were 13 bank applications in total.

Description:
To understand the context, we requested our customer to provide us the access to sample bank applications. During the application tour, we realized that all the bank applications have the same business layer and are different in UI implementation, which can be handled by the automation code. We created a Proof of Concept (POC) for the customer, where we automated a scenario for 6 banks with single QTP script. Customer showed a great interest in the proposed approach and gave a nod to go ahead. SPAN, specialized in automation testing, has a big library of automation framework. We picked one in-house developed QTP hybrid framework to implement the automation. The only concern we had was to deal with the UI objects for 13 different applications in QTP Object Repository. This would slow down the execution and make it tedious to deal with multiple objects for each bank. To overcome this, we introduced Config XML in the existing framework as Object Repository. Then we introduced Driver XML, where the user can mention the bank application to be tested along with browser as per the testing need. As per the implementation, the test script calls the Driver XML and reads the name of application under test, picks the elements from Config XML and executes the test in a browser mentioned in Driver XML. The business functions and general functions are managed separately in the Business Utility Library and the General Utility Library. The solution implemented was handling changing objects dynamically across the banks and also was dealing with the varied functionalities depending on the bank.