A regression test is intended to ensure, that changes in one part of an existing system do not lead to unwanted effects on other areas. It usually consists of repeating existing test cases that retest the entire system or processes and should be performed after changes have been successfully tested. Typically, regressive testing takes place quite late in the test cycle.
Due to the repetitive nature and frequency of these repetitions, it makes sense to use a formalized or automated procedure for regression testing.
For this purpose, we set up and maintain a "global" test case repository, i.e., a central administration and storage of reusable test cases. Optimally, all parties involved have access.
This repository is the basis for manual as well as automated tests.
A test repository is a collection of test cases for all processes in the system landscape to be regressively tested. Can be used as a scope for all test types and phases. It therefore initially only contains processes that are already used productively.
Depending on the tools used in a company, all test cases are collected in a test case catalog, e.g. in Excel.
Structured according to the requirements:
are useful information and can be stored in the catalog or test cases. The structure and catalog can be extended at any time depending on new requirements.
A reasonable and flexible numbering makes it easier to find, assign and later test the test cases.
The test cases themselves can be stored in a share or/and in the SAP Solution Manager Solution Documentation (test cases or test steps). All test cases should be maintained with the same template or with test case type test steps. This simplifies the maintenance as well as testing.
If you want to plan a regressive test, you can simply collect the test cases from the defined catalogue as required by business, and the same scope can also be used for recurring tests.
For a release, for example, only prio 1&2 test cases can be selected, for a rollout or upgrade project also prio 3&4 test cases. Additional test cases can be easily added as needed. For recurring testing tasks, predefined and coordinated test scopes can be easily created, tested and reported.
The test plans and packages are then created as usual.
With each change introduced into the system, a regressive test may also change, or new ones have to be added, old ones deleted. Time-consuming and unpopular review of test cases should be planned and monitored as an integral part of the test procedure.
During each project/release the business checks whether the existing test cases catalog is still up to date and correspond to the current productive and the changes planned for the project/release (or changes introduced in the meantime) of the processes.
After a release/rollout, the deltas are finally incorporated, and the Test Rep is stored as a new version.
The process should be clearly defined, coordinated with all parties involved and communicated. Responsible contact persons should be appointed for all tasks and areas. Once the initial test repository has been created and the advantages and simplification become clear to all, the future planning of regressive test phases should become much easier and more transparent for all.
Due to the repetitive nature and frequency of these repetitions, it makes sense to use a formalized or automated procedure for regression testing.
For this purpose, we set up and maintain a "global" test case repository, i.e., a central administration and storage of reusable test cases. Optimally, all parties involved have access.
This repository is the basis for manual as well as automated tests.
Objective
A test repository is a collection of test cases for all processes in the system landscape to be regressively tested. Can be used as a scope for all test types and phases. It therefore initially only contains processes that are already used productively.
- Complete: Mapping of all business processes
- Standardised: used as a basis for all test phases in release and rollout projects
- Up-to-date: Changes to and new processes are adopted
Advantages
- High reusability in the context of a wide variety of project types and phases
- Reduction of effort in preparing individual test phases
- Reduction of effort in testing
- Strong standardization of test phases
Realization
Depending on the tools used in a company, all test cases are collected in a test case catalog, e.g. in Excel.
Structured according to the requirements:
- starting with the area, core process and processes
- Priority, test efforts, test relevance for different tests or country
- additional info like Test user, hardware, requirements etc.
are useful information and can be stored in the catalog or test cases. The structure and catalog can be extended at any time depending on new requirements.
A reasonable and flexible numbering makes it easier to find, assign and later test the test cases.
The test cases themselves can be stored in a share or/and in the SAP Solution Manager Solution Documentation (test cases or test steps). All test cases should be maintained with the same template or with test case type test steps. This simplifies the maintenance as well as testing.
If you want to plan a regressive test, you can simply collect the test cases from the defined catalogue as required by business, and the same scope can also be used for recurring tests.
Priority
- Prio1 (very high) Business core processes (max. 5-7 test cases per WS) -
Assessment by risk: which processes cause the highest costs and/or the highest number of employees unable to work in case of failure? Regressive tests: test scope for reality testing and are tested in all project types for assurance before handover to the country
- Prio 2 (high): Business-critical processes
Required for daily warehouse operations, i.e. responsible for regularly used physical processes Relevant for error-free inventory management Prio 1 + 2 test cases covers the test scope for comprehensive assurance of system functions, e.g. when commissioning new warehouses in an existing country
- Prio 3 (medium): All other processes
For rollouts in new countries, a 100% test of the system is required, for which Prio 1-3 as well as specific new developments are tested. When new warehouses are commissioned, these test cases are to be tested optionally to increase safety.
- Prio 4 (low):
ggf. special cases, if applicable
For a release, for example, only prio 1&2 test cases can be selected, for a rollout or upgrade project also prio 3&4 test cases. Additional test cases can be easily added as needed. For recurring testing tasks, predefined and coordinated test scopes can be easily created, tested and reported.
The test plans and packages are then created as usual.
Versioning & Updating
With each change introduced into the system, a regressive test may also change, or new ones have to be added, old ones deleted. Time-consuming and unpopular review of test cases should be planned and monitored as an integral part of the test procedure.
During each project/release the business checks whether the existing test cases catalog is still up to date and correspond to the current productive and the changes planned for the project/release (or changes introduced in the meantime) of the processes.
- For deltas, existing test cases are supplemented, or new ones created and, if necessary, stored separately, e.g., proposals for releases or projects.
- Changes are implemented by the business themselves directly in the Excel and test cases/test steps or will be communicated to the test management.
- New test cases can be created by the business to test developments and changes to a release or project.
- At the end of an integration test phase, a current version of the test repository is stored and serves as a basis for subsequent and future test phases.
After a release/rollout, the deltas are finally incorporated, and the Test Rep is stored as a new version.
Conclusion
The process should be clearly defined, coordinated with all parties involved and communicated. Responsible contact persons should be appointed for all tasks and areas. Once the initial test repository has been created and the advantages and simplification become clear to all, the future planning of regressive test phases should become much easier and more transparent for all.
Key Takeaways
- A test repository can save your teams a lot of time, work and improve the quality of testing.
- A global share with accessibility (read and write) for all participants saves a lot of coordination and mail traffic.
- Establishing this repository is an iterative process requiring input from all project teams/functional areas.
- SAP Managed Tags:
