We’ve established previously that our definitions include scenarios, processes, and components, and that these definitions tie in with SAP Solution Manager and can also map with modelling process levels. These definitions also (helpfully) map to HP ALM. In order to see how they map, we can take a look at the structure of both HP ALM and our scenario.
HP ALM Modules
The Testing section of HP ALM provides three modules for setting up our scenarios: Business Components, Test Plan, and Test Lab:
Business Components is where we can store the lowest level of detail – the test component or transaction. Each component only needs to be created once (plus additional instances for variations) and can then be reused in different processes.
Test Plan is where we create and store the processes. This is where we can group one or more transactions into process flows. Again, each process flow only needs to be created once (plus additional instances for variations) and can then be reused in different scenarios.
Test Lab is the test execution module of HP ALM. We set up end to end scenarios (Test Sets) using combinations of processes that can then be executed by the testers and end users.
SAP Business Scenario
As an example of a business scenario and the various components and processes, we can look at a standard Order to Invoice business scenario:
Here we can see that the individual transactions are listed as business components, that the components/transactions are grouped into like business processes, and overall the end to end process flow is the business scenario.
We can now set up our reusable items in the Business Components and Test Plan modules to create our end to end scenario.
HP ALM SAP Business Scenario Setup
In order to organise our HP ALM project a little better, we’ll need to set up folder structures in the modules first. We can set up our folder taxonomy any way we choose as long as it’s understandable and relates to the context of the project.
For the Business Components module we’re creating test components based on SAP transactions, so it makes sense to structure our folders based on transactional areas – perhaps by functional areas such as Order to Cash, Procure to Pay, etc but this does tend to create additional complexity in cross-functional areas (depending on your project Credit Management may sit under O2C or it may sit under Finance, for example). An alternative would be to arrange your transactions by SAP module or component:
For our purposes I’m going to keep it simple and organise them alphabetically by their transaction codes:
Notice in the screenshot that I’ve got a user-defined field in Customization to hold the transaction code so that we can search the components more easily:
Tip: In the screenshot above, the user-defined field is a drop-down list. I’ve set up a project list with all required SAP transactions in it so that the field selection is more accurate. If you do this in your project you might want to note:
- Not all SAP transactions will be required in the list. Use your implementation project’s Business Process Master List (BPML) or security role matrix to only load the transactions being used in your implementation.
- There are tools available to bulk load a list into the Customize module so you don’t have to add a thousand+ transaction codes manually.
- You’ll also need to create a list item for non-SAP components, for example where there are interfaces to non-SAP systems that you need to add steps in your scenario for. This can be easily handled by including a “non-SAP” list node and adding your external applications as list items under the node.
- Be aware that your project will likely have “Z” tcodes that have been customised for your project; some maintenance may be required in the HP ALM list as your project blueprint is closed out and the final transaction codes are defined.
Once the transactions are loaded in the Business Components module, we can create business processes in the Test Plan module. Again we need a folder structure – this can be the same or a different folder structure to the components. As these are business processes alphabetical doesn’t make much sense here so we’ll base it on functional areas. The Test Case itself is created with the Type BUSINESS-PROCESS, which then allows us to select the relevant components from the Business Components module:
Finally,the Test Lab module is where we are going to create our scenario and record it’s execution. The scenario will be reusable in multiple test phases and for different data sets and plants so I’ll set up a Library folder to store it as a ‘template’ that can be copied down when it needs to be run in test phases. There’s some additional configuration required in ALM to add a user-defined field for a scenario ID (in our case it’s Required and Masked to 4 digits) so that the scenario is more easily identified. The Test Set (Scenario) can then be created by selecting the relevant Test Plan business processes:
And that’s it, the initial setup of our scenario is complete.
|Previous Page - 6.5 Estimate Activity Durations||Next Page - 11.1 Plan Risk Management|