SAP CML Volume Testing Template

In my previous post: Use Case Template i post about use case template. In this post i'm posting general SAP CML Volume Testing template:

Volume Testing

Duration and Timing:
1. The duration of the volume test strongly depends on the complexity of the tested business scenarios.
2. Planning the timetable for testing.

Test Scenarios and Requirements:
For each of the core business processes, identify the relevant steps and arrange them in several test scenarios. Dependencies between the steps need to be identified and the critical success factors for the steps must be defined.

Test Scenarios:
1
2
3

SAP CML Business Processes for the Test
1. Business Partner
2. Contracts
3. Disbursements
4. Payments

Time Table:
Business Process//Processing Time//Frequency Type// Single user processing time per line

Create BP //15.00-15:30//Daily//Interface, Online//800 ms
Master Data Transfer//22.00-24.00 (Europe) 9.00-17.00 (CT)//Weekly//Interface//800 ms
Create correspondence //07.00-19.00//Daily//Online, Background//400 ms
Create invoice //22.00-01.00//2 per month//Background//150 ms
Create cheque //9.00-10.00//Daily//Background//800 ms
Create PAP //9.00 – 12.00//Daily//Background//600 ms

Implement Test Tools:
Manual Testing or Load Generators

Use Case Template

Use Case Template
Before i explode with template, lets talk first what is Use Case?

Use Case: A use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven hreads through the functional requirements.

There are many different styles and templates for use cases. These elements constitute a reasonable framework for a bare essentials use case.

Name
The name of the use case captures the essence of the use case and provides a recognizable reference for readers. It should also appear on an accompanying use case diagram.
Unique IdentifierThe identifier is often a number, and is essential to requirement traceability. It is used to cross reference requirements to design and test artifacts, and needed to verify delivery of the requirements. The identifier must be unique in both the scope of the project and the scope of the solution.

Brief Description
The description provides an informal, natural language description of the use case and the goal that is being satisfied. Functionality may be implied in this section, but no designs or tests should trace to it. All functionality must be identified in the elements below.

Preconditions
Preconditions describe what must be true for the use case to be triggered or started. They can relate to conditions either within the solution or outside of the solution under study. For example, when withdrawing money from an ATM at a specific bank, the customer must be an existing customer of that bank.

Basic flow of events
The basic flow is the ‘guts’ of the use case and describes the sequence of user to solution interactions and related solution behavior or rules. It is commonly referred to as the "primary scenario" or "happy path." It indicates what happens when there are no exceptions or complications.

Alternative flows
These describe what happens when things don’t follow the "happy path." Called a variation if the flow rejoins the happy path, and an exception where an error occurs, these prevent the actor from achieving their goal.

Post-conditions
Post-conditions are things that are true at the conclusion of a use case. Traditionally, these things are always true, regardless of what path is taken through the use case. If the use case has many alternate flows, there may be several outcomes with different post-conditions. It may be useful to identify post-conditions for the basic flow and each of the alternate flows.
source: www.theiiba.org/