A continuous data-quality control increases the benefit of the produced results and lowers the follow-up costs that appear using incomplete or inconsistent data.

Thereby, the various processes of data quality management, the test process, usually follow a certain pattern.

The displayed example uses a use case to demonstrate how the RapidRep Test Suite recognizes forbidden or missing currencies.  

Description of the use case

• The data whose quality is to be tested is located in an Oracle table.
• A CSV file lists all currency codes whose values are needed for each day.
• Since RapidRep can access all relevant data sources, the scenario could also be comparing data in MySQL with the values of a Microsoft Access view.

Common questions regarding quality

• Are the exchange rates available for a certain day?
• Which currency has no exchange rate loaded?
• Are there any exchange rates for currencies supplied that aren't necessary?
• Are the rates plausible according to their time sequence?

Layout design for a test-case report with Microsoft Excel

• The realization with RapidRep begins with designing a layout template based on Microsoft Excel.
• The first step of the implementation of a test case is to design an excel workbook, which can even be done by users without any experience with RapidRep.
• RapidRep does not restrict how the workbook is created. Still, it is considered as Best Practice to create an overview sheet in which the test-case result is documented after the test execution. The aim of this overview is to register all details of the process as well as to document all test runs.

Implementation with RapidRep Designer (1/5)

• The RapidRep Designer is an autonomous Java application used to create the so-called report definition is created.
• The settings in such a report definition are adjusted using the tabs
• The properties of a report definition are inserted into the previously created Microsoft Excel Workbook (Excel template)
• Autonomous workbooks are created based on this template during the test execution. An adequate name can be stated with the help of the parameters.

Implementation with RapidRep Designer (2/5)

• In case that reports are created based on a report definition, the runtime can be influenced using various type-specific parameters (A default setting is available).
• In this example, a date parameter is set, since the user or the batch application is supposed to be able to enter the desired date.
• The calculation of a test case during the runtime can only be influenced via the parameter values. Apart from that, the remaining knowledge about the test-case logic is totally enclosed within the report definition.

Implementation with RapidRep Designer (3/5)

• In this example, the debit and actual data is located in two different data sources. The actual data is located in an Oracle file, where as the debit data is located in a CSV file
• In RapidRep, an arbitrary amount of connections can be defined in the connection tab.
• RapidRep supports all relevant data sources. The definition of these data sources is homogeneous and is explained elsewhere.

Implementation with RapidRep Designer (4/5)

• The central part of a report definition is the data elements, which can existent in an arbitrary amount and can be managed in a tree structure.
• With the help of a simple macro language and parameters, it is possible to define easily maintainable SQL queries, whose evaluation on the data sources return data blocks during the test-case execution.
• The optional language is simple, but very effective. 4 commands are enough to easily structure even complex SQL queries: If/ then- branch,  assigning variables und calling functions

Implementation with RapidRep Designer (5/5)

• The results of all data elements are written in a specific are of the workbook template
• The numerous setting options influence the output specifically.

By doing so, the development of a report definition is completed and can be used from the RapidRep Test Runner or the RapidRep Test Runner API.

Executing a test case with RapidRep (Test Runner or Test Runner API) (1/2)

• As soon as a certain version of a report definition has been finalized it can be used within the RapidRep Test Runner application.
• The main aim of the RapidRep Test Runner is to execute test cases.
• Therefore, the user chooses a report definition and creates a new, still incomplete test case
• All previous test cases and their status are listed in a table

Executing a test case with RapidRep (Test Runner or Test Runner API) (2/2)

The previously created report is parametrized in an appropriate way (only one date is provided as a parameter)

• Afterwards, the test case is calculated according to the example stated at this place and displayed as a Microsoft Excel workbook
• During the calculation, the results of the data elements from the report definition are written to the respective are of the Excel workbook template.
• The produced result is stored revision proof within the RapidRep repository

The final result of a test case report

• The result is an autonomous Excel workbook, which contains all data based on the Microsoft Excel workbook template either to validate the result or to identify buggy data.
• The advantage of this approach is that the MS Excel workbooks can be passed as an attachment towards an optional Test Management System. The result can be used without being dependant on RapidRep.

Integration in IBM Rational Quality Manager

The RapidRep Data Testing Adapter makes the functions of the test-case execution and evaluation available for the IBM Rational Quality Manager

This connection has been tested by the IBM Staff and was rewarded with the "Ready for Rational" Software Logo.

Applying a RapidRep test script in RQM

• A test script is applied in the Rational Quality Manager, selecting “Data Testing with RapidRep” as the type.
• Via an import progress, all available report definitions are displayed. In this example, the Currency Test report definition is selected and stored together with the parameter (which might has to be adjusted) as a part of the test script.

Creating a test case in RQM

• A test case is created in the Rational Quality Manager and the previously created test script is assigned.
• As soon as the test case is started, RapidRep becomes active in the background and executes the test case with the date from the test script.

Result of a calculated test case

• After triggering the test case, a progress bar appears, followed by an “Execution result”
• Since two currencies are missing in our example, the result of the test case is returned as “failed”.
• The test-case report appears at the bottom of the display as an attached Excel workbook
• Naturally, test cases can be triggered arbitrary often.
• As usual, it is possible to create the progress reporting and other kinds of reports can RapidRep directly from within the Rational Quality Manager.

Summary

The use case demonstrates how RapidRep is capable of testing data quality. Obviously, it does not matter where the actual and debit data is located, since RapidRep is supporting all relevant data sources. Uses cases with practical orientation often have to perform dozens of these data –checks. On behalf of RapidRep, there is no limitation.

The realization of a test case is usually only performed once during the design phase, where as the evaluation of the test cases is performed arbitrary often and is parameterized (maybe even in batch form). The implementation is very simple and can be both performed from the inside as from the outside of the Rational Quality Manager.

Advantages:

• The produced results are completely transparent and reasonable
• The results from the test-case evaluation are completely contained in a Microsoft Excel workbook
• If a test management system is used, in this case the IBM Rational Quality Manager, it is possible to plan within the IBM Rational Quality Manager, whereas the implementation and result evaluation is performed by RapidRep
• The precede enables a high test coverage with low costs