BI Developer is fully responsible for Unit Testing, which normally happens in parallel with development.
Unit testing is a verification and validation method in which a developer tests individual units to make sure that those units are fit for use. A unit is the smallest testable part of an application e.g. query.
Ensure that the query meets its design specified in RDD.
Every BI project typically requires prototyping and rebuilding user requirements.
There is nothing business people like more than to see their requirements turn into a tangible deliverable. A prototype accomplishes this goal.
The purpose of prototypes is not to see the accuracy of data extracted from the development environment. This is done under unit and integrated testing and later by the business at UAT testing.
The environment is usually loaded with small, clean and well representative set of data . The main purpose is to try out visual interfaces, functionality and to make sure that the presented report objects meet their expectations. You do not want to have your prototype results tarnished because of dirty or missing data.
Testing the technology for performance is not a valid purpose for a prototype. It is not a stress-test environment.
In SAP BI world the following units are tested in an ‘integrated fashion.’
Entire flow of data from Data Source, InfoPackage (transactions, attributes, hierarchy, text), PSA object, InfoObject, DTP (from PSA to DSO, from DSO to InfoCube), DSO, InfoCube, MultiProvider, Security Role, Process Chain, notifications, NetWeaver Portal (startup screens, folders and report lists) and finally check whether reports get data from sources as expected.
It is performed to make sure that all BI objects work together in harmony to bring required business information accurately to the users.
The performance testing, stress testing and recovery testing may also be performed during integration testing.
Once the application is ready to be released the crucial step is User Acceptance Testing (UAT).
In this step a group representing a ‘cross section of end users’ tests the application. The user acceptance testing is done using real world scenarios and perceptions relevant to the end users. Therefore the UAT scripts/exit criteria are created by business users and expressed in a business language.
Acceptance testing generally involves running a suite of tests on the ‘completed system.’ This means during UAT when operational systems accumulate data it will be transferred to BI environment through scheduled extractions for users to validate through reports.
Project Duration - ideally not more than 3 months.
Clearly define the roles and responsibilities of project team (RASCI)
Follow a sound methodology for gathering requirements and implement such requirements keeping user satisfaction as the primary key measure of success.
Lead and guide the business team throughout the process – sometimes business doesn’t know what information they want (SAP BI has got tones of information), how reports should be compiled, capabilities of BI tools and how reports are delivered to them.
Train business users adequately enough to handle BI reporting tools.
Focus on deliverables in scope - These deliverables need to be owned by the business teams, not the BI team.
Foster ownership – Reports are owned by the business, not BI.
Sign-off on scope, prototype and UAT is important.
Help the business teams help you. Guide them through out the process.