Formal Technical Reviews

FTR is a SQA activity that is performed by software engineers.

Objectives of the FTR are

1. To uncover errors in function, logic, are implementations for any representation of the software.
2. To verify that software under review meets its requirements.
3. To ensure that software has been represented according to predefined standards
4. To achieve software that is developed in an uniform manner
5. To make projects more manageable

In addition, the FTR serves as a training ground, enabling junior engineers to observe different approaches to software analysis, design, and implementation. The FTR also serves to promote backup and continuity because numbers of people become familiar with parts of the software that they may not have other wise seen.

The FTR is actually a class of reviews that include walkthrough inspection and round robin reviews, and other small group technical assessments of software. Each FTR is conducted as meeting and will be successful only if it is properly planned, controlled and attended. In the paragraph that follows, guidelines similar to those for a walk through are presented as a representative Formal technical review.

The Review Meeting

The Focus of the FTR is on a work product - a component of the software.

At the end of review all attendees of the FTR must decide

1. Whether to accept the work product without further modification.

2. Reject the work product due to serve errors (Once corrected another review must be performed)

1. Accept the work product provisionally (minor errors have been encountered and must be corrected but no additional review will be required).

The decision made, All FTR attendees complete a sign-off indication their participation in the review and their concurrence with the review team findings.

Review reporting and record keeping

The review summary report is typically is a single page form. It becomes part of the project historical record and may be distributed to the project leader and other interested parties. The review issue lists serves two purposes.

1. To identify problem areas within the product

2. To serve as an action item. Checklist that guides the producer as corrections are made. An issues list is normally attached to the summary report.

It is important to establish a follow up procedure to ensure that item on the issues list have been properly corrected. Unless this is done, it is possible that issued raised can "fall between the cracks". One approach is to assign responsibility for follow up for the review leader. A more formal approach as signs responsibility independent to SQA group.

Review Guidelines

The following represents a minimum set of guidelines for formal technical reviews

1. Review the product, Not the producer
2. Set an agenda and maintain it
3. Limit debate and rebuttal
4. Enunciate problem areas but don't attempt to solve every problem noted
5. Take return notes
6. Limit the number of participants and insist upon the advanced preparation
7. Develop a check list each work product that is likely to be reviewed
8. Allocate resources and time schedule for FTRs.
9. Conducts meaningful training for all reviewers
10. Review your early reviews

related post

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