In this entry I’ll pull together a few threads from previous posts (testing, documentation, upgrades and offshore development) and throw in some Solution Manager (SOLMAN) functionality. These pieces can be fitted together to help accelerate a project and testing preparation via use of the SAP Test Workbench.
Nowadays SAP wants you to use SOLMAN to manage your landscape and use it as the main conduit to interact with the mother ship in Walldorf. Lots of SAP installations use SOLMAN as a way to generate developer keys and as a document repository: valid uses, but only a small fraction of the available functionality. Let’s explore some more of that SOLMAN magic.
SAP Business Process Design
An ongoing SAP mantra relates to taking a business process based perspective: rather than look at point functions and optimization of individual steps you take a more holistic view of the entire business process and attempt to optimize the whole. With SOLMAN (and encouraged by SAP) you can take a hierarchical approach from business scenarios to business processes to business process steps. For example, you can have an order-to-cash (OTC) business scenario and within that you have a standard material order fulfillment process made up of several process steps. In SOLMAN you can build a structure that looks something like this:
Within SOLMAN you can identify the specific SAP transactions executed in the steps (both custom and standard transactions). You can attach descriptive documentation at any level, for example, an overview of the OTC business scenarios as executed within your organization. At the business process level you may want to provide one overview of the order fulfillment process for standard material delivery orders, and another for a services order. Finally, at the process step level you can provide details about how a transaction is executed as part of the overall process. These steps don’t have to be SAP transactions: they could be manual offline activities or steps performed in another application. You can also include development objects that have to be incorporated into the process flow.
Here’s the point: laying out the scenarios, processes and steps in SOLMAN creates a structure that can be pulled directly into the SAP test workbench using transaction SWTB_2. This transaction automatically takes your SOLMAN project content and creates test plan content.
SAP Test Plan Content Creation
And what is even better about this step to pull information into the SAP test workbench is that you can pick and chose the elements you want to include in your test plan. Once you have a test plan, you can create test packages with tester assignments and test sequencing. The graphic below shows a test plan structure created automatically based on the SOLMAN project structure shown above.
In this graphic you can see that the transaction codes and the supporting documentation have been pulled into the test plan.
Now that I have my test plan content I can create test packages and assign testers to the packages. In the graphic below you can see four test packages and the assignment of testers.
Now within that test package I can sequence the tests and supporting documentation and assign testers to each step as shown below.
This can be pretty powerful stuff. With some forethought and preparation I can generate a test plan based on the contents of my SOLMAN project. I can pick and chose the pieces I want from SOLMAN to build my test plan content and further pick and chose what I want to include in my test packages.
Now when the project goes into test execution each tester assigned to a test package can execute transaction SWTB_WORK to see all the packages where she/he has been assigned as a tester (see below).
Clicking on a specific package drills in to show the detail test steps, the sequence, the assignments along with other useful information, for example, the status of each test step (see below). Not only is this information all available in one place but the transactions can be invoked by clicking on the check mark and, assuming the correct technical set up, the system will automatically log you on to the test system ready to perform the test.
On top of the test plan preparation and execution the SOLMAN tools also support overall test reporting. The SAP Solution Manager Work Centers transaction (SOLMAN_WORKCENTER) includes some delivered reporting capabilities to allow centralized monitoring of test plan and test package execution for a project.
The reporting allows you see report test status across test packages within a project and supports drill down capability to see the details associated with each test including documentation for test results and any test defects reported.
The SAP SOLMAN tools allow your project to be used as the basis for your test plan content and automatically include your project documentation in your test plan. The inherent integration means that you can use SOLMAN as a document repository for business process design, key decisions, test case identification, etc. and use as much of that as you want when you build your test plan. One source for documentation and information; no need to organize and use different tools.
Clearly the example case I used here is something of a simplification and I am not going to underestimate the thought that needs to go into test planning content, but whichever tool you use for testing you have to put in this effort regardless. I hope this example serves to illustrate some of the capability available in SOLMAN and reveals some of the potential available in the tool.
However a key point to note is that the SOLMAN Test Workbench allows you to build test content, but it does not offer the capability to schedule the tests. Again this is something you need to do regardless of the tool you use.
This blog discussed use of SOLMAN project content to automatically generate test plan content. In my next blog I’ll discuss how you can use template projects to rapidly create implementation projects and save huge amounts of project preparation time.