Test tools – GTL GUI Master

Contact
Test tool GUI Master tests user interfaces automatically using bitmaps. It is a graphically-oriented solution for designing and executing automated user acceptance tests (UAT), regression tests as well as integration tests. Uses image recognition to control the test scenario flow. GUI Master is a platform-independent solution and covers virtually all business applications used by corporations, governments, and public institutions. From a user perspective, gui master offers a great amount of flexibility and automates even the most complex test scenarios at a favorable cost. Keeps the structure of test scenarios clear, easy to maintain and well documented. Test automation driven by GUI Master is fast and efficient. The innovative technology behind test tool eliminates the disadvantages found in “regular” testing tools and provides the most flexible and user-friendly testing solution currently available on the market.

Test tool – key features

  • Platform independence – gui master is a platform-independent solution. it supports web applications, reporting systems, b2b, erp, sap, infor, navision, oracle, siebel, etc., as well as terminal applications (e.g. as400).
  • Simplicity – one solution for testing all applications. no extra software costs or “applications- specific” plugins are required.
  • Flexibility – the flexibility of gui master far exceeds that of other “boxed products”. Available functionality can be extended at once in accordance with project needs. Test scenarios are portable among various pc’s as well as between windows operating systems.
  • Fast test scenario configuration – the test scenario design in gui master is fast and efficient. Users do not write a “test script”; rather they build a test scenario using the mouse. Any part of the test scenario can be re-used in another test scenario with different parameters.
  • Programming skills not required – GUI Master does not require programming/scripting skills. The test scenarios are built/maintained in a graphical environment with good “bug tracking” support.
  • Data-driven testing support – in GUI Master, the data is separated from the test scenario “flow” and kept in a (xls/txt) file or sql database. Various test scenarios are created by adding an extra set of data into the file/database.
  • Automated evaluation of test results – the scenarios are automatically evaluated according to the given guidelines. The results achieved can be compared to the data taken from an error message or displayed report and compared to a value stored in a file or database table.
  • Detailed reporting – the execution of the test scenario (including screenshots) and its results are reported. A number of formats are supported, including the possibility to generate a video sequence from the test.
  • Easy integration with test management systems – GUI Master fully integrates with major alm applications, such as spiratest, hp qc, or ibm rational, to name just a few.
  • Test scenarios resistant to changes in the tested application – gui master supports automated testing even in a dynamic environment, where tested applications change frequently.

How does test tool GUI Master work

GUI Master uses image recognition to run the test scenario trough tested application. Typical test scenario defines, which transaction should be started, the parameters to used and where these parameters should be entered. GUI Master seeks those objects (button, radio button, combo box, drop down list, etc.) on tested screen and subsequently process required action (i.e. enter value, select an item from the drop down menu, etc). Exact position of these objects is irrelevant. An object can be found anywhere on a tested screen, including areas not currently shown. Additionally, the bitmap sample can be dynamically adapted to changed conditions (e.g. different colours, screen resolution, or new font) of the application, which makes the test scenario quite stable and minimize maintenance cost despite changes implemented into tested application. The “visual recognition of objects” gives gui master the ability to automate the testing of virtually any application, including those accessible only via citrix or other remote desktop. In fact the gui master approach is very similar to what a human tester would do when executing the same test scenario: the tester starts the test, looks for the graphical object specified in the documentation, takes the action required (pushes a button, enters data, etc.) and (sometimes) writes a report. GUI Master is also able to react to the status of the tested screen and adapt to the next course of action according to the situation. Because of the similarity of the approach to the “human way of testing”, the test scenario design is easy to learn and quite intuitive. The difference (with a human tester) is that gui master is cheaper, runs faster, evaluates each test scenario in line with given rules, and keeps detailed records of actions taken for further auditing reference. Apart from the “screen-based actions”, GUI Master also actively uses the command line to execute other operations (such as ftp, telnet, various utilities and system services) to further enhance its ability.

GUI Master editor

