Walkthroughs and inspections are formal manual techniques that are a natural evolution of desk checking. Both procedures require a team, usually directed by a moderator. The team includes the developer, but the remaining members and the moderator should not be directly involved in the development effort.
Both techniques are based on a reading of the product (e.g., requirements, specifications, or code) in a formal meeting environment with specific rules for evaluation. The difference between inspection and walkthrough lies in the conduct of the meeting. Both methods require preparation and study by the team members, and scheduling and coordination by the team moderator.
Inspection involves a step-by-step reading of the product, with each step checked against a predetermined list of criteria. These criteria include checks for historically common errors. Guidance for developing the test criteria can be found elsewhere. The developer is usually required to narrate the reading product. The developer finds many errors just by the simple act of reading aloud.
Walkthroughs differ from inspections in that the programmer does not narrate a reading of the product by the team, but provides test data and leads the team through a manual simulation of the system. The test data is walked through the system, with intermediate results kept on a blackboard or paper.
The test data should be kept simple given the constraints of human simulation. The purpose of the walkthrough is to encourage discussion, not just to complete the system simulation on the test data. Most errors are discovered through questioning the developer's decisions at various stages, rather than through the application of the test data.
At the problem definition stage, walkthrough and inspection can be used to determine if the requirements satisfy the testability and adequacy measures as applicable to this stage in the development. If formal requirements are developed, formal methods, such as correctness techniques, may be applied to ensure adherence with the quality factors.
Walkthroughs and inspections should again be performed at the preliminary and detailed design stages. Design walkthroughs and inspection will be performed for each module and module interface. Adequacy and testability of the module interfaces are very important. Any changes that result from these analysis will cause at least a partial repetition of the verification at both stages and between the stages. A reexamination of the problem definition and requirements may also be required.
Finally, the walkthrough and inspection procedures should be performed on the code produced during the construction stage. Each module should be analyzed separately and as integrated parts of the finished software.
Related Posts
White and black box testing
TESTING CONSTRAINTS PART TWO
LIFE CYCLE TESTING
TEST METRICS
Independent Software Testing
Test Process
Testing verification and validation
Functional and structural testing
Static and dynamic testing
V model testing
Eleven steps of V model testing
Structural testing
Execution testing technique
Recovery Testing technique
Operation testing technique
Compliance software testing technique
Security testing technique
Both techniques are based on a reading of the product (e.g., requirements, specifications, or code) in a formal meeting environment with specific rules for evaluation. The difference between inspection and walkthrough lies in the conduct of the meeting. Both methods require preparation and study by the team members, and scheduling and coordination by the team moderator.
Inspection involves a step-by-step reading of the product, with each step checked against a predetermined list of criteria. These criteria include checks for historically common errors. Guidance for developing the test criteria can be found elsewhere. The developer is usually required to narrate the reading product. The developer finds many errors just by the simple act of reading aloud.
Walkthroughs differ from inspections in that the programmer does not narrate a reading of the product by the team, but provides test data and leads the team through a manual simulation of the system. The test data is walked through the system, with intermediate results kept on a blackboard or paper.
The test data should be kept simple given the constraints of human simulation. The purpose of the walkthrough is to encourage discussion, not just to complete the system simulation on the test data. Most errors are discovered through questioning the developer's decisions at various stages, rather than through the application of the test data.
At the problem definition stage, walkthrough and inspection can be used to determine if the requirements satisfy the testability and adequacy measures as applicable to this stage in the development. If formal requirements are developed, formal methods, such as correctness techniques, may be applied to ensure adherence with the quality factors.
Walkthroughs and inspections should again be performed at the preliminary and detailed design stages. Design walkthroughs and inspection will be performed for each module and module interface. Adequacy and testability of the module interfaces are very important. Any changes that result from these analysis will cause at least a partial repetition of the verification at both stages and between the stages. A reexamination of the problem definition and requirements may also be required.
Finally, the walkthrough and inspection procedures should be performed on the code produced during the construction stage. Each module should be analyzed separately and as integrated parts of the finished software.
Related Posts
White and black box testing
TESTING CONSTRAINTS PART TWO
LIFE CYCLE TESTING
TEST METRICS
Independent Software Testing
Test Process
Testing verification and validation
Functional and structural testing
Static and dynamic testing
V model testing
Eleven steps of V model testing
Structural testing
Execution testing technique
Recovery Testing technique
Operation testing technique
Compliance software testing technique
Security testing technique
No comments:
Post a Comment