Presentation is loading. Please wait.

Presentation is loading. Please wait.

QA Reviews Lecture # 6.

Similar presentations


Presentation on theme: "QA Reviews Lecture # 6."— Presentation transcript:

1 QA Reviews Lecture # 6

2 What is a Review? “A process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, or other interested parties for comment or approval. Types include code review, design review, formal qualification review, requirements review, test readiness review” IEEE std

3 Purpose of QA Reviews Assure the quality of deliverable before the development process is allowed to continue. Once a deliverable has been reviewed, revised as necessary, and approved, it can be safely used as a basis for further development.

4 Kinds of Reviews Formal
SQA(Technical) and Business (management) reviews are grouped as: Informal Peer desk-check Walk-throughs Formal Inspections

5 Objectives of SQA Reviews?
A meeting conducted by technical people for technical people for: A technical assessment of a work product (improvements, complete, correct,) Ensure that the software conforms to your company’s standards Ensure that any changes to the software are implemented according to procedures and standards Identify any defects early, thus resulting in cost and time savings

6 Objectives of Business Reviews
Validate that the project is making progress according to plan (procedures & policies) Ensure a deliverable is ready for management approval (Correct, complete) Resolve issues that require management’s attention. Identify if the project needs a change of direction (provide required information) Control the project through adequate allocation of resources

7 Guidelines for Reviewers
Be prepared - evaluate product before the review meeting (formal) Review the product, not the producer Keep your tone mild, ask questions instead of making accusations Stick to the review agenda Raise issues, don’t resolve them Avoid discussions of style - stick to technical correctness

8 Review Planning - 1 Distribute review package one week in advance
Document to be reviewed Review agenda Identification of the individual who will manage the agenda and schedule Exit and entrance criteria for the review

9 Review Planning - 2 Names of attendees, their roles and responsibilities Review location Date and time of review List of classifications that will be used for defects discovered (defect type, defect origin, and defect severity) Procedures for handling issues raised during the review and escalation phase

10 Review Meeting - 1 Begins the meeting with an introduction of agenda, people, and description of their roles Proceeds the review to explain the materials, while reviewers raise issues based on advance preparation

11 Review Meeting - 2 When valid problems, issues, or defects are discovered, they are classified according to their origin or severity and then recorded. These are accompanied with the names of individuals who are responsible for resolution Related recommendations are also recorded

12 Decisions at the End of a Review Meeting
All attendees must decide whether to: Accept the product without further modification Reject the product due to severe errors Accept the product provisionally Hold a follow-up review session

13 Review Report - 1 Published report, with approval from all attendees, after a week of the review meeting. Review report consists of Elements review Names of individuals who participated in the review Specific inputs to the review

14 Review Report - 2 List of unresolved items
List of issues that need to be escalated to management Suggested recommendations

15 Rework It is the responsibility of project manager to ensure that all defects identified in the review are fixed and retested

16 Follow-Up During the follow-up, that all inconsistencies identified are resolved and the exit criteria for the review have been met Document lessons learned during the final report also

17 The Inspection Process
Michael fagan developed the inspection process at IBM in the mid-1970s (fagan 1976), And others have extended or modified his methods (gilb and graham 1993). Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans.

18 The Inspection Process - Participants
It involves a small team of trained participants who carefully examine a work product for defects and improvement opportunities. The participants in an inspection should represent four perspectives (wiegers 2002a): The author of the work product and perhaps peers of the author   The author of any predecessor work product or specification for the item being inspected   People who will do work based on the item being inspected   People who are responsible for work products that interface with the item being inspected  

19 The Inspection Process - Roles
Author  the author created or maintains the work product being inspected. The author of an srs is usually the analyst who gathered customer requirements and wrote the specification. During informal reviews such as walkthroughs, the author often leads the discussion. However, the author takes a more passive role during an inspection, the author can listen to the comments from other inspectors, respond to—but not debate—their questions, and think. The author will often spot errors that other inspectors don't see.

20 The Inspection Process - Roles
Moderator the moderator, or inspection leader, plans the inspection with the author, coordinates the activities, and facilitates the inspection meeting. The moderator distributes the materials to be inspected to the participants before the inspection meeting. Moderator responsibilities include starting the meeting on time, encouraging contributions from all participants, and keeping the meeting focused. Reporting the inspection results to management. The moderator follows up on proposed changes to ensure that the defects and issues were addressed properly.

21 The Inspection Process - Roles
Reader  one inspector is assigned the role of reader. During the inspection meeting, the reader paraphrases the srs one requirement at a time. The other participants then point out potential defects and issues. By stating a requirement in his/her own words, the reader provides an interpretation that might differ from that held by other inspectors. This is a good way to reveal an ambiguity, a possible defect, or an assumption.

22 The Inspection Process - Roles
Recorder  the recorder, or scribe, uses standard forms to document the issues raised and the defects found during the inspection meeting. The recorder should review aloud what he wrote to confirm the record's accuracy. The other inspectors should help the recorder capture the essence of each issue in a way that clearly communicates to the author the location and nature of the issue.


Download ppt "QA Reviews Lecture # 6."

Similar presentations


Ads by Google