OBIEE Reports validation

Report Validation:-

—————————————————————————————————————————–

Aggregation in column level needs to be validate separately on column level or directly in a adhoc query

——————————————————————————————————————————–

1. Sample report and Navigation steps

• Oracle Interactive Dashboard page is displayed as designed for project
• Click on Customer Subject area (Note : Generally set of reports may or may not  come under specific subject area)

2. Checking the Source record count and Target record count

• Checking the source record count and Target record count for matching
• While writing the queries we can validate the record count

Once the Report gets executed we need to validate query in database by finding the matching record count.

3. Checking the Naming Conventions: During the Project setup and later during maintenance these conventions can help for communication about several possible entities: ETL, DWH and Repository. Using naming convention is only effective if they are used by everyone at the same level of details:

• Fact Table (W_xxx_F)
• Dimension Table (W_xxx_F)
• Dimension Hierarchy Table(W_XXX_DH)
• Aggregated Fact Table (w_xxx_AG

4. Authentication: Is the process used to verify the identity of a user who tries to access the system. This is implemented by BI Server using either the Internal Authentication or External Methods

Authorization: Is the process used to verify that a user has been granted sufficient privileges to perform the requested action on the special object.

5. Report Data Validation: In BI testing world, generally we call it as End to End testing hence we need to perform report data validation against data warehouse(DB) and source system data (i.e. Test data which are created specific to report from Business team or Front office team)

Whenever the report is opened, one session log will be generated with Query which is used to identify the physical data source to which Oracle BI Server is connecting. Use this SQL to analyze the tables and fields while validation the data of the report.

6. Steps to follow to navigate to the Session log Query:

Step 1: Click Settings > Administration to open the Oracle BI Presentation Services Administration   window

Step 2: In the Session Management window, under Cursor Cache, click the View Log link for the last entry

7. Source to target validation :Here source is represented by metadata repository and Target represents OBIEE Reports & Dashboards, BI Publishers.
8. Presentation Layer Object Validation:This is the layer of the logical business model that is accessible for the client through the structure query Language better known as the logical SQL. The presentation is the appropriate layer to set user permissions and to validate user permissions to reports.
9. Categorizing the metrics: It is important to classify the metrics from multiple perspectives such as, their frequency of use, potential performance impacts, and complexity of calculations involved.  Such a classification helps drive priority of testing.
10. Dashboard charts and filters criteria: User interface testing should encompass tests with multiple options in the available filter criteria.  OBIEE gives enough drilldown features to verify the underlying data on the clickable components of the charts.  Test cases written should be detailed enough to verify data aggregated at various layers.
11. Filter Validation

• Validate the entire filters which are available on report. Example refer below report and its filter
• Example: For Performance Measure filter- Validate filter contents against report requirement and database

Filter types:

Local filters:  Filtering the records in the report level.
Global filters: Filtering the records based on user selection in Dashboard.

Dashboard Validation: When a user selects certain request that need to display the exact results in the dashboard.

12. Data level security: Data level security validation means user will be able to see only particular data for the given permission

Example: Both the Eastern and Western region Sales Managers will be seeing the same reports but the Data visible to them in the reports will be Eastern and Western region Sales data respectively.

Object Level security: Need to validate whether the particular user is able to access the particular dashboard or folder etc.

Example: For example, users in a particular department can view only the subject areas that belong to their department.

13. Bursting the reports: Bursting the reports means distributing the reports based on the regions. Eg: if there are 4 regional reports, validate to burst the reports (based on East, West, South, North regions).
14. Buzz Matrix validation: Need to validate the alerts in the Dashboard.

Example: We are running stock market and CEO is very much interested to know today’s business weather, has it reached a certain level that which he expects compared to the last week. If the level has reached to a certain level in Dashboard Buzz (Alert), it should raise an alert saying that it has reached the level in such a way the buzz matrix validates.

15. Testing in Levels:In a typical OBIEE project, it is advisable to test in multiple areas rather than attempting to test everything at once.
16. 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.
17. 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.
18. 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.
19. 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.

16. 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.
17. 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.
18. 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.

1. 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.
2. 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.

Thus this Document gives an overview of OBIEE Testing and commonly used in BI Components while doing validation.