The low-level test cases should now be organized and assembled in test procedures and / or test scripts.
The term “procedure” is mostly used by the software testing engineers when they are prepared for manual test execution, while the term “script” is mostly used for automatically executable procedures.
The degree of detail in the procedures depends on who will be executing the test. They should therefore always be written with the intended audience in mind. Experienced software testing engineers and people with domain knowledge and knowledge about how the system works will need far less details than “ignorant” software testing engineers. What we need to specify here is the actual sequence in which the test cases should be executed.
The documentation of a test procedure must at least include:
#Unique identification
# Description
# References to high-level test cases and/or to test conditions and/or directly to basis documentation to be covered by the procedure
# An explicit description of the preconditions to be fulfilled before the actual test execution can start
# Included low-level test cases
Intelligent software testing engineers organize their test procedures in such a way that the execution of one test procedure sets up the prerequisites for the following. It must, however, also be possible to execute a test procedure in isolation for the purpose of confirmation testing and regression testing. The prerequisites for a test procedure must therefore always be described explicitly.
Test procedures may be hierarchical, that is “call others,” for example, generic test cases.
The test groups and the specification of their test procedures must be revisited to ensure that they are organized to give a natural flow in the test execution. Remember that the production of the test specification is an iterative process. We need to keep on designing and organizing test cases, test procedures, and test groups until everything falls into place and we think we have achieved the required coverage.
The organization in test procedures could be looked at as the execution schedule. It could be fixed, but it could also be dynamic. For specific purposes, especially for regression testing, some of the test procedures may be selected and reorganized in other execution schedules that fit the specific software testing purpose. A test procedure should not include too many or too few test cases - a maximum of 20 test cases and a minimum of 2 to 4 test cases is a good rule of thumb.
The test procedure may also include facilities for logging the actual execution of the procedure.
There are many ways to lay out the specification of test procedures and test cases. It is a good idea to set up a template in the Software Testing and development organization.
The term “procedure” is mostly used by the software testing engineers when they are prepared for manual test execution, while the term “script” is mostly used for automatically executable procedures.
The degree of detail in the procedures depends on who will be executing the test. They should therefore always be written with the intended audience in mind. Experienced software testing engineers and people with domain knowledge and knowledge about how the system works will need far less details than “ignorant” software testing engineers. What we need to specify here is the actual sequence in which the test cases should be executed.
The documentation of a test procedure must at least include:
#Unique identification
# Description
# References to high-level test cases and/or to test conditions and/or directly to basis documentation to be covered by the procedure
# An explicit description of the preconditions to be fulfilled before the actual test execution can start
# Included low-level test cases
Intelligent software testing engineers organize their test procedures in such a way that the execution of one test procedure sets up the prerequisites for the following. It must, however, also be possible to execute a test procedure in isolation for the purpose of confirmation testing and regression testing. The prerequisites for a test procedure must therefore always be described explicitly.
Test procedures may be hierarchical, that is “call others,” for example, generic test cases.
The test groups and the specification of their test procedures must be revisited to ensure that they are organized to give a natural flow in the test execution. Remember that the production of the test specification is an iterative process. We need to keep on designing and organizing test cases, test procedures, and test groups until everything falls into place and we think we have achieved the required coverage.
The organization in test procedures could be looked at as the execution schedule. It could be fixed, but it could also be dynamic. For specific purposes, especially for regression testing, some of the test procedures may be selected and reorganized in other execution schedules that fit the specific software testing purpose. A test procedure should not include too many or too few test cases - a maximum of 20 test cases and a minimum of 2 to 4 test cases is a good rule of thumb.
The test procedure may also include facilities for logging the actual execution of the procedure.
There are many ways to lay out the specification of test procedures and test cases. It is a good idea to set up a template in the Software Testing and development organization.
No comments:
Post a Comment