Browse Prior Art Database

Customisation In A Test Harness Disclosure Number: IPCOM000032875D
Original Publication Date: 2004-Nov-17
Included in the Prior Art Database: 2004-Nov-17
Document File: 4 page(s) / 71K

Publishing Venue



GUI Testing has traditionally been perceived as conventional testing of menus, bitmaps and windows. Further, GUI design and development technologies have evolved with time. Technically, this progress has to be well-matched with equivalent GUI Testing methods. The objective of GUI RTS (Regression Test Suite) II is essentially this. Specifically, the GUI RTS II aims at providing a framework that will reduce time and effort spent in preparation and consolidation of test as well as efficiently testing the subject.

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

Page 1 of 4

Customisation In A Test Harness

Why GUI RTS II exists?

The requirement of GUI RTS (Regression Test Suite) II was designed and developed with the intent of catering to the test of any product

The test subject/product was logically classified as a set of components. The testing required testers to report XML results into a DB2 database. The test subject could potentially reside on more than one test machine. The regression testing should be easy to use for third parties.

The GUI RTS II had to be fast and reliable.

The GUI RTS II had to highly configurable easy adoption.

The GUI RTS II should have Traceability options.

What problem does it resolve?

The GUI RTS II resolves the following problems

Direct integration with Integrated Test Environment (ITE) Database via XML. This enables automated test case tracking, web-based result reporting and data mining.

Multi-machine Testing. Cross platform testing achieved using Software Test Automation Framework (STAF). STAF is a framework that enables test script developers to develop scripts that can initiate processes on multiple platforms. Easy-to-use GUI to drive the automation. This is aimed at Development & Lifecycle Test teams, so users can run tests without needing to understand the code. Can also be started by any other tool, locally or remotely, allowing complete integration.

HTML logging onto a web server so test failures can be investigated via the web no matter where the test was run.

Automation framework has a modular plug and play design, making it portable to other products. Soon it will also be rolled out for WebSphere MQ testing, potentially saving an enormous test effort.

Individual Test Isolation. Highly configurable and easy to understand test parameter files enable other teams to configure tests. Available both at Test Suite and Test Case level
Fail Safe Mechanism for Test Results. Erroneous previous test runs are checked and user is prompted. This alerts the user to take corrective action.

Hierarchical Component Based Architecture. The automation is split into components for plug and play (or "Plug and Test") ability making it easy for other teams to plug more tests. Also aids in isolation of test suites or test cases for individual run. A plug and play approach.

User Driven Testing. Traditional GUI testing works with objects, and traditional run time testing of a component simulates input from other components (e.g., from a GUI). This automation does exactly as a user would.

    This is the design of a customisable framework for running automated tests. This customisation is achieved by using an instructions profile to store information such as if a build is to be install before the tests is run, which tests to run and where the test results is to be stored, the tests can be run on unattended machines. This profile can be copied to or shared with other users or machines. This would allow

Page 2 of 4

other users that is unfamiliar with the tests to run the tests.

    With the aid of...