How to start testing during an OBIEE Environment

How to start testing during an OBIEE Environment:

In an earlier posting I discussed the importance of and where to implement testing in the Project Life Cycle for an OBIEE Application. In this posting I want to discuss further how to implement testing for the application and some of the major steps during the Project Life Cycle.
During the Project Initiation Stage of the Project Life Cycle the first step in testing is to develop a Test Strategy. The Test Strategy outlines the recommended approach to the testing processes during the Project Life Cycle. Some of the key components of the Test Strategy are:

· Purpose and Test Objectives
· Quality Standard
· Test Phase Ownership
· Test Phases and Test Types
· Test Plans
· Test Case Repository
· Test Case Design
· Defect Tracking System
· Severity Levels of Defects
· Test Tools
· Test Reports

Since testing will be incorporated of the Project Life Cycle, it is critical that all project team members be familiar with the test strategy and understands their roles in the Project Testing Processes. All project team members will be involved is multiple phases of the testing processes, and it is important that they understand their role in testing and the roles of the other project team members in the testing processes.

Once the Test Strategy has been completed by the Testing Team and approved by the Business Users the next step is to start the Project Test Plan. The Test Plan is started during the Project Requirements Phase. As the requirements are being gathered it is important to identify how the requirements can be validated and tested to insure that they are met by the provided application. The development of the Test Plan involved all members of the Project Team as well as the Business Sponsor and Users. Once a requirement has been defined it is important to have some way to substantiate that the requirement has been met by the application. While looking for ways to test a requirement, it also helps the business user better define and understand the requirements. In most cases the business users have a good understanding of their source application, but have very little insight into the metrics and attributes needed by measure and manage their business processes. Also when a business application is used by many different groups they may have many different business processes to do the same functionally. While gathering the Business Requirement and Testing Requirements, there may be many different test cases to measure the same functionally across different departments in an organization. It is important to gather this testing information to insure that the business requirements can be validated by the different departments. One of the important steps that are often overlooked in testing is to test the actual requirement to insure that is valid and verifiable to measure and manage their business processes. Unfortunately this is often not the case and not until the business users see the Dashboards and Reports do they understand the value of the metrics and attributes for measuring their business processes. The Test Plan can help to identify the type of Testing and Test Cases that need to be developed to validate the requirements. Some of the items that can be included for testing are:

Validate the access to the System – Security
Validate the navigation to a particular screen, dashboard, page, and report
Validate access to the right data, screens, dashboards, pages, and reports
Validate the response time to access the application
Validate the response time to access a particular dashboard, page and report
Validate the capability and ease of using prompts to select data on a report with specific attributes
Validate the use of drilldown on Reports
Validate the use of navigation on Reports
Validate that the attributes that are used to display the metrics are correct
Validate that the metrics on the Reports provide helpful and valuable information to help them measure and manage their business processes

The next major testing task is to develop test cases to validate the user requirements. The Test Cases are usually designed and built during the design and build stages of the Project Life Cycle. In most situations the Test Cases are iterative, because more details are fleshed out during the Project design and build stages. For each requirement the minimum information needs to be developed for each test case:

Test Case Number
Test Case Summary
Test Case Description
Test Case Steps
Test Case Expected Results
Test Case Error Condition
Person responsible for Test Case

Once the Test Cases are built and agreed upon by the Project Team and Business Users, and the design and build stages for the application are complete then the execution of the Test Cases can begin. One major advantages of building the Test Cases early in the Project Life Cycle is the Development Team will understand the test conditions and can execute many of the Test Plans during Unit Testing. Quality is an important of any project and each team member is responsible for building quality into the finished product. By using the aforementioned Testing Processes quality can be built into the project from the earliest part of the Project Life Cycle, instead of waiting until the finished product is turned over to the business users for user acceptance testing. If testing is only implemented during user acceptance testing many of the quality issues that would have been identified and corrected in the early part of the Project Life Cycle will come to light, and will cost more in terms of resources and money to correct than if they were identified and corrected in the earlier stages of the Project Life Cycle