1. Testing in Levels: In a typical OBIEE project, it is advisable to test in multiple areas rather than attempting to test everything at once.
a) The first set of tests can verify the accuracy of the column to column transport of the data between the source and target. This verification is typically done using SQL statements on the source and target databases.
b) The next step is to verify the accuracy of the repository (the .RPD file.) These tests will include testing with appropriate dimensional filters on the metrics and the formula used to compute those metrics. Testers can build two sets of comparable queries within the repository interface.
c) The next step in testing will be to verify the dashboard / reports against comparable queries on repository metrics. In these tests, testers verify dashboard charts / reports against corresponding results from queries they execute on metrics of the repository.
d) Finally, the functional interface tests will cover tests to verify the lookups, performance, ease of use, look and feel etc.
The first three types of tests are performed by testers who can create simple SQL statements.
Structure and organization of test cases:
The choices on test cases naming convention and structure can help organize the test artifacts better and aid a great deal in implementing the overall testing strategy.
For example: If the test cases are grouped based on the nature of the tests, like, source to target verification, RPD metrics tests, functional, security, performance and usability, it would be easier to pick and choose the tests based on the testing context and tester capabilities.
1. User acceptance criteria:
Users typically have an existing legacy mechanism to verify if what is displayed in the new solution makes sense. Testers should dig into this and understand how the end users built the project acceptance criteria. Testers should challenge the assumptions made by the business community in deriving the acceptance criteria. This activity helps get an end user perspective built into the testing efforts from early on.
2. Validating Master Detail Report:
Master Details linking of views allows you to establish a relationship between two or more views such that one view, called the master view, will drive data changes in one or more other views, called detail views.
3. Time series functions validation: Time series functions provide the ability to compare business performance with previous time periods, allowing you to analyze data that spans multiple time periods.
Time series functions enable comparisons between current sales and sales a year ago, a month ago, and so on.
a. Ago: With ago function we can compare period to period
b. To date: Time series functions enable comparisons between current sales and sales a year ago, a month ago, and so on.
c. Period rolling: The PERIODROLLING function does not have a time series grain; instead, you specify a start and end period in the function.
4. Oracle bi-publisher validation: Oracle BI Publisher known as XML Publisher offers efficient scalable reporting solution available for complex, distributed environments. It provides a central architecture for generation and delivering information to employees', customer and business partners both security and in the right format.
