Browse Prior Art Database

Hierarchical Optical & Logical Manual-work Elimination System (HOLMES)

IP.com Disclosure Number: IPCOM000249409D
Publication Date: 2017-Feb-23

Publishing Venue

The IP.com Prior Art Database

Abstract

Method to perform whole GUI testing automation based on user feedback using hierarchical, optical and logical implementation in order to give reasons to every test scenarios so that the automation can fully understand when a test case should fail and when it should pass with a reasonably high accuracy and confidence level.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 18% of the total text.

1

Hierarchical Optical & Logical Manual-work Elimination System (HOLMES)

Disclosed is a method to perform whole GUI testing automation based on user feedback using hierarchical, optical and logical

implementation in order to give reasons to every test scenarios so that the automation can fully understand when a test case should

fail and when it should pass with a reasonably high accuracy and confidence level.

The problem with existing test automation tools is that their method of recording test scripts is very limited to what is just enough in order to get a weak

test script working.

There is also a need for users who are very familiar with the test script itself to construct and maintain that test script, making sure it is up to date.

1.1 Problem 1: whole GUI understanding

The main problem with the current day automation tools is that all of them are unable to analyze and automate GUI testing as a whole.

This means that small change in the GUI may not be captured by the existing tool. It could pass or fail use cases without valid reasons as it doesn’t consider

the GUI from the user perspective.

This problem is commonly seen when the product releases its new versions with more features and changes to its existing GUI.

Logically, this shouldn't fail the existing test cases, but because of the limitation of the current tools that only perform fixed analysis of the GUI without

understanding it as a whole, then every time this happens when new automation script has to be rewritten just to cater for the new change.

1.1.1 Controls within a range of areas

For example, given the following scenario where the application is supposes to pass the use case if the button is located in the top left of the form.

Existing tools cannot capture this information unless explicitly hard coding this logic.

2

Figure 1

1.1.2 Additional unforeseen controls

Many times an application requires tester to continue to try before a manager is confident to release that application, because current automation testing

tool would still pass a use case when there are additional controls on the form.

Figure 2 Figure 3

For example, in RQM when an extra button is introduced into a form as shown above. The following script is still verified as a pass even though there is an

existence of a new objection.

3

Figure 4

Problem 1: windows box is enlarged and automation test failed

4

5

Figure 5 Figure 6

6

1.1.3 Obscured button test (Z-positioning)

Description:

A window application with two buttons - “Show” and “Quit”. Clicking on the “Show” button displays a static text with content “TEXT TO SHOW” below the

buttons. Clicking on “Quit” button exits the application.

Objective:

To test if RFT is able to correctly identify that the “Show” button is not visible and thus, should report a failure to click on the button.

Background:

The application has two versions. Figure 1 shows the first version of the application, which is also the intended and correct version of the application. Note

that both...