SAP in it’s core state contains pre-made business processes that contains end to end flows. However, in most cases the processes needs to be adjusted or changed to the companies own processes, policies and data structures. All normal testing procedures and methods can be applied within a SAP project and of one them are a classic risk based method to define and communicate the test strategy in your project. We will go through a simple way to conduct a risk based methodology from a high level perspective in this text.
Functions, processes, programs can be analyzed by identifying business critically and technical condition.
When identifying business critically it can be good to quantify it in terms of money, how much something is worth (business value) or how much it costs if it doesn’t work (business disruption costs). As you might need to interview a number of key people who have in-depth knowledge to get that information, it’s a good practice to have a simple classification model, with few choices.
I normally use a simple model that uses the letters A,B and C as classification for business criticality. This can be applied to a analyzing business processes, sub-processes, transaction codes, reports, integrations etc.
A = Over 50K USD in damage (High)
B = Between 1K to 50K (Medium)
C = Below 1K (Low)
This is an information intake that its primarily a task for the business side of the organization/project, but you most likely as a test manager need to drive the activity and to make sure that the persons understand the questions.
For the other parameter for the general risk analysis formula, we usually take in the information from technical side: developers, basis, functional consultants etc.
Key information for this classification can be frequency of use (there are SAP tools available to get this), if the program is standard/modified/new, how large or complex a program is. In SAP programs are usually named transaction codes (T-Codes).
An example for a model for frequency of use could look like:
1. >100K times
2. 10<100K
3. 10
Which degree of standardization of program can have an own table such as below:
a. New
b. Modified
c. Standard
By combining frequency of use and degree of standardization, we could setup a simplified table:
| Standardization/Frequency | a | b | c |
| 1 | HIGH | HIGH | HIGH |
| 2 | HIGH | MEDIUM | LOW |
| 3 | MEDIUM | LOW | LOW |
Please note, in your project you might need to distributes the weights, but above show you a good starting point. By doing this, we now have the possibility to combine the business perspective with the technical using a new table.
| Business/Technical | HIGH | MEDIUM | LOW |
| A | RISK CLASS A | RISK CLASS A | RISK CLASS B |
| B | RISK CLASS A | RISK CLASS B | RISK CLASS C |
| C | RISK CLASS B | RISK CLASS C | RISK CLASS C |
Short list example for Business Processes (called Nx):
Business Process N1: Business rated A & Technical rated MEDIUM = RISK CLASS A
Business Process N2: Business rated C & Tecnical rated MEDIUM = RISK CLASS C
Business Process N3: Business rated B & Tecnical rated MEDIUM = RISK CLASS B
When you have the list complete or nearly complete, you can start define what kind of level of testing, amounts, coverage and types etc. for each class. For an instance for RISK CLASS A classed processes, they might have extensive testing in all phases, using large datasets and to set a strict security and performance regime in the testing.
For RISK CLASS C, you might choose to only do basic positive flow acceptance testing or similar, depending on your system overall criticality in itself for the company. You can also use the above as a template and add or remove testing activities to them in a new table or scope.
As a test manager, you should not try to influence or do the classification yourself. You would like to stay unbiased and conclude your strategy on other peoples competence and information. You can use the same technique to help you get out prioritized testing areas for performance, roles and security, integrations, modules, reports etc.
When you have collected the risk analysis, which might be that you need to do in an iterative way, you can start to break down what kind of testing, resources and competences that are required. When this is gathered in a simple list, you can start change or modify the effort as there might be prioritizes that needs to be taken into account that the above intake didn’t took into account. It’s makes it also much easier to answer questions such as if you can’t afford the all RISK CLASS C areas, how much that would save in time and resources (which is a classic question from the project management).
In the end, this method gives you a good start to conclude your testing scope, strategy and can easily be communicated within and outside the project. In very mature projects, there might have already been a risk based analyses made by the project management, in those (rare) cases, you still need to align and analyze it from a testing perspective.
We will in the next post talk about SAP specific tools that might help you with your test planning or execution.
//Bengt Augustsson
Bengt has worked over 20 years in the testing business and is a co-founder of QualityMinds.