3. Static Techniques

3.1 Static Techniques and the Test Process

  • Informal review
  • Walkthrough
  • Technical review
  • Inspection

3.1.1 Recognize software work products that can be examined by the different static techniques

  • Any product, development or testing, can be tested via static techniques

3.1.2 Describe the importance and value of considering static techniques for the assessment of software work products

  • test software without executing the code
  • find causes of failures, rather than failures
  • usually used before dynamic techniques
  • complementary to dynamic techniques
  • manual reviews and automated static analysis

3.1.3 Explain the difference between static and dynamic techniques, considering objectives, types of defects to be identified, and the role of these techniques within the software life cycle

  • Static testing finds defects, i.e. causes of failures, whereas dynamic testing finds the failures

Static testing via reviews finds:

  • invalid or incomplete requirements
  • untestable requirements
  • incorrect software/system design
  • incorrect UI designs
  • deviations from regulations or standards

3.2 Review Process


  1. Planning
  2. Kick-off
  3. Individual preparation
  4. Review meeting
  5. Rework
  6. Follow up


  1. Planning
  2. Define entry/exit criteria
  3. Kick-off
  4. Check entry criteria
  5. Individual preparation
  6. Noting incidents
  7. Review meeting
  8. Examine
  9. Rework
  10. Fixing defects
  11. Follow-up
  12. Check exit criteria

3.2.1 Recall the activities, roles and responsibilities of a typical formal review


  1. Planning
    • Moderator assignment
    • Define entry criteri
    • Number of reviewers, size of document, roles for reviewers
  2. Kick-off
    • optional
    • checking that everyone at same level
    • introduction overview of objectives
  3. Preparation: participants review document individually
  4. Review meeting
    • logging
    • discussion
    • decision
  5. Rework
  6. Follow up

Roles and Responsibilities:

  • Moderator
  • Author
  • Scribe/Recorder
  • Reviewers
  • Manager

3.2.2 Explain the differences between different types of reviews: informal review, technical review, walkthrough and inspection

Informal review

  • no process, quick benefit
  • not documented
  • usefulness varies depending on reviewers
  • may be pair programming
  • purpose: inexpensive way to find defects


  • lead by author
  • optional process
  • informal to very formal
  • purpose: establish common understanding and gather feedback about a document

Technical review

  • led by trained moderator
  • mostly follow process
  • vary from quite informal to very formal
  • expert reviewers
  • purpose achieving consensus on technical content of document


  • led by trained moderator
  • most formal
  • purpose: finding defects

3.2.3 Explain the factors for successful performance of reviews

  • Find a champion
  • Pick things which really count
  • Clearly plan and track activities
  • Provide training to participants
  • Manage people issues
  • Follow the rules but keep it simple
  • Continuously improve the process and tools
  • Report results

Another list:

  • Each review has clear objective
  • Right people involved
  • Atmosphere of trus
  • Not used for evaluation of participants
  • Defects found welcomed and expressed objectively
  • People issues/psychological aspects dealt with
  • Checklists/roles used
  • Training given to participants
  • Management support
  • Testers welcome as reviewers
  • Emphasis on learning and process improvement

3.3 Static Analysis by Tools

  • Find defects in software source code and models
  • Can locate defects that are hard to locate in dynamic testing

3.3.1 Recall typical defects and errors identified by static analysis and compare them to reviews and dynamic testing

  • Coding standards: naming conventions and programming rules
  • Code metrics: depth of nesting, cyclomatic complexity, number of lines of code, etc.
  • Code structure: control flow (e.g. unreachable code), data flow (how object state/values change), data structures

3.3.2 Describe, using examples, the typical benefits of static analysis

  • Defect detected prior to test execution
  • Find defects difficult to find via dynamic testing
  • Improves maintainability of code

3.3.3 List typical code and design defects that may be identified by static analysis tools

  • unused variables
  • unreachable code
  • security vulnerabilities
  • coding standard violations
  • syntax issues
  • nesting depth
  • cyclomatic complexity

Cyclomatic complexity:

Hint: the question may number the edges and nodes. You can use both formula below to verify your answer. # means number and decision statements include if and loop statements.

Two formulas:

  • = #edges - #nodes + 2
  • = #decision statements + 1
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License