1. Static Technique

2. Static Technique - Review  A way of testing software work products  Program code, requirement spec., design spec.  Test plan, test design, test cases, test script, user guides  Early defect detection and correction of software development  Development productivity improvements, reduce development time, reduce testing cost and time  Fewer defects and improved communication  Reviews, static analysis and dynamic testing have the same objective – identifying defects  Reviews : find the cause of failures (defect) rather the defect themselve  Static analysis : complexity of code, error in statement, missing parameter, Dead code etc.

3. Static Technique - Reviews Static Technique Manual ReviewStatic Analysis Formal Review Informal Review Inspection Technical Review Walkthrough Informal Review

4. Why Review  More efficient detecting defects in review that in dynamic test  Component test period; 2-4 findings per hour  Code review; 6-10 findings per hour  Cost of fixing defects after component test level  10-14 m/h for finding and fixing defects during integration or system test level  1 m/h for finding and fixing defect during Inspection  Time and cost efficiency when quick defect correction

5. Reasons of review  Effective defects detecting  Gaining understanding of documentation  Determining and deciding through the discussion  When auditing is planned  Satisfying requirement or compliance  Needed to be high quality in developing process

6. Review – roles and responsibility  Manager  Decide on the execution of reviews, allocates time in project schedules and determine if the review objectives had been met  Moderator  Leads the review of the document, planning the review and running the meeting and follow-up after meeting  Author  The writer or person with chief responsibility of the document(s) to be reviewed  Reviewers  Checkers or inspectors  Reviewers should be chosen to represent different perspectives and roles in the review process  Scribe (recorder)  Documents all the issues, problems and open points

7. Review Process StepRoleGoal PlanningManagerAssign role, define entry/exit criteria, identify documentation to be reviewd Kick-offModerator Reviewer Author Distribute documentation Explain the goal of documentation and process Check entry criteria for the review PreparationReviewerPrepare about review meeting, try to find possible defects and comments ReviewModerator Reviewer Author/Scribe Recording defects during the review meeting Do not try to solve the problem ReworkAuthorFix the defect found (typically by author) Follow UpModeratorCheck all the defect found fixed, collect metrics and confirm Check the exit criteria for the review.

8. Informal vs. formal review InformalFormal Formal processNoDocumented, defined defect detection process that includes peers and technical experts Main purporseInexpensive way to get some benefit Discuss, make decision, evaluate alternatives, find defects, solve technical problems and check conformance to specifications and standards Participants(optional) pair programming or a technical lead reviewing designs and code Performed as a peer review without management participation Moderator DocumentationOptionalDocumented EffectVary in usefulness depending on reviewer Consistent and quantity effect (when it succeed) Preparation-Pre-meeting preparation others-Ideally led by trained moderator (optional) the use of checklist, review report, list of findings and management participation

9. Types of review – Informal review  No formal process  There may be pair programming or technical lead reviewing designs and codes  Optionally may be documented  May vary in usefulness depending on the reviewer  Main purpose – inexpensive way to get some benefit

10. Types of review – Walkthrough  Meeting led by author  Scenarios, dry runs, peer group  Open-ended sessions  Optionally a pre-meeting preparation of reviewers, review report, list of findings and scribe  May vary in practice from quite formal to very formal  Main purporse : learning, gaining understanding, defect finding

11. Types of review – technical review  documented, defined defect-detection process that includes peers and technical experts;  may be performed as a peer review without management participation;  ideally led by trained moderator (not the author);  pre-meeting preparation;  optionally the use of checklists, review report, list of findings and management participation;  may vary in practice from quite informal to very formal;  main purposes: discuss, make decisions, evaluate alternatives, find defects, solve technical  problems and check conformance to specifications and standards

12. Types of review - Inspection  led by trained moderator (not the author);  usually peer examination;  defined roles;  includes metrics;  formal process based on rules and checklists with entry and exit criteria;  pre-meeting preparation;  inspection report, list of findings;  formal follow-up process;  optionally, process improvement and reader;  main purpose: find defects.

13. Success factors for reviews Each review has a clear predefined objective. The right people for the review objectives are involved. Defects found are welcomed, and expressed objectively. People issues and psychological aspects are dealt with (e.g. making it a positive experience for the author). Review techniques are applied that are suitable to the type and level of software work products and reviewers. Checklists or roles are used if appropriate to increase effectiveness of defect identification. Training is given in review techniques, especially the more formal techniques, such as inspection. Management supports a good review process (e.g. by incorporating adequate time for review activities in project schedules). There is an emphasis on learning and process improvement.