Why using the SolMan test suite makes sense

MS Office programs such as Excel are often used to create and execute test cases. This may still be manageable for a small number of test cases and testers, but after that the maintenance effort becomes too high. In addition, an integrated error management is missing.

Fast and stress free

So why not use a test case catalog in Excel as a basis and switch to SAP Solution Manager? If you master the following tricks, you can prepare the tests faster and perform them with less stress. 

For example, the test cases defined by the business unit for checking the required functions must be uploaded initially. The preparatory measures for uploading the test case files take place in the solution documentation, not in the test-suite. Users can use a folder structure before test cases are uploaded at the scenario level. Prioritization is also possible here. The determination of the document type should be consistent in order to be able to select the test cases later in the test plans.

Test plan, test package, test case

After the upload in the solution documentation, the further preparations are made in the test plan management of the test suite. The hierarchy according to which these are to take place is prescribed in the test-suite and is thus processed in sequence. At the top level of test plan management, general settings must be made and all relevant test cases selected. A test plan can only be edited by one person at a time. If the content of a test plan makes sense, it is advisable to split it into several plans - also for controlling the test release. A test plan can contain any number of test packages and any number of test cases can be assigned to a test package. In order to maintain a good overview, it is recommended to delimit the test packages in terms of content and not to let the number of assigned test cases get out of hand. In SolMan it is advantageous that test cases can be used in several test packages. This is particularly practical for test cases that describe basic functions. At the same time, however, a warning appears if a test case is not used in any test package. 

Any number of test persons can be assigned at the test package level. However, not all of them have to execute the test cases. The testers can see in the overall status which test cases are already being processed or even completed by another person. Provided that the test cases are not connected in series, they can be freely selected by the testers. If several people have performed the same test case with different results, the worst-wins principle takes effect in the overall status. As a test manager, caution is advised here: The status "in progress" beats the status OK. If a test case is in progress, it must also be completed.

The test suite does not offer the convenience of conventional test management or application lifecycle management tools, but it is usually license-free for SAP customers and easy and quick to implement. One thing is certain: testers will accept SolMan and its test suite well, and the advantages over tools such as Excel will outweigh the disadvantages. The use is particularly worthwhile, since test case execution and defect creation are intertwined. Less intuitive in handling are the analysis options for test progress and defect situation. However, their presentation and processing are useful for a short-term overview.

A final tip: For a status report, it is advisable to take the data as a basis and use your own representation. Especially when the status of several test plans is of interest, the test suite weakens. If you are interested in all test result documents from a test, you have to download them individually, because the test suite does not offer a comprehensive download.