ISTQB Foundation Level Chapter 3: Static Testing

What this chapter covers

Static testing basics

Static testing can be applied to almost any work product produced during software development, not just code. This includes requirements specifications, user stories, design documents, test plans, test cases, code, and even contracts. You should be able to identify which work products can be examined using static techniques (a K1-level objective): essentially anything written down can be reviewed.

The value of static testing comes from finding defects early and cheaply, often before any code has even been written. A defect in a requirements document, if caught during a review, might take minutes to fix. The same defect, if it makes it into code, test cases, and documentation before being caught, can take much longer to fix and may have already caused other problems downstream. This connects directly to testing principle 3 from Chapter 1 (early testing saves time and money) and the idea of shift left from Chapter 2.

Static testing also finds different kinds of defects than dynamic testing does. Static testing is good at catching things like requirements defects (ambiguity, contradictions, missing information), design defects, coding standard violations, incorrect interface specifications, and security vulnerabilities, often before they could even be detected by running the software. Dynamic testing, by contrast, can only find defects that cause an observable difference between expected and actual behavior when the software runs.

The key difference between static and dynamic testing is not just "before versus after code is written." Static testing examines a work product directly, looking for defects in the product itself, while dynamic testing executes the software and observes its behavior to infer whether defects exist. Static testing can find the cause of a problem directly. Dynamic testing finds a failure and then requires further work (debugging, from Chapter 1) to find the underlying defect.

Feedback and review process

Early and frequent feedback from stakeholders is one of the main benefits of static testing, especially reviews. The earlier a stakeholder can look at a work product and provide input, the earlier any misunderstandings, gaps, or disagreements can be addressed, before they are built into later work products.

The syllabus describes a general review process based on ISO/IEC 20246, with the following activities:

• Planning: defining the scope of the review (what is being reviewed, what quality characteristics will be checked), estimating effort and timeline, defining roles and selecting participants, and defining the entry and exit criteria for more formal review types.
• Initiate the review: distributing the work product and any related materials, and explaining the goals, process, and work products to participants.
• Individual review (preparation): each reviewer examines the work product on their own, noting potential defects, questions, and comments, ahead of any group discussion.
• Issue communication and analysis: discussing logged defects, often in a meeting, with the goal of reaching consensus on what is actually a defect, assigning ownership, and deciding on follow-up.
• Fixing and reporting: the author addresses defects (often outside the review meeting itself), and metrics about the review (such as time spent and number of defects found) are reported for process improvement purposes.

Several roles are involved in a review, and you should be able to compare them (a K1-level objective):

• Author: the person who created the work product being reviewed.
• Management: decides whether reviews will be performed, allocates time and resources, and monitors the cost-effectiveness of the review process.
• Facilitator (often called moderator): ensures the review runs effectively, often mediating between different viewpoints, and is sometimes the same person as the author in informal reviews.
• Review leader: takes overall responsibility for the review, including planning and follow-up.
• Reviewers: individuals who examine the work product and identify potential defects, often chosen for different perspectives or areas of expertise.
• Scribe (or recorder): collates and records the issues identified during the review meeting.

The syllabus describes four review types, ranging from informal to formal:

• Informal review: no formal process, may simply involve a colleague reading over a document. Low cost, useful early in a document's life.
• Walkthrough: the author guides participants through the work product to build a shared understanding and gather feedback. Can range from fairly informal to more structured depending on the goals.
• Technical review: a discussion among technically qualified peers, focused on the technical content of the work product, often used to evaluate the technical quality of a design or solution.
• Inspection: the most formal review type, with defined roles, defined entry and exit criteria, and a structured process including individual preparation and a follow-up step to verify that issues were addressed.

Finally, the syllabus lists success factors for reviews, which include things like having clear objectives for each review, choosing the right review type for the work product and its risk level, creating a comfortable atmosphere where people feel able to raise issues constructively, and following up to confirm that defects were actually fixed. Management support, such as allocating time for reviews and not using review results to evaluate individual performance, also matters a great deal for whether a review process succeeds long term.

Chapter 3 at a glance