1 / 23

Review Techniques

Review Techniques. Why Review Review vs Testing Type of Reviews Inspections Walkthroughs Code Reading Pair Programming. Quality Assurance Fundamentals. QA techniques provide critical support for maximum development speed If too many defects -> spend more time fixing than writing.

chaviva
Download Presentation

Review Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Review Techniques • Why Review • Review vs Testing • Type of Reviews • Inspections • Walkthroughs • Code Reading • Pair Programming

  2. Quality Assurance Fundamentals • QA techniques provide critical support for maximum development speed • If too many defects -> spend more time fixing than writing ~ 95% correct is fastest • Later Change is MUCH more expensive • 1 -> 60 Ratio!!!

  3. We haven’t got time(for more testing, for review) • A decision not to focus on defect detection early • is a decision to postpone defect detection until later in the project, • WHEN IT WILL BE MUCH MORE EXPENSIVE IN TIME AND $$$

  4. QA technique 1 - Testing • Unit testing - finds 10-50% of defects • Average 25% • System testing finds 20-60% • Average 45% • Cumulative - usually less than 60% • Finds errors late - when they’re more expensive to fix

  5. QA Technique 2 - Reviews • Find 60 - 90 % of errors • Finds them earlier • Is 3 - 10 times more cost-effective than testing

  6. Some Published Results • 1-line maintenance changes • 55% error -> 2% error • #2, 11 programs, same people • 5 without reviews: 4.5 errors / 100 loc • 6 with reviews: 0.82 errors / 100 loc • Aetna: found 82% of errors using inspections, 25% productivity increase • ATT: 14% productivity increase, 90% defect decrease • JPL estimates $25,000 saving PER INSPECTION

  7. Personal Experience(RB) • Reviewed modules were robust, easy to maintain • Compare -a non-reviewed project was 4 times budget, Acceptance phase took 6 months • (budgeted 1 month) • Many indirect advantages of reviewing • Author more likely to have “Do it right first time” attitude because code will be reviewed by another

  8. Extra Benefits of Reviews • Education - spread skill, experience • Promote Standards and Good Practice • Assess Quality and Progress • Promote teamwork Reviews apply at all stages

  9. Review or Testing? • Complementary - Find different types of errors • Best results when BOTH used Detected by Reviews Detected byTesting

  10. Types of Reviews • Inspections • Formal, Checklists, focus on defect detection, defined roles (at least 3 people), Data collected • Walkthroughs • Less formal, usually hosted by author, emphasis on improvement, learning • Code Reading • Less emphasis on meeting. Can be done remotely • Pair Programming • Continuous review – two programmers work together at one computer

  11. Inspection Roles • Moderator (Chairman) • Author • Reviewer. May be several • Scribe________________________ • Management - NO WAY • Moderator may be scribe, otherwise no combination of roles

  12. Inspection Procedure • Planning • Overview • Preparation (eg Code Reading) • Inspection meeting • Inspection Report • Repair • Follow up

  13. Egos in Inspections • Style and Opinions • How to express comments • What about “Suggested Improvements”

  14. The Right Attitude is Vital! • Too much ego will destroy cooperation • Too little ego (confidence) – uncritical acceptance of others’ views. Quality improvements will be missed. • Vital to have right attitude • Cooperative, value others’ contributions • Objective. Focus on team goal

  15. When to Inspect Who decides? Probably Author Too early - Not enough done to review productively Too late Time has been wasted that review would have saved Too much ego invested Appropriate level of formality Less More

  16. What to Inspect • Program Code • Specifications? • Test Plans?

  17. Walkthroughs • Usually hosted by author • 30-60 minutes • Flexible • When done well:- • slightly less effective than inspections • can be more flexible • When done poorly:- • more trouble than they’re worth

  18. Inspection / Walkthough Comparison

  19. Code Reading • Code passed to reviewers • Reviewed independently, each reviewer notes errors • Meeting reviews error reports, no attempt to go through code line by line • (Meeting may not be necessary) • Author fixes problems

  20. Pair Programming • Two programmers work together at one computer • One codes, the other observes • Popular with eXtreme Programming • If reviewing is good, then more reviewing is better. The extreme – continuous review of everything. • Pair programming sounds inefficient – is it?

  21. Pair Programming – is it productive? • Mostly ad-hoc stories, little good evidence • Study results – initially 40% faster, but 60% increase in resource. After “adjustment period”, results improve - 15% increase in resource compared with programming alone. • Higher quality result. • On this basis, PP is less effective than other inspection techniques, but better than lone programming because of quality increase HOWEVER

  22. Pair Programming and Teamwork • Pair programming may have strong advantages in team building • Anecdotal evidence – Pair Programmers work well as a team, develop the cooperative attitudes essential to making any inspection technique work. • Experienced pair programmers prioritize, and decide which parts to do in pairs, which alone.

  23. Reviewing - Conclusions • Reviewing is the most important single step you can take to improve quality and productivity. • The key to success is a cooperative teamwork attitude • “Our product”, not “Your/My Program”.

More Related