Dieter SteigerDieter Steiger SAP Process Testing – Gaps to be Closed

01/16/2008 by Dieter Steiger

Theory says that in order for effective business process testing to be done, testing requirements should already be deduced in the requirement’s phase of the software development lifecycle (SDLC). But do SAP users consistently test all the processes that are impacted by changes? Despite obvious consequences, this is hardly ever done.

Process models are not up-to-date
Many SAP users do not take the effort to document their business processes in order to derive quality measures and test definitions. But even when this is done, the focus of the projects is on developing a running system, and the process documentation is not maintained during the projects and are not up-to-date.

When changes are handed over to IT operations, the routine of consistently testing all of the processes to see what is impacted by a change is extremely difficult and time-consuming. Because the link between change and processes is not currently documented, the only choice would be a complete test of all business processes. Hence, if at all, processes are only partially tested. Process testing gets marked as completed just because of the lack of prerequisites for such quality measures. Consequences are fatal. Working systems using the same programs or customizations, suddenly behave differently. Components of homogeneous, but even more so for heterogeneous SAP systems, report errors or stop working.

It is just too laborious, too complex, and is not system supported to completely document systems from the technical objects up to the process level. After some time it becomes nearly impossible to understand why a process has changed or is implemented in a specific way. Developers in new projects, as well as maintenance programmers, are priority driven by their immediate project goals. Long-term system goals for maintainability of the overall application lifecycle are secondary at best.

Business Process Lifecycle Management
Understanding over time why and how processes have changed in a specific way is too hard. In SAP development methodology, a typical SAP Business Blueprint and SAP process model do not care whether individual processes that need delivered or already exist should be changed or be newly developed.
Because it is not distinguished in such a way, it is not possible at this point in time to derive which processes were impacted from a change. Because of this, properly defining what the testing requirements should be becomes impossible. The prerequisites for a complete test will be missing later.

This is not only true for new development. The same drawback exists with support and maintenance programming and disciplines in IT Service Management(ITSM). There is no reference of changes to process objects in their lifecycle.

Projects need to maintain a sustainable lifecycle management for processes. At any time, it is comprehensible which version of a process was caused by which development project or service request, including what objects were impacted in which way. Consequences for later stage process testing in this way are identified early on so testing can be planned properly.

The ideal SAP system initializes business processes with the first project. Every new project or service request, roll-ins, roll-outs, enhancements, or bug fix impacting the business process, generates a new version of it, with proper test requirements that are included and comprehensible.

In order to not let SAP process testing just be a pretense, it is a must that process documentation is maintained throughout all phases of the development cycle by new projects as well as maintenance activities. It needs to be part of the IT organization’s application lifecycle discipline. It is only in this way that the impact of projects on business processes can be understood and business process test requirements can be defined and used for proper SAP testing.

Sphere: Related Content

No TweetBacks yet. (Be the first to Tweet this post)

5 Responses