Just as Software Engineers produce design documents based on requirements. It is necessary for the Testing Team to design test procedures based on these requirements as well. In some organizations, the development of Test Procedures is pushed off until after a build of the software is delivered to the testing team, due either to lack of time or lack of properly specified requirements suitable for test procedure design.
Moving the Test Procedure Development effort closer to the requirements phase of the process, rather than waiting until the Software Development Phase, allows for test procedure to provide benefit to the requirement specification activity. During the course of developing a test procedure, certain oversights, omissions, incorrect flows, an other errors may be discovered in the requirements document, as Testers attempt to walk through an interaction with the system at a very specific level, using sets of Test Data as input. If a problem is uncovered in the requirement, that requirement will need to be reworked to account for this discovery. The earlier in the process such corrections are incorporated, the less likely it is that the corrections will affect Software Design or implementation.
As I mentioned before, early detection equates to lower cost. If a requirement defect is discovered in later phases of the process, all stakeholders must change the requirement, design, and code, which will affect budget, schedules, and possibly morale. However, if the defect is discovered during the Requirements Phase repairing it is simply a matter of changing and reviewing the requirement text.
The process of identifying errors or omissions in a requirement through test procedure definition is referred to as Verifying the Requirement’s Testability. If not enough information exists, or the information provided in the specification is too ambiguous to create a complete test procedure with its related test cases for relevant paths, the specification is not considered to be testable, and may not be suitable for Software Development. Whether a test can be developed for a requirement is a valuable check and should be considered part of the process of approving a requirement as complete.
If a requirement cannot be verified, there is no guarantee that it will be implemented correctly. Being able to develop a test procedure that includes data inputs, steps to verify the requirement, and known expected outputs for each related requirement can assure requirement completeness by confirming that important requirement is not missing, making the requirement difficult or even impossible to implement correctly and un-testable. Developing test procedures for requirements early on allows for early discovery of non-verifiability issues.
Developing test procedures after a software build has been delivered to the Testing Team also risks incomplete test-procedure development because of intensive time pressure to complete the product’s testing cycle. This can manifest in various ways. For example, the test procedure might be missing entirely, or it may not be thoroughly defined, omitting certain paths or data elements that may make a difference in the test outcome. As a result, defect might be missed, or the requirement may be incomplete, as described earlier, and not support the definition of the Necessary of Test Procedures, or even proper software development. Incomplete requirements often result in incomplete implementation.
Early evaluation of the Testability of an application’s requirements can be the basis for defining a testing strategy. While reviewing the testability of requirements, testers might be determine, for example, that using a capture/playback tool would be ideal, allowing execution of some of the tests in automated fashion. Determining this early allows enough lead time to evaluate and implement automated testing tools.
Moving the Test Procedure Development effort closer to the requirements phase of the process, rather than waiting until the Software Development Phase, allows for test procedure to provide benefit to the requirement specification activity. During the course of developing a test procedure, certain oversights, omissions, incorrect flows, an other errors may be discovered in the requirements document, as Testers attempt to walk through an interaction with the system at a very specific level, using sets of Test Data as input. If a problem is uncovered in the requirement, that requirement will need to be reworked to account for this discovery. The earlier in the process such corrections are incorporated, the less likely it is that the corrections will affect Software Design or implementation.
As I mentioned before, early detection equates to lower cost. If a requirement defect is discovered in later phases of the process, all stakeholders must change the requirement, design, and code, which will affect budget, schedules, and possibly morale. However, if the defect is discovered during the Requirements Phase repairing it is simply a matter of changing and reviewing the requirement text.
The process of identifying errors or omissions in a requirement through test procedure definition is referred to as Verifying the Requirement’s Testability. If not enough information exists, or the information provided in the specification is too ambiguous to create a complete test procedure with its related test cases for relevant paths, the specification is not considered to be testable, and may not be suitable for Software Development. Whether a test can be developed for a requirement is a valuable check and should be considered part of the process of approving a requirement as complete.
If a requirement cannot be verified, there is no guarantee that it will be implemented correctly. Being able to develop a test procedure that includes data inputs, steps to verify the requirement, and known expected outputs for each related requirement can assure requirement completeness by confirming that important requirement is not missing, making the requirement difficult or even impossible to implement correctly and un-testable. Developing test procedures for requirements early on allows for early discovery of non-verifiability issues.
Developing test procedures after a software build has been delivered to the Testing Team also risks incomplete test-procedure development because of intensive time pressure to complete the product’s testing cycle. This can manifest in various ways. For example, the test procedure might be missing entirely, or it may not be thoroughly defined, omitting certain paths or data elements that may make a difference in the test outcome. As a result, defect might be missed, or the requirement may be incomplete, as described earlier, and not support the definition of the Necessary of Test Procedures, or even proper software development. Incomplete requirements often result in incomplete implementation.
Early evaluation of the Testability of an application’s requirements can be the basis for defining a testing strategy. While reviewing the testability of requirements, testers might be determine, for example, that using a capture/playback tool would be ideal, allowing execution of some of the tests in automated fashion. Determining this early allows enough lead time to evaluate and implement automated testing tools.
0 komentar:
Post a Comment