Inspection and Review The main objective of an Inspection or a Review is to Detect Defects. (Today -there may be some other goals or broader definition.

Slides:



Advertisements
Similar presentations
Test Execution and Defect management. 2 Module Objectives Introduction to Test Execution Checklist of Test Execution Defect management Defect Classification.
Advertisements

Damian Gordon.  Static Testing is the testing of a component or system at a specification or implementation level without execution of the software.
Software Project Management Lecture # 11. Outline Quality Management ( chapter 26 - Pressman )  Software reviews  Formal Inspections & Technical Reviews.
Software Quality Assurance Inspection by Ross Simmerman Software developers follow a method of software quality assurance and try to eliminate bugs prior.
Testing Without Executing the Code Pavlina Koleva Junior QA Engineer WinCore Telerik QA Academy Telerik QA Academy.
 Every stage from phase DESIGN in Software Development Process will have “design document” especially in analysis and design phases.  “Design document”
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited Review objectives Formal design reviews (FDRs) Participants Preparations.
OHT 8.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations.
SE 555 Software Requirements & Specification Requirements Validation.
CSC 395 – Software Engineering Lecture 9: Testing -or- How I Stopped Worrying and Learned to Love the Bug.
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
Personal Software Process Overview CIS 376 Bruce R. Maxim UM-Dearborn.
1 Software Inspections and Walkthroughs Author: A. Frank Ackerman Presented by Cynthia Johnson EEL6883.
Design Reviews Peer Reviews. Agenda Peer Reviews Participants of Peer Review Preparation for a Peer Review Session The Peer Review Session Post-peer Review.
OHT 4.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Introduction to Information System Development.
S/W Project Management
Extreme Programming Software Development Written by Sanjay Kumar.
Software Inspections and Walkthroughs By. Adnan khan.
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
Software Testing Lifecycle Practice
Page 1 MODEL TEST in the small GENERALIZE PROGRAM PROCESS allocated maintenance changes management documents initial requirement project infrastructure.
Software Quality Assurance Lecture #4 By: Faraz Ahmed.
Galin, SQA from theory to implementation © Pearson Education Limited 2004 Review objectives Formal design reviews (FDRs) Participants Preparations The.
Software Inspections. Defect Removal Efficiency The number of defects found prior to releasing a product divided by The number of defects found prior.
Software Inspection A basic tool for defect removal A basic tool for defect removal Urgent need for QA and removal can be supported by inspection Urgent.
Formal and Informal Peer Reviews
Phil Cronin Anne Hill Allen Schones CIS841 Summer on Campus 1998 IN-PROCESS INSPECTIONS FOR OBJECT ORIENTED DESIGNS.
Requirement-Related Risks Extracted from the book: Software Requirements By Karl E.Wiegers.
Independent User Acceptance Test Process (IUAT)
Formal Technical Reviews Matt Graham 18 November 2004 EECS 814 University of Kansas.
CHAPTER 9 INSPECTIONS AS AN UP-FRONT QUALITY TECHNIQUE
Software Testing and Maintenance 1 Code Review  Introduction  How to Conduct Code Review  Practical Tips  Tool Support  Summary.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
Unit III Static Testing. static testing Testing of a component or system at requirements or implementation level without execution of any software, e.g.,
Slide 6.1 CHAPTER 6 TESTING. Slide 6.2 Overview l Quality issues l Nonexecution-based testing l Execution-based testing l What should be tested? l Testing.
Approaches to ---Testing Software Some of us “hope” that our software works as opposed to “ensuring” that our software works? Why? Just foolish Lazy Believe.
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
Inspection and Review The main objective of an Inspection or a Review is to detect defects. This activity and procedure was first formalized by Mike Fagan.
© Michael Crosby and Charles Sacker, 2001 Systematic Software Reviews Software reviews are a “quality improvement process for written material”.
How to Build Test Inventory Test inventory is built and updated as the software project moves from phase to phase –Start with Requirements List the actual.
Software Engineering Lecture 8: Quality Assurance.
Advances In Software Inspection
Mahindra Satyam Confidential Quality Management System Software Defect Prevention.
Peer Review Presented by : Basker George. Peer ( 同等的人 ) Review( 回顾 ) During the development of software, defects are inevitably ( 不可避免 ) injected. Defect.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
Software Project Management Lecture # 12. Outline Quality Management ( chapter 26 - Pressman )  SQA  Who does it?  SQA Activities  Software reviews.
Strana 1MBA kurz informačního inženýrství INITIATE CONSTRUCT DELIVER MAINTAIN & SUPORT quality assurance, manage project, trainig&education, manage.
Process Knowledge Playback Maintenance Project Presented By- Alka Mehta(885026) Arpit Saran(838563) Kirti Singh(883796) Kumari Meenu(840291) Rishabh Jha(835286)
Software Quality Control and Quality Assurance: Introduction
Software Engineering (CSI 321)
Approaches to ---Testing Software
Testing Process Roman Yagodka ISS Test Leader.
SEVERITY & PRIORITY RELATIONSHIP
Prologue.
SWE 3643_2016_Lesson_3 PSP Data / Review / Inspection from kindergarten to college SWE 3643 Lesson 3 PSP & Review/Inspection.
SWE 3643_2016_Lesson_3 PSP Data / Review / Inspection from kindergarten to college SWE 3643 Lesson 3 PSP & Review/Inspection.
Engineering Processes
Software Quality Engineering
Inspection and Review The main objective of an Inspection or a Review is to detect defects. (Not for Giving Alternative Solutions) This activity and procedure.
Quality Measurable characteristic Cyclomatic complexity Cohesion
QA Reviews Lecture # 6.
Engineering Processes
Software Testing Lifecycle Practice
Code Reviews Assignment Each team should perform a code review
Software Reviews.
Testing, Inspection, Walkthrough
3. Software Quality Management
Presentation transcript:

Inspection and Review The main objective of an Inspection or a Review is to Detect Defects. (Today -there may be some other goals or broader definition of what a “defect” includes ---- ) This activity and procedure was first formalized by Mike Fagan of IBM during a period when CPU was still much more costly than people, and system complexity increased to the point where software quality became a huge issue. Inspections and reviews are testing of software artifacts without the actual execution of code and is especially suited for : 1.Requirements - documents 2.Design - documents 3.Plans and Tests Cases – documents 4.Customer education material - documents

Inspection may be a Natural Part of Software Development Requirements Analysis Design Code & Manuals Functional Test Component Test System Test Inspect Document Inspect Document Inspect Test Cases Inspect Code & doc. Inspect Test Cases Inspect Test Cases most often used less often used least often used

Introduction to (Inspection/Review) Activity Some Resistance 1.What’s the value? 2.Why so formal? 3.How to include into an already tight schedule? 4.Who should be involved? What do you think ? 1.Compare the cost of bug found by customer ? 2.Would people take this seriously, otherwise? 3.Would code test time decrease enough? 4.How reliable are your “friends?” in telling you the truth?

Introduction of Review/Inspection Activities into Professional Organizations Must have complete “buy-in” --- (how do you do this? - use cost analysis?) –Upper management –Project leaders –Team members Must provide training for inspection/review: –Not natural for people to look for defects ---- we like to show things work Delivering negative comments in a positive fashion –Focus on defects and not just “better” solution –Prioritize the problems and not dwell on minor problems –Agree on defect types, definitions, and severity Reviewers must be “prepared” --- read and understand the material Must keep good records and act on the result

General Review Sub-Process Framework Appoint a moderator Plan and Schedule the Review Conduct the Review & Analyze results Error corrections & ( Rework if needed) Follow-up & (Re-inspection- If needed) Report Final Result(s) rework and re-inspections are optional and needed only if the review results did not meet some prior criteria

Inspection/Review Sub-Process (more details) Assuming no Re-review Appoint moderator Responsible Activity ( almost sequential )“output” Project mgr “responsible/trained” moderator Plan, schedule, organize the review Moderator set review date; review material disseminated; review team organized, review “rules” set; review-checklist (if applicable) and “gols” established Prepare for review Reviewers materials read; organized set of defects found while preparing for the actual review; priorities of found defects set; written down questions for the review Conduct the review Moderator, Reviewers & Review material owner Pre-review: review rules re-explained, Post review: list of “agreed upon” prioritized problems; list of resolved problems; list of questions to be resolved (all lists must be “trackable”) Decision: re-review needed decision–based on goals, problem resolution schedule

Inspection/Review Sub-Process (more details) Fix the defects in the material and provide them to the moderator Responsible Activity“output” review material owner Fixed material Ensures the fixes are indeed correct by having the reviewer “sign off” Moderator & reviewers Prepare the final report and disseminate the final review report Moderator Final review report which contains the “previously agreed upon” statistics from the Review and any recommendation based on the project quality goals. “Signed off” Fixed material

Participants of a Review Author of the material Inspectors : –customer –designer –requirements analyst –programmer –tester –trainer Moderator

Trained Participants Moderator : –schedule and ensure the inspectors are ready for inspection –keep the group to the major task of defect finding –moderate the discussions and keep the activity moving –arbitrate and decide on the defect severity level –record, analyze, and report on the review results (may involve an assistant) –follow up on the review –report on the final result Inspectors: –look for defects first versus look for “best” alternatives –establish what works (not promoted by all practitioners of inspections) –critical with the product, not the person (very hard to do, but must) –participate in deciding on the severity of the defects found –take the inspection result to their own “downstream” domain of activities because buggy areas deserve more attention and preparation

Review Preparations Schedule : –material reading time by the participants –actual inspection time –defect fixing and rework time –follow-up (re-review if necessary) –documenting and reporting on inspection results Defect severity definitions –severity levels and defect types Rework and Re-Inspection guidelines

Review Preparation (cont.) –Review for “defects” How? ( Establish what’s important) –Consider the categories of items that are important (based on goal) Functionality Reliability Usability Performance Security Etc. –Within each category, prioritize the items (e.g.) Functionality –Product Installation : priority 1 –Existence of a specific function or feature: priority 1 –Product displays error messages: priority 2 –Etc. Usability –Tool bar icons: priority 1 –Tool bar icon explanations: priority 1 –Drop down window defaults: priority 1 –Prioritization of Drop down window defaults: priority 3 –Etc. Most do not get this sophisticated

Have an idea of what’s important (problems) Example: Defect Severity levels by problem impact Level 1 : Catastrophic error which causes the whole system to be down and possible loss of life. Level 2 : An error that will cause a major functional failure and there is no work around. Level 3 : An error that will cause a major functional error but there is a manual work around. Level 4 : An error that will cause a minor error or system degradation. Level 5 : A cosmetic level error that may be fixed at the next most convenient time How do these apply to Requirements Review?

Rework and Re-Inspection Guidelines 1.These guidelines must be set ahead of time. 2.What should rework guidelines be ? –All defects found in an inspection should be reworked and fixed? (for what type of products?) –All severity level 1 through level 3 must be reworked and fixed before the inspected artifact may be declared complete. –Should requirements and design artifacts be under a stricter rule ? 3.What should Re-Inspection guideline be ? –Re-inspect the complete artifact if there is “x” number of severity level 1 problems ? –Re-inspect only the rework and fixes for severity 1 and 2 problems ?

What Have We Learned ? 1.Inspections and reviews are expensive and time consuming 2.Inspections and reviews do bring down defect rates and also : –force some discipline into an organization –brings awareness of quality focus –helps in setting milestone marks (inspection exit) 3.Inspection and Reviews should be used selectively –mostly on non-executables –error prone and complex areas –new areas (new functions, new employees, new domain)