Questions that arise during a BW upgrade project include:
- Are the standard object features behaving as expected?
- Is the enhancement pack itself broken?
By having a series of pre-defined feature tests available in the system, we are able to run them independently of the DataModel used in the BW production system. By being able to push known data through many existing ETL scenarios, we are able to compare the before and after results to achieve a level of certainty. This allows the project team to save time by running only the feature tests that are used in this environment.
For Example: Do you really care about the sign of max aggregated key figures in a DataStores change log table (the before and after records) impact on a downstream cube, if they are not in the DataModel? No, of course not.
Regression testing in an upgrade project is something that most of us find hard to get excited about. We all know that it is necessary and important to the overall success. So what is it that we are really testing?
The business logic in the ETL is not going to be altered as part of a technical upgrade project. Chances are that the project manager has specifically excluded the effort to fix business logic that was already broken or is discovered to be broken during the upgrade project. This leaves the support team accountable for fixing existing bugs, in parallel to the upgrade project teams activities.
Now there are only two things to be tested as part of a technical upgrade project:
- Outside: Are all the standard objects still working with each other?
- Inside: Is each standard object and it’s features still behaving as expected?
These are the two main questions that everyone wants answered; including the business system owners, business team members, the project manager, project team, support teams, etc. Each team will want a different level of detail but they all want the basic answer of ‘Only X issues identified and Y are show stoppers’.
With quite a few different teams and many more individual people all wanting to get that warm feeling of knowing that the new code delivered in the enhancement pack is not actually going to make things worse; how can you afford not to answer these questions sooner?
Were you unlucky enough to experience the BW patch that failed to execute Transformation End Routines, at all. Good news, a follow up OSS Note was made available to patch the enhancement pack.
The main thing to consider is what would have been the impact on your upgrade project time line for something that should have just worked? Or worse yet, what if it went unnoticed and processed 2 weeks worth of delta data in the BW production system before someone finally tracked it down?
“most upgrade projects are under great pressure to
be done and out of the way as soon as possible”
When an Enterprise has gone to the effort to invest in implementing feature tests, they are able to leverage this in their sandpit system and know in advance which features of the standard objects are broken before they corrupt the data. This information is invaluable as it can play a critical part in a go/no-go decision towards the beginning of the project time line before the Enterprise invests in the additional human resources to implement the BW upgrade project in the development, test and production systems.
This also leaves the support teams with as much time as possible to continue with business as usual while the smaller upgrade project team finds answers or engages with the software vendor (SAP AG). Interaction with external resources can take weeks or months, depending upon the service level agreements your Enterprise has with them.
The clear advantage of using feature tests as soon as possible in the upgrade project time line is that they can be executed by a technical or functional resource without taking business and support personnel away from their daily duties.
- How ‘pre’ prepared are you for the next SAP BW upgrade?
- Will you go to the effort of implementing feature tests?