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.

The post Test tools – GTL GUI Master appeared first on GTL Tools.

• Up to 50% faster test data preparation than conventional methods.
• Covers 100% of tested business logic.
• Increased transparency of the testing process.
• Complex tests (logical and performance tests).
• Improved security of production data.

Test tool concept

Functionality of QAceGen is driven by the “focus to the point” concept:

• Easy access to all necessary information.
• Elimination of non-value added tasks.
• Focus on the problem solving.

“Focus to the point” means that work with test tool QAceGen is very efficient. All necessary information about data types, primary and foreign keys, constraints and relations impacting the test project is always easily available within the tool. Tester does not have to look for relevant information in documentation, databases or in other information sources. QAceGen also eliminates vast majority of the “non-value added” activities: keys, constraints, filters and records in all referential tables are automatically generated by qacegen. All data fields, although not directly related to the tested logic, but required due to the data integrity, are generated automatically. This significantly shortens the time to prepare test data. This innovative concept introduced by qacegen offers substantial user benefits. QAceGen saves up to 50% of the time needed for test data preparation when compared with conventional methods. When preparing test data manually, a tester has to often deal with very complex data relations, which is very time-consuming and often leads to grossly incorrect results. QAceGen however allows a tester to focus entirely on the tested business logic. Any “non-value added” activities (i.e. not directly related to tested business logic) are processed by the system.
Note: “business logic” specification defines rules which a software application follows. this is used for both development and application testing. QAaceGen has been designed as a “business logic driven data generator”. Tt means that the system generates test data based on the rules defined in the business specification. In QAceGen, the business logic is divided into logically indivisible elementary units called test scenarios. Each test scenario is then expressed in the dgl language (data generation language) of QAceGen. These definitions are then used by QAceGen to generate set of records for each scenario. Resultant set of test data covers every logical branch of a given business logic. Another useful feature of qacegen is self-documentation. Each test project has a defined logical structure, driven by the split of a tested logic into individual test scenarios. Project documentation is integrated directly into each test scenarios. These comments can be easily exported into a separate document (while preserving its original logical structure) and subsequently distributed to all involved parties. This feature prevents project documentation to lag behind the actual status of a project. The “self-documentation” feature minimizes administrative effort and costs and keeps the documentation always up to date. QAcegen generates test data in two modes:

• Data for a logical test.
• Performance test data.

Logical test data is primarily used to test the business logic. Tool generates only small volume of data (of a few thousands of records) to cover every logical branch of a tested business logic. Once successfully completed, the system (based on all test scenarios) prepares data for a performance test. In this mode, the volume of records is significantly higher (millions of records) to simulate a real-life situation and/or a “peak events” to verify that tested application meets speed requirements.
Note: qacegen always generates complex data, which covers entire business logic. No matter how insignificant change request is implemented, tool always generates data for a complex test. Only this way can be identified possible collateral effects of the change request, which may not show during an incremental test.
QAceGen offers an easy transportation functionality to deliver test data into all source files and/or tables. Metadata of each table/file are stored in a “source profile”, which defines location, data format and access rights. The “data transportation” icon transports data into required location automatically. When test scenarios include the “verification statements”, qacegen validates the results of each test scenario and creates detailed protocol. First, these results are displayed in a graphical mode in qacegen. Subsequently, the results can be exported into a text report while preserving the logical structure of the project. The level of detail can vary from the simple results overview to a detailed information about each transaction used during the test. QAceGen’s security features are system’s another advantage. Data used by the system contain only artificial strings and numbers unrelated to the real production data. No sensitive data from production system is ever used during test.

Main applications

QAceGen system has been primarily designed for following type of type of activities:

• Data preparation – (e.g. development, training).
• Applications Testing.
• ITO applications.
• Complex systems.
• Data quality management (dqm).

Note: ito = Input / transformation / output (i.e. an application processing data)
ITO application – takes data from input tables/files, transforms data according to the business logic and stores results into output tables/files. An etl process is an example of an ito application, however similar processes/applications can be found among data warehouse application or transaction systems. Complex systems – specialized solutions (e.g. erp, b2b), which can be seen as a “black box” by users. Data processing and storage of data inside database is not exactly known but these systems communicate with users or other application via pre-defined interface according to given business processes. Data preparation – according to the business logic defined in the specification. As mentioned above, the business logic is split into scenarios and qacegen generates set of records covering each scenario. Such data can be used for applications development or loading data into test/training environments, where the use of production data is either not possible or not recommended due to security issues. Testing – designed scenarios in addition to the “data preparation” include “verification statements” which validate results of a tested application. QAceGen also supports data generation/testing in a complex systems environment. Many organizations run many specialized systems from various vendors and on various platforms. It is often necessary to test how these systems exchange data and cooperate among themselves. These systems communicate via a pre-defined interface. This implies that the input data structures as well as the loaders feeding those systems have a defined structure. Test scenarios are defined by a given business process, which defines both list of required input data (e.g. client, order, transaction) and a sequence of input data loads. QAceGen tool generates data according to the input tables/files structures and then it runs a relevant api or a script to transport input data. In addition, data input using screen forms can be automated. If required, the results verification can be addressed similarly. QAceGen can run an api/script with the relevant business process, record and verify the result. Data quality management (dqm) feature controls data quality. The feature includes:

• Duplicity monitoring.
• Cardinality monitoring.
• SCD2 (slowly changing dimensions type2 – e.g. historization, incidences, …).

Using the simple dqm commands, it is possible to set checks above tables or joins of tables. These commands then generate a set of control sql statements and after execution are automatically verified by QAceGen. The outcome is recorded into a standard report. The main advantage of this solution is fast control of virtually hundreds of tables across different databases. Also, dqm functionality is an “open solution” where new dqm commands can be designed if required.

Benefits

• Lower project costs than traditional solutions.
• Time efficient.
• Enhanced transparency of a test project.
• Improved data security.

The post Test tools – GTL QAceGen appeared first on GTL Tools.