The GUI Master editor is a component for building and editing test scenarios. In GUI Master, the test scenario is not built in the form of script (vb,java). Instead, tool keeps the test scenario in a visual “tree” structure, where the test designer inserts (by mouse) specialized procedures seeking visual objects and determines what the test scenario should do. Each procedure was designed to execute a specific event, such as “find a bitmap”, “enter a string in a combo box”, “push a button” or “collect data for validation”, etc. the gui master library contains approximately 40 procedures and covers all typical functionality needed to build automated test scenarios. In order to offer maximum flexibility, there is a built-in sdk, which allows advanced users to build new procedures in order to accommodate any functionality not covered by standard procedures. Most standard procedures are supported by the wizard to simplify and speed up the setup of procedure-specific parameters. Such procedure is then virtually set with a few “clicks of the mouse”. This innovative approach makes a significant impact on productivity, as work in the editor is faster and more efficient, compared to the conventional method of typing a script into GUI Master also supports modularity. A set of procedures (e.g. the sequence for login into the system) can be saved in a block (macro) and used furthermore as a procedure with different parameters.

GUI Master launcher

The launcher is a component that provides the following operations:

  • Structures and organizes test scenarios
  • Prepares test data.
  • Launches test scenarios.
  • Collects data.
  • Evaluates results.
  • Creates test reports.

Test data preparation

In GUI Master, the data can be separated from the test scenario and kept in a text file or an xls file. The data can also be stored in a database table. GUI Master accesses the data source via an odbc connector/driver while processing the test scenario. An alternative test scenario is then created simply by adding an additional set of data to the data source. GUI Master also supports the automatic generation of test data. for example, in order to validate an “entry form” it is necessary to enter “allowed” in each combo box, as well as “disallowed” values. GUI Master has a component that makes it possible, with simple statements, to describe these values, and GUI Master then subsequently generates the required values (please see qacegen for more details).

Launching test scenarios

In GUI Master, test scenarios can either be launched manually from a launcher or from a batch file while processing more than one test scenario at the same time. A batch file can run straight from a command line and it is also possible to launch the file from external test management applications (including spiratest, hp qc and ibm rational). While executing the batch file, gui master carefully manages the test cycle. Should a scenario fail or the tested application crash, gui master always attempts to return the next test scenario to a defined “starting point”. That way, a failure of one scenario does not affect the execution of the remaining scenario.

Data collection

Each test scenario is automatically evaluated according to the given guidelines. Should data from the test scenario be saved on a database table, gui master would generate and run an sql statement to validate the results achieved. In some instances, it is necessary to validate the results against the data displayed only on the screen (reports, error messages, etc.). In that case, GUI Master downloads the required data directly from the screen and – if necessary – applies built-in ocr functionality to convert the image. The collected data is stored in internal variables and subsequently used during result verification.

Results verification/validation

GUI Master also provides very strong support for results verification. There is a number of ways to prepare verification statements, which can be written in any programming language or in the inbuilt “results verification editor” using simple comparisons. Probably the simplest way is to store the expected results together with the test data in a text or xls file. GUI Master then only compares achieved results with the data recorded in the file.

Reporting

Presenting achieved results is an integral part of the testing process. gui master offers fully automated reporting functionality. Each scenario is carefully documented during its execution and subsequent verification, including screen snapshots. once the scenario is completed, gui master compiles a report. The level of details and graphical template can be edited according to specific reporting requirements. Alternatively, GUI Master can also store the results in a database.

GUI Master adaptability

The “bitmap samples” sought by gui master on the tested screen should not be understood as static objects. Colors may be changed, other fonts used, or a new graphical object added. GUI Master can easily adapt to these changes without modifications in test scenarios. For example, the typical “bitmap sample” gui master frequently uses is a description of a combo box. This description can be stored as a text value. prior to the execution of the test, GUI Master detects what font and color are used within the tested operation, and based on this information it dynamically creates the “bitmap sample”, which is subsequently used during the test.

Integration with other applications

We focus entirely on test automation. We realize there are many existing solutions for application lifecycle management (alm). In 2012 gartner compared approximately 20 alm applications and we have no ambition to compete there. Therefore, instead of merely building another alm, we gave gui master the ability to integrate its superior functionality into existing alm applications or virtually any reporting system in that area. The test scenarios built in gui master can be launched from an alm application. After completion, gui master returns the required information back to the alm. It is also possible to integrate gui master into existing test automation scripts. GUI Master also supports automatic test data generation. For example, each “entry form” has defined specific data types to be entered into each box, eventually there are filters and constrains applied. GUI Master can automatically generate data to validate entry of “allowed” data types into a box, eventually generate data for “forbidden” data types.