Test Case design for SAP Applications

[Daniel_Enderli]

Introduction

"Developing is creative and testing is destructive" - ​​this is not the case, I would like to highlight this topic with this blog post about test case design. Especially the test case design is a very creative discipline and peppered with some methodology it can be a lot of fun. The creation of test cases for software development projects is a key activity in projects and in operation. Especially for standard software such as SAP solutions, it helps to know the most important cornerstones of test management.

Related to the test case design, the following questions arise:

• When should the test cases be created?


• How can good quality test cases be determined?


• For which test step does it make sense to write or automate test cases?


• When are the test cases ideally executed?


• How test cases can be linked to test data?


• Which tools can be used to manage and execute test cases?

The fundamental test process

I would like to start with the fundamental test process according to the ISTQB standard. The test process defines all phases and activities from test planning to test closing and is the ideal basis to enable an effective test management.

In the phases "test analysis" and "test design", the test basis is identified, as well as the test objects which are relevant to design the test cases.



Source: Own illustration, in reference to ISTQB.org

 

Methods for test case identification

For the creation of test cases, there are various methods that can be used. In principle, the procedures can be subdivided into the two categories "Blackbox" and "Whitebox".

In particular, I recommend the following three methods for SAP solutions:

• Equivalence class based procedures (build larger classes, for example, to test per material type rather than each individual material).


• Decision table based procedures (eg create, change, delete business partners).


• Use case based procedures (derived from the requirement, from process diagrams or user stories create test cases).

Source: Own illustration, in reference to ISTQB.org

 

Test levels in a waterfall model

In the waterfall process model, there is an associated test level for each specification level. This ensures that each specification level is covered with test cases and reviewed. In the context of SAP, I have allowed myself to take the V-model as a basis and to easily adapt it to the SAP world by inserting the functional tests at process step / function level. This is also the first formal test level after the development or customization is finished and the unittest is done.



Source: Own illustration, for the context SAP, based on V-Modell 97/V-Modell XT

 

Test levels in the agile model

In the agile model, the test levels are used during each sprint and each release in shorter cycles than in the waterfall process model. Automation of test cases at unittest level is essential to test the developed product increment or build. From personal experience, it makes sense to focus on the newly developed functions during a sprint. Towards the end of the sprint or directly after it, the focus should then be on integration tests and regression tests, which check the newly developed functionalities in the overall context of the product and the system.

An agile process model in the context of SAP places high demands on the product owners, architects, developers and test manager, because the user stories have to be defined so finely granular and independent of each other that they can be realized and tested in a sprint. In other words, a strict rethinking is necessary in order not to realize the complete business blueprint from the beginning, but rather iteratively individual components (product increments), which will then be expanded further in later sprints.



Source: Own illustration, in reference to Objektspektrum, s-lab and Scrum

 

The four test quadrants for agile testing

Even in an agile approach, a variety of quality features must be assessed. The following illustration shows in four quadrants which tests are appropriate for the dimensions "Business and Technology" and "Team and Product". The quadrants also illustrate which test cases are more useful for the scrum team and which test cases are more focused on the product and its environment.

As a good practice, 1-2 test procedures should be selected in an agile model from each quadrant. I particularly recommend here:

• Functional Tests


• Exploratory Tests


• User Acceptance Tests


• Plus depending on the circumstances, suitable non-functional tests such as load & performance tests

Source: Test quadrants after Crispin / Gregory

 

Test objects

The objects to be checked are called test objects. These have different relationships to other objects and elements in the software development process. The following illustration shows these relationships.



Source: Own illustration

 

Test Case Design

Now let's look in detail about the test case design and how test cases should be described.

• The level of detail of a test case should be chosen so, that a qualified person from the same team can also perform the test case.


• The number of steps per test case should be limited to 15-20 steps. Longer test cases have to be subdivided into further test cases. As a result, a test case can be executed in the foreseeable future and, above all, completed. It also makes it easier to link simple defects to a test case.


• It is very helpful to add the business role to the description of the test case. That shows, which business role is responsible to execute the test case or the relevant test steps.

The test cases at least should have the following elements included:



Source: Own illustration

 

First example of a simply described test case with test steps:



Source: Test Steps Designer from SAP Solution Manager 

 

Second example of a detailed described test case with test steps:



Source: Test case inside SAP Solution Manager 

 

Conclusion

Regardless of whether a waterfall or agile model is used for the project, it is important to start with the test process early. Even during the specification phase, test cases can be identified.

Specially in agile models test cases can easy be identified from the acceptance criterias of each user story.

It is important to select the right methods for test case identification to ensure the objectives and quality requirements can be achieved.

The test case procedures can be applied at different test levels to consider different aspects.

It is worth having the test cases reviewed by a second person. As a result, the last ambiguities can be discovered and corrected.

The test cases should be independent of the specific test data whenever possible. The goal must be to use the test cases for multiple test records. The test data can be made available to the testers, for example in the form of an attachment.

The test cases should "live", which means that the test cases must be kept up-to-date and new findings lead into the test cases. For this purpose, an ALM or test management tool such as the SAP Solution Manager in which the test cases can be managed and executed is strongly recommended.