Browse Prior Art Database

A method or system of design driven agile test automation Disclosure Number: IPCOM000248688D
Publication Date: 2016-Dec-27
Document File: 8 page(s) / 270K

Publishing Venue

The Prior Art Database


The disclosure introduce one Graphical User Interface Design driven Test Automation framework, Graphical User Interface designer, developer, tester can work together efficiently based on this framework in software life cyle

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


A method or system of design driven agile test automation


GUI Graphical User Interface

IDE Integrated Development Environment

MBHFT Model Based Human Friendly Test Language

Current GUI Test Automation has two great pain points: 1) Can’t start GUI Test Automation development if the GUI program hasn’t been developed by the developer. - GUI Designer, GUI Developer and GUI Tester working on the same UI thing in mind but the work are not shared. Is there a way to share common data among GUI Design, GUI Code, and GUI Test Automation Scripts? Is it possible to start GUI test automation development based on the GUI design data shared by GUI Designer, and then once the GUI code is ready testers can kickoff the testing immediately? - GUI Automation is usually not used to test new features because it takes time to develop the automation after UI development complete and the UI changes frequently. It is mostly used for FVT regression to test stable features. 2) The automation script/code is difficult to maintain. - Writing test automation code/script is a complex development work for most testers - GUI Change is not well communicated to concerned parties. Testers usually know the GUI Changes when the test script fails. Then it is a huge work to find the UI changes and modify the test scripts. Is there a way to automatically detect GUI change and notify test script errors to the tester, just like the compiling error notified to developer when he/she is writing code in IDE?

The present invention will tackle these two pain points by introducing a breakthrough GUI Design driven Test Automation framework.

The following figure briefly shows the concept of the innovation.

1) At the central of the figure is the GUI Model Data which is shared by all roles including GUI Designer, GUI Developer and GUI Automation Tester through a new

IDE infrastructure. The present new IDE infrastructure stores the data centrally in a server with three types of IDE Client – GUI Designer IDE, GUI Development

IDE and GUI Automation development IDE.

2) The GUI Model data consists of the Page Element Topologies and the Page Action Flows of an application. When the GUI Designer draws the GUI Artifacts and

GUI flow in the GUI Designer IDE, the GUI Model data is generated automatically and saved back to the central server.

3) Once the GUI Design is complete. The GUI Automation Tester can start GUI automation test scripts development using the generated GUI Model Data in the GUI

automation development IDE. He/she doesn’t need to wait for the GUI Developer to develop it first.

4) At the same time, the GUI Developer can start coding according to the GUI Model Data using the GUI Development IDE.

5) When the real GUI program is ready and the test script is ready. The GUI Automation Tester can start the testing immediately.


6) Once the GUI is changed either by the GUI Designer or GUI Developer in the IDE, update will be made to the corresponding Model Data in the server. Then...