review techniques n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Review Techniques PowerPoint Presentation
Download Presentation
Review Techniques

Loading in 2 Seconds...

play fullscreen
1 / 23

Review Techniques - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Review Techniques' - chaviva


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
review techniques
Review Techniques
  • Why Review
  • Review vs Testing
  • Type of Reviews
    • Inspections
    • Walkthroughs
    • Code Reading
    • Pair Programming
quality assurance fundamentals
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!!!
we haven t got time for more testing for review
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 $$$
qa technique 1 testing
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
qa technique 2 reviews
QA Technique 2 - Reviews
  • Find 60 - 90 % of errors
  • Finds them earlier
  • Is 3 - 10 times more cost-effective than testing
some published results
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
personal experience rb
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
extra benefits of reviews
Extra Benefits of Reviews
  • Education - spread skill, experience
  • Promote Standards and Good Practice
  • Assess Quality and Progress
  • Promote teamwork

Reviews apply at all stages

review or testing
Review or Testing?
  • Complementary - Find different types of errors
  • Best results when BOTH used

Detected by Reviews

Detected byTesting

types of reviews
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
inspection roles
Inspection Roles
  • Moderator (Chairman)
  • Author
  • Reviewer. May be several
  • Scribe________________________
  • Management - NO WAY
  • Moderator may be scribe, otherwise no combination of roles
inspection procedure
Inspection Procedure
  • Planning
  • Overview
  • Preparation (eg Code Reading)
  • Inspection meeting
  • Inspection Report
  • Repair
  • Follow up
egos in inspections
Egos in Inspections
  • Style and Opinions
  • How to express comments
  • What about “Suggested Improvements”
the right attitude is vital
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
when to inspect
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

what to inspect
What to Inspect
  • Program Code
  • Specifications?
  • Test Plans?
walkthroughs
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
code reading
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
pair programming
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?
pair programming is it productive
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

pair programming and teamwork
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.
reviewing conclusions
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”.