Venkata Ramana Edagottu
Manager, Hitachi Consulting Software Services
Venkataramana, CSTE, PMP, ITIL is currently leading the Applications SubCoP is a part of TQA CoP ... more>>
This article is intended to provide information of test requirements, defect management and approach taken to make sure the OBIEE dashboards are tested with minimal defects.
Test Data Requirements:
Test Data has to be clearly defined prior to testing Oracle Business Intelligence dashboards data. As a best practice, test data should mimic real user world as in Production systems. Database should be provided with at least 4-6 months of production data to be present to validate results. Test Data should have specified boundaries while inputted in a test case. This term "Boundary Conditions" is to be clearly defined by the analyst who is responsible for constructing the data. Boundary Conditions for test data specify the limits within which the system should work in intended manner. Test data when not limited, can lead to a project delay increased testing efforts, and resource impact.
Validating the Report data Vs Database Data is a key challenge in any OBIEE projects. Need to take the query log and build our own query or create a SQL query according to business logic to run against the source database. This needs good command on SQL queries and joins.
Simplify your lengthy SQL queries to quickly run on the source/target data otherwise, it may take longer time to execute the query. This will ultimately leads to the execution timelines.
ETL stands for extraction, transformation and loading. Incremental ETL is the process of loading the newly added/modified/deleted data from source database to destination database. Test analyst should be create/modify/delete records and check the data after the every ETL refresh. Typical ETL test process is as follows:
Most of the OBIEE dashboards have multiple drilldown reports. Each drilldown report navigates through one level to lower level of the same hierarchy. Good number of defects can be found in this navigational experience of the drilldown reports by noticing the headers of the reports and data displayed in relation with the main dashboard report.
Different kinds of user roles will be defined based on the nature of business of different customers. Test analyst should be able to understand the different scenarios applicable to different user roles.
Ex: Host User, Super User, Analyst User, Marketing User... etc. The Analyst User may not be able to see customer details (First Name, Middle Name, Last Name, all Address fields, Email, Gender, Phone, Customer Attributes... etc). The Analyst User may have access to every dashboard except for ad hoc reporting.
Well designed test cases covering the entire user roles will be greatly affect the quality of the OBIEE application.
This is one of the important aspects in dashboards testing. Performance acceptance criteria should be defined in well advance and with the proper input parameters of dashboard reports. Response time for all the drilldown reports should be tracked and monitored. Ultimately this will impact the end user interaction with the application.
These meetings will help project teams with the following: