ISTQB CTFL · FOUNDATION LEVEL

Static Testing

Complete Chapter 3 study notes covering static testing basics, static analysis, reviews, stakeholder feedback, the review process, review roles, review types, success factors, and the book’s additional review-techniques section.

Chapter 32 Core SectionsInteractive Explorer8 Knowledge Checks

SDLC

Chapter map

3.1

Static Testing Basics

Static testing evaluates a work product without executing the test item. It can be applied to executable and non-executable work products and supports quality improvement, defect detection, and evaluation of readability, completeness, correctness, testability, and consistency.

Static Analysis

Usually tool-supported analysis of formally structured work products. Examples include code measurement, control-flow analysis, data-flow analysis, type compatibility checks, and coding-standard checks.

Reviews

People examine a work product to identify defects, questions, improvements, and quality concerns. Reviews are the chapter’s main focus.

3.1.1 Work Products Examinable by Static Testing

Reviews can be applied to virtually any work product that participants can read and understand. Examples include specifications, epics and user stories, acceptance criteria, architecture designs, source code, testware, manuals, websites, contracts, plans, schedules, and budgets.

Technique	Suitable work products	Important condition
Review	Virtually any understandable work product	Reviewers must be able to read and analyze it meaningfully
Static analysis	Code, formal models, structured requirements, and analyzable text	A formal or machine-checkable structure is normally required

3.1.2 Value of Static Testing

Static testing can expose problems early, before they propagate into later work products. It can detect design and architectural defects, unreachable or unused code, documentation defects, ambiguities, contradictions, omissions, redundancies, inconsistencies, and deviations from standards. Earlier detection can reduce later dynamic-testing, maintenance, and field-failure costs while improving communication and shared understanding.

Cost-of-quality example: the chapter’s simulation starts with 130 defects. Without static testing, total quality cost is $682,800 and 26 field defects remain. With static testing before dynamic testing, total quality cost is $625,900 and 13 field defects remain—a modeled saving of $56,900 (about 8.3%).

3.1.3 Differences Between Static Testing and Dynamic Testing

Static testing	Dynamic testing
Does not execute the test item	Requires execution of running software
Can find defects directly in a work product	Often observes a failure first, then debugging locates the defect
Can examine non-executable work products	Applies to executable/running work products
Strong for consistency and internal quality	Strong for externally visible behavior
Useful for requirements/design defects, unreachable code, standards and traceability gaps	Useful for runtime-dependent issues such as memory leaks and performance

Remember: static and dynamic testing are complementary. Both aim to evaluate quality and identify defects as early as possible, but they expose different kinds of problems.

3.2

Feedback and Review Process

3.2.1 Benefits of Early and Frequent Stakeholder Feedback

Early and frequent feedback helps teams detect quality issues quickly, reduce misunderstandings, respond to changing requirements, prioritize high-value functionality, and keep implementation aligned with stakeholder expectations. The chapter’s Figure 3.3 contrasts rare feedback, where implementation drifts far from the customer’s vision, with frequent feedback, where smaller corrections keep the two closely aligned.

3.2.2 Review Process Activities

1Planning
Define scope, purpose, work products, quality characteristics, effort, timing, review type, participants, roles, checklists, and—when formal—entry/exit criteria.

2Review initiation
Distribute the work product and supporting material, explain scope and roles, answer questions, and ensure participants are ready.

3Individual review
Reviewers examine the work product and record comments, questions, recommendations, concerns, and anomalies.

4Communication and analysis
Analyze reported anomalies, distinguish defects from false positives, assign actions, and evaluate the work product against exit criteria.

5Fixing and reporting
Defects are corrected, fixes are confirmed, measures may be collected, exit criteria checked, and a review report produced.

3.2.3 Roles and Responsibilities in Reviews

Role	Principal responsibility
Manager	Decides/schedules the review, allocates staff, budget and time, monitors cost-effectiveness, and takes control decisions.
Author	Creates the work product and removes defects where necessary.
Moderator / facilitator	Ensures smooth meetings, mediates disagreements, and supports a safe atmosphere of trust and respect.
Scribe / recorder	Records anomalies, new potential defects, and meeting decisions.
Reviewer	Examines the work product and identifies potential defects from relevant viewpoints.
Review leader	Has overall responsibility for the review process and organizes participation, place, date, and meetings.

3.2.4 Review Types

Type	Formality	Key characteristics
Informal review	Informal	No defined process; formal documentation not required; often buddy checks or pair reviews.
Walkthrough	Informal → formal	Usually led by the author; individual preparation optional; can use scenarios, dry runs, or simulations.
Technical review	Informal → formal	Technically qualified reviewers; seeks consensus and technical decisions; individual preparation mandatory; meeting optional and facilitated if held.
Inspection	Formal	Defined rules, roles, checklists, entry/exit criteria, mandatory preparation, documented results, and measurements used for process improvement.

A work product may undergo more than one review type. Any type can be implemented as a peer review. The appropriate level of formality depends on context such as SDLC, process maturity, criticality, complexity, regulatory requirements, audit needs, risks, resources, domain, and culture.

3.2.5 Success Factors for Reviews

Clear purpose

Define measurable objectives and exit criteria; choose a review type and techniques appropriate to the goal and work product.

Prepared participants

Schedule reviews early, give reviewers sufficient preparation time, and provide training where needed.

Right perspectives

Include people whose skills and viewpoints support the review objectives, including testers when their perspective adds value.

Healthy culture

Use small review units, objective defect handling, good moderation, mutual trust, and results that are not used to evaluate participants.

3.2.6 (*) Review Techniques

Book note: this subsection is retained as useful additional material but is explicitly marked as not examinable for the Foundation Level v4.0 syllabus.

Technique	How it works
Ad hoc review	Unstructured review with little guidance; effectiveness depends strongly on reviewer skill.
Checklist-based review	Reviewers systematically check selected defect/risk items; checklists should stay focused and current.
Scenarios and dry runs	Reviewers step through scenarios or manually simulate behavior to check whether functionality and exceptions are represented correctly.
Role-based review	Reviewers examine the product from particular stakeholder/user roles or personas.
Perspective-based reading	Different reviewers adopt different stakeholder perspectives and try to use the work product to produce something relevant, such as draft acceptance tests.

Role-based vs perspective-based: role-based review changes the types of users while the task remains broadly the same; perspective-based reading changes stakeholder perspectives or the kinds of tasks performed.

G

Interactive Explorer

H

Key Takeaways

Static ≠ execution

Static testing evaluates work products without running the test item.

Find defects early

Reviews and static analysis can expose defects before they propagate and become more expensive.

Know the five review activities

Planning → initiation → individual review → communication/analysis → fixing/reporting.

Know the four review types

Informal review, walkthrough, technical review, and inspection differ mainly in purpose, preparation, roles, documentation, and formality.

I

Knowledge Check

Test your understanding with all 8 Chapter 3 sample questions from the attached chapter. Choose one answer for each question.

Score: 0 / 8

Question 3.1

Your organization has just prepared an official document describing how reviews should be performed in the organization.

Can this document be reviewed?

A. Yes, because any human-understandable document can be static tested. B. No, because we would have to apply the rules described in this document to itself during the review. C. No, because the document is not a work product of either the testing process or the development process. D. No, because reviews can only be done for specifications and source code.

Question 3.2

While analyzing the code, the tester noticed that the cyclomatic complexity of one of the code components was very high. The tester passed this information to the developers, who refactored the code, making it more readable and testable. This scenario shows the benefit of using:

A. Dynamic testing. B. Static testing. C. Test management. D. Formal test technique.

Question 3.3

What is the difference between static and dynamic techniques, due to the purpose of these techniques?

A. Static techniques directly detect failures, while dynamic techniques directly detect defects. B. Static techniques are typically used early in the SDLC, while dynamic techniques are typically used in later phases of the SDLC. C. There is no difference, as both types of techniques aim to detect defects as early as possible. D. Static techniques usually require programming skills, while dynamic techniques usually do not.

Question 3.4

Consider the following statements about early feedback.

i. Early feedback gives developers more time to produce new features of the system, as they spend less time on modifying the features planned in a given iteration.
ii. Early feedback allows agile teams to deliver the features with the greatest business value first, as the customer’s attention remains focused on the features most important from the customer’s point of view.
iii. Early feedback reduces the overall cost of testing because it reduces the amount of time testers need to test the system.
iv. Early feedback increases the likelihood that the system produced will be close to customers’ expectations, since they have the opportunity to make changes during each iteration.

Which of these statements are true?

A. (i) and (iv) are true; (ii) and (iii) are false. B. (ii) and (iii) are true; (i) and (iv) are false. C. (ii) and (iv) are true; (i) and (iii) are false. D. (i) and (iii) are true; (ii) and (iv) are false.

Question 3.5

Which of the following is part of the review initiation phase?

A. Selecting who will participate in the review. B. Collecting metrics. C. Answering participants’ questions about scope, goals, process, roles, and work products. D. Identifying the scope of work, including the type of review and the documents (or parts thereof) that are the subject of the review and the quality characteristics to be assessed.

Question 3.6

Which role is responsible for the smooth running of the review meeting?

A. Review leader. B. Moderator. C. Author. D. Reviewer.

Question 3.7

Over the past few days, the team has been trying to find the cause of a strange system failure. Since they could not figure out the cause, the team decided to “simulate the computer” by manually executing the code line by line to understand what exactly the program was doing and thus discover the cause of the software’s strange behavior.

What type of review will be most appropriate for this activity?

A. Inspection. B. Informal review. C. Technical review. D. Walkthrough.

Question 3.8

Inspection will be better carried out if:

A. Its main purpose will be defined as “evaluation of alternatives”. B. The manager will attend review meetings. C. Reviewers will be trained to conduct reviews. D. Metrics will not be collected throughout the review process.

ISTQB CTFL • Static Testing • Interactive Self-Study Guide