Category: Testing

  • End of an Exception: Quality Management Integrates SAP

    For testing SAP solutions, we used to depend on experts with specialized ABAP or JAVA know-how. Consistent testing of processes beyond SAP systems was quite a challenge.

    Now SAP offers SAP Quality Center by HP. It enables the customer to integrate SAP testing into a comprehensive Quality Management and testing of his IT organisation. This means that SAP testing is no longer a special discipline within Application Management.

    Through bidirectional integration of SAP Solution Manager and HP Quality Center, the precondition for the HP Quality Center to be used as a central control station for SAP testing – and thus for Test Management – has been created.

    For SAP customers, this provides a simple and intuitive approach to controlled access to HP´s Testing Tools, which HP acquired from Mercury Interactive in 2007. In addition to HP Quality Center, at that time called TestDirector for Quality Center, the tools include HP Quick Test Professional and HP Loadrunner.

    The combination of these tools allows for the test requirements to be directly derived from SAP Business Blueprints and to be used as a basis for creating test cases in HP Quality Center.

    In addition to meeting the requirements for SAP applications, HP Quality Center will make it possible to also include processes, that reach beyond the boundaries of SAP systems, into testing requirements, and to test them comprehensively. Testing teams are enabled to start testing from HP Quality Center, without being dependent on SAP specialists.

    So Requirements Management in IT can be standardized and optimized. A better transparency of testing processes will be achieved. Testing results can be compared and, through this, Compliance risks are minimized. Due to user-friendly Quality Management functions, testing automation and re-usability of the testing cases, time and costs will be saved.

    We may summarize that the integration of SAP “SolMan” and HP Quality Center bridges relevant gaps in Application Management allowing the SAP environment to be embedded into a comprehensive IT-wide Test Management.

  • Application Management Reduces SAP Costs

    In the context of large commercial software installations, the opportunity to reduce costs in the long run – all through the life cycle of the systems – is tremendous. Four fields of Application Management, pragmatically introduced and applied, are able to substantially contribute to this potential benefit.

    Project Portfolio Management
    A consistent Project Portfolio Management (PPM) which considers, evaluates, and releases all changing activities from a business as well as an IT point of view, will concentrate effort and reduce cost. In many cases, changes are evaluated from either business or technical perspective. To get to a comprehensive assessment of change requests by IT – concerning complexity and effects on other business processes or technical components – suitable tools are often missing. As a result, decisions are often based on wrong assumptions, and effort and cost estimates prove to be false.

    Quality Management
    A pragmatic Quality Management, consistently supporting the development process, and realized as an integrated tool, is often missing or insufficiently implemented. Integration of development and quality methods and tools spanning all phases from definition of requirements up to testing, will ensure completeness of testing and, above all, hold the scope of testing activities at a reasonable level. Often, Quality Management fails because the scope of testing cannot be clearly defined. As a result, complete testing gets too laborious and will be left out in parts or even completely. When attempting to put the changes into effect, then, at the latest, there will be undesirable additional costs.

    Environment Protection
    The presumably most difficult issue with large SAP and other packet software installations can generally be referred to as Environment Protection – and it holds the greatest potential for benefit.
    The number of components in modern systems is dramatically growing. The reutilization of customizing settings, data, processes, functions, program components or services helps in the first place to lower development costs. On the other hand, it increases the risk of changes taking effect on various parts of the system, intentionally or unintentionally.

    So how could be made sure that one or more changes at a time will not interfere with other functions that are, at the same time, running or being edited? There are in fact approaches to address this problem by the help of methods and tools. But most of them are to a large extent restricted to the developers´ perspective. They are inadequate for customizing activities, let alone for a business analyst evaluating the effects of changes, which means inadequate on business level. Environment Protection is getting a more and more exigent issue as the amount of internally and externally created services used in the context of SOA (Service Oriented Architectures) is constantly growing.

    Lifecycle Management
    The lifecycle of large applications is not restricted to three or five years. From a realistic point of view, we should rather talk about ten, twenty or more years. And these applications are permanently in a process of change. A consistent Lifecycle Management for all objects, no matter if they are of rather business-related, technical, organizational or descriptive nature or relate to the technical process of their development and operation, is a pressing requirement. The issue is not only relevant for the results of development – how is a result changed over a longer period of time, and for which reason? – but also for the development process itself: What does its realization look like? And, once it is clearly defined, should it repeatedly be carried out in the same way? Changes must be targeted and documented. Useful and reasonable documentation, digitalization, administration, and automation are in demand. This is a promising approach to avoid redundant and unnecessary activities in the context of system change and development.

    Summary
    Application Management projects around SAP and other large packet software installations in all kinds of industries make it obvious that the targeted investment in Project portfolio Management, Quality Management, Environment Protection and Lifecycle Management is profitable.
    With reasonable effort, they produce high benefit all through the lifecycle of the systems. But there is also a short-term advantage, the reduction of errors. Better defined system environments facilitate parallel work on projects. And it will be possible to benefit from prior projects, with respect to development as well as testing and deployment.

    Project work, in particular, clearly shows the high demand for an optimized support of methods and tools in the context of Application Management. In many cases, there is still a great deal of unnecessary manual work done – an issue bearing a great potential for software vendors and at the same time being a challenge for producers of commercial software. In our new beteo mini guides, we present a survey of Application Management tools – not only for SAP systems.

  • SAP Process Testing – Gaps to be Closed

    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.

    Conclusion
    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.