Packaged Application Testing teams are always looking for ways to optimize test efforts and costs. In Packaged Application Testing like Oracle Apps Testing, the effort put into identifying quali铿乪d test data for processes such as Procure to Pay and Order to Cash can be excruciating. This is done because no one wants data integrity constraints to impact process and transaction accuracy. The best data can be found in production instances and by creating a subset of production data, the problem can be circumvented. In most cases, however, data privacy issues prevent access to live data. Therefore, we have the practice of Test Data Management (TDM) to address the problem. The remit of the TDM team is to make the right data set available in the right combination, in the right format, at the right time and at the right place.

The signi铿乧ance of Test Data Management and the challenges around the practice

TDM is gaining traction in the Testing practice. TDM reduces the time taken in data collection, organizes the data and reduces defects in data.聽 The tools used for TDM also help meet business process driven data requirements and manage data complexity. The test data鈥攚hich is Master dataii聽 and Transactional dataii 鈥攊s then used for the functional validation of test cases. The provisioned data must not be too large in quantity or small. But it can be provisioned by creating synthetic data through modi铿乧ation of the extracted production data. Today, TDM is implemented with the aid of well-de铿乶ed processes, manual methods and platforms. However, the TDM team has several data sourcing challenges to address that could include:

• Inadequate and incomplete test data requirements
• Test data sizing and planning not covered during test requirements phase
• No access to data sources
• Turnaround time for data acquisition (mostly from development team) is huge
• Data provided may be chunks from production dumps and can be sensitive (unsuitable for business test cases)
• Corrupt data
• Lack of test data creation knowledge
• Inability to leverage partially utilized data
• Business logic of data relationship is missing with testers
• Huge volumes of data are needed in a short span of time

The widespread bene铿乼s of TDM solutions

TDM implementation can address most challenges, with several bene铿乼s:

• Quality: Optimal test data coverage and a reduction in data defects/corruption can be achieved by utilizing TDM solutions. By analyzing data requirements early, the right data can be acquired (or synthesized) and by capturing data details in the planning phase, we can have version control and end-to-end traceability of data. Stringent data security policies help in data safety.
• Turnaround time: The right test data and designs lead to faster execution cycles and improved time to market. GUI-based data tools assist in this while business process driven TDM solutions quickly identify the right data sets.
• Optimized cost: TDM reduces costs by sinking test data creation efforts and minimizing data storage.
• Ease of use: This is among the most attractive features of TDM鈥攊t doesn鈥檛 require data expertise. Even normal functional teams, functional testers and automation tester can use the solution.

TDM solution for functional testing

The challenges enumerated earlier are part of the everyday life of a function tester. Successful implementation of TDM solutions and frameworks can alleviate most functional testing challenges and assure the completeness of testing from a business perspective. In functional testing, TDM solutions are governed by numerous factors that include:

• Test coverage: Identi铿乧ation of all business scenarios鈥攖he data should contain positive scenarios, negative scenarios, boundary conditions scenarios, all functional 铿俹ws, etc.
• De铿乶ed volume of data sets: There should be only one of every data set for each scenario identi铿乪d. Data sets for repeated scenarios should be created at once to reduce effort.
• Reusability: Master data can be reused across test cases and common transactional data can be base lined so it can be reused during release testing.
• Optimal test data:聽 Test data should be a subset of production data. It should comprise data for all testing scenarios and be of minimal size to avoid hardware and software cost overheads.
• Data requirements gathering process: During test case preparation, data requirements should be documented and marked as reusable or non-reusable. This ensures that test data is well de铿乶ed and documented.聽 A simple cumulative of the same test data provisions the required test data.
• Feasibility check: TDM solutions are suitable for functional testing projects that invest over 15% of the testing efforts on data preparation and continuous regression testing across the release cycles.

TDM solution to feed in test automation

Test data creation is a challenge in test automation. Often data has to be created quickly from the front end as there is a rapid burn of data during test runs and there is limited access to dynamic data. The data required for Test automation is usually created manually, or from user interface, or from data operations in the database. This is time-consuming and requires domain/functional knowledge. Implementing TDM solutions helps overcome the challenge as it supports multiple iterations of dynamic data in short intervals.

A quick overview of Oracle EBS TDM used for EBS projects shows how it can be leveraged for test automation.

Technology stack:

• Developed TDM tool using Oracle APEX software
• Developed SQL/PLSQL scripts to support test data for vanilla Oracle EBS applications.
• Developed customized HTML pages for Oracle EBS applications
• Developed Excel Macros for synthetic data generation of test data

Pre-requisite:聽Oracle Apex to be installed on Client Server, which is free of cost.

The Oracle EBS TDM tool addresses the needs of today鈥檚 application testing teams:

• It fetches Master data details (Chart of Account, Employee, Customers, Item, Supplier), Procure to Pay, Order to Cash, etc., from non-production instance based on organization ID or date range selected.
• It does not save data from non-production instance. It fetches data on the 铿倅. If testers want a data set for reuse, that data view can be saved for later use.
• It is interactive, GUI-friendly, and incorporates most of the Excel functionality. This makes it usable by anyone.
• It has a tab that can download Excel with macros for synthetic data generation.
• Synthetic data in Excel can be reused for functional testing purpose. For automation testing, Excel data in parameter form can be integrated with any automated tool like UFT, Selenium etc. and used.

The bene铿乼s of the Oracle EBS TDM will appeal to testing teams facing an uphill task because it provisions data in the right format, reduces effort and cost by up to 40% and the quality of data is defect-free and immutable, reducing test cycles. Its intuitive user interface and roles-based provisioning of data makes it simple to use. Our experience with the tool con铿乺ms that this can overcome all the challenges that testers face today.