It is time for the next upgrade project. The team members are being selected and gather; were you the one assigned with the responsibility of regression testing?
You must be holding the short straw. :-)
This usually involves the creation of new documentation and test scenarios because the prior upgrade project did not leave a viable legacy and no one has any faith in the old documentation, at all. No matter what the reason, you are looking at what appears to be a lot of work. So what is that work load, exactly?
There are plenty of information sources to review for ideas to add to the regression test list:
- Legacy project documentation;
- Existing support team documentation;
- The software vendor;
- The upgrade software release documentation;
- Blogs and community forums, etc, etc, etc.
Take a deep breath and remember that the prior documentation would only have ever been a good starting point to you because the system itself has probably been improved since those documents were created anyway. While some of it could be reused a lot of it would be slightly different from the current system configuration. So you really couldn’t trust it completely, anyway.
Have a look through the vendors official upgrade information area. SAP AG has quite a few good documents and many active forums that can provide additional information for you to work with. The released versions of SAP BW always have great change log information to point you to exactly what is changing.
The files that patch the system itself usually come with useful hints to specific activities that are an exception to a standard upgrade procedure. Make sure you consider the full implications of these hints.
For Example: When the new analysis authorisation was introduced there was an extra step you could perform to reset the default authorisation implemented back to the authorisation objects only, no analysis authorisations. This in turn allowed a technical upgrade project to proceed without including a complete re-write of the security model.
“the first upgrade project should be technical features”
Have a quick think about all the standard features the DataModel implements, specifically in this environment. For Example: ALPHA conversion, Unicode compatibility, delta load queues, system downtime, broadcasting, open hub destinations, InfoSpokes, etc. By now you realise that it will take weeks to create, document and execute the regression tests on all the different types of standard objects and their features used in your DataModel.
The next idea is usually to focus on a few critical DataSets and select only a few test scenarios for the upgrade project team to implement and then get the business personnel to test the final end user reports. The theory being that if the report is ok then the ETL that created it must also be ok. This style of running an upgrade project consumes a lot of business resources and also assumes the business has all the necessary documentation and skills to complete a reporting reconciliation. Do they?
It also means that the development and test systems are usually patched prior to any real regression testing being done by the business. Can your project budget afford to get that far into the project to find out that all is not well?
By involving the business personnel the project team would be able to shift the accountability to them if the project failed. In an Enterprise where the business has 1001+ reporting reconciliation scripts, the time and are happy to do it then this would be the way to go.
Is that really a practical way forward for any Enterprise? No. This is where BW feature testing can save a lot of time and money. Divide the overall objective of an upgrade into two projects; technical and then functional.
“the second upgrade project should focus on
functional features and business processes”
With an upgrade project starting with technical activities, the feature tests are the automated testing of the standard objects and the expected behaviour of their features.
This would require a separate set of programs and function modules in a dedicated name space that does the actual comparison of data in and out of standard objects; Like InfoProviders.
Process chains run through the matrix of possible scenarios. The result is a working DataModel that generates real records in the database using the programs that are the standard objects and their features.
When an upgrade project is using automated feature tests they are able to significantly reduce the involvement of Business personnel whose role is now reduced to double checking reports towards the end of the second upgrade project time line. This leaves the business personnel with:
- More time to get on with their regular duties;
- Minimises the change management scheduling nightmare to book them;
- Less demands for involvement from the upgrade project;
- Reduces the overall upgrade project budget;
- Minimises the internal cross charging between cost centres.
Are you willing to invest in the creation of BW feature tests for standard BW objects to give the business personnel back their precious time?
Further Reading: Aspects of a technical upgrade to NetWeaver BW v7-50.