Testing is a crucial part of the software development life cycle (SDLC), irrespective of which method of development you are using: Waterfall, Agile, Iterative etc. Developers need test data in order to unit test new functionality, test analysts require test data to conduct system and integration testing, end-users require test data as part of User Acceptance and Business Process Testing and support staff need test data to manage production problems related to production issues.
Creating valid test data for the various test phases is task that can be simplified with any one of a number of automatic test generators available in the market today. However, creating test data, especially system test data, that is meaningful and relevant to your system under test requires the test analyst to fully understand the requirements and to be proficient in using the tools at hand in order to construct test data in exactly the right format.
This might be one reason as to why so many test analysts and end-user like using Microsoft’s Excel to create test data. It is simple to use, easy to understand and is readily available in most organisations. However, Excel doesn’t provide out-of-the-box all the necessary tools to manipulate and validate the test data, so that it is constructed to meet the specific test conditions.
Of course this can be overcome with some VBA programming but then that creates a maintenance overhead. Proteros Data Systems’s Excel Interface, which is part of the Frurion™ product range, provides and easy-to-use UI that extracts test data that has been created in Excel to create test data to be used in any one of the Frurion™ test tools.
The Frurion™ Excel Interface provides a mechanism for validating test data, created in Excel, without the need for VBA programming. It relies on field definitions created and stored in the Frurion™ data dictionary, which holds information on all field attributes and is used to validate data against these definitions.
The Frurion™ Excel Interface also comes with an Error reporting capability that highlights which cell does not match the field definitions, making it easier for the user to go back and rectify the error before the test data is used in any testing. The aim of the Frurion™ Excel Interface is to increase data quality by ensuring the test data is aligned with the field definitions. Data quality is further enhanced due to the automatic padding feature. Fixed length fields are padded to the full length of the field. Variable length fields are padded to the length of the minimum size. This aids the test creation process and eliminates simple data errors.The Frurion™ Node mapper, is another tool within the Frurion™ suite and provides a mechanism for a user to map data held in Excel to a source location, such as a file, for example. Therefore creating a file to test an Extract, Transform and Load (ETL) process as part of a data migration project, for example, is simplified by using tests data held in Excel and the target field definitions from the Frurion™ Data Dictionary.
The Frurion editors, which are used to manipulate the data dictionary support a number of field data types include Binary Coded Decimal to support Cobol COMP-3 definitions.
The Frurion™ Excel Interface can be used in the following areas:
- Test Case Design & Execution
- ETL Testing:
- Validate Data Extraction Logic
- Validate Data Transformation Logic (including testing of Dimensional Model – Facts, Dimensions, Views etc)
- Validate Data Loading
- Some data warehouses may overwrite existing information with cumulative, updated data every week, while other DW (or even other parts of the same DW) may add new data in an incremental form, for example, hourly.
- Test end to end data flow from source to data mart to reports (including calculation logics and business rules)
- Check for accuracy, completeness (missing data, invalid data) and inconsistencies.
- Reports Testing (Drill Down/Drill Through):
- Verification of the layout format per the design mock-up, style sheets, prompts and filters attributes and metrics on the report.
- Verification of drilling, sorting and export functions of the reports in the Web environment.
- Verification of reports containing derived metrics (Special focus should be paid to any subtotals or aggregates)
- Reports with “non-aggregate-able” metrics (e.g., inventory at hand) also need special attention to the subtotal row. It should not, for example, add up the inventory for each week and show the inventory of the month.
- Test files for Data Migration testing
- Creating test files for mainframe Cobol or PL/1 systems
- Creating interim files for ETL testing
- Creating load files for data warehouse testing
- Simple UI to map Excel cells to target system
- Data validation and auto padding