Software reviews are a "filter " for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors that can then be removed. Software reviews serve to "purify" the software work products that occur as a result of analysis, design, and coding.
Any review is a way of using the diversity of a group of people to:
1. Point out needed improvements in the product of a single person or a team;
2. Confirm that parts of a product in which improvement is either not desired, or not needed.
3. Achieve technical work of more uniform, or at least more predictable quality that can be achieved without reviews, in order to make technical work more manageable.
There are many different types of reviews that can be conducted as part of software- engineering like
An informal meeting if technical problems are discussed
1. A formal presentation of software design to an audience of customers, management, and technical staff is a form of review.
2. A formal technical review is the most effective filter from a quality assurance standpoint. Conducted by software engineers for software engineers, the FTR is an effective means for improving software quality.
To illustrate the cost impact of early error detection, we consider a series of relative costs that is based on actual cost data collected for large software projects.
Assume that an error uncovered during design will cost 1.0 monetary unit to correct. Relative to this cost, the same error uncovered just before testing commences will cost 6.5 units; during testing 15 units; and after release, between 60 and 100 units.
A defect amplification model can be used to illustrate the generation and detection of errors during preliminary design, detail design, and coding steps of the software engineering process.
To conduct reviews a developer must expend time and effort and the development organization must spend money. However, the results of the presiding example leave little doubt that we have encountered a "Pay now or pay much more later" syndrome.
TEST CASE DESIGN
TEST CASE DESIGN TWO
DESIGN OF TEST CASES PART THREE
TEST CASE DESIGN PART THREE
TEST CASE DESIGN PART FOUR
TEST CASE DESIGN PART FIVE
TEST CASE DESIGN PART SIX
TEST CASE DESIGN PART SEVEN
TEST CASE DESIGN PART EIGHT
TEST CASE DESIGN PART NINE
REVIEWS AND APPROVAL OF TEST CASES
WRITING SOFTWARE TEST CASES PART ONE
WRITING SOFTWARE TEST CASES PART TWO
WRITING SOFTWARE TEST CASES PART THREE
WRITING SOFTWARE TEST CASES PART FOUR