3.2 Work Products and Static Analysis

What Can Be Examined

A work product is any artefact produced during software development, testing, operation, or maintenance. Requirements specifications, user stories, acceptance criteria, product-backlog items, design and architecture descriptions, source code, test plans, test cases, test charters, traceability matrices, user guides, contracts, and project plans can all be candidates for static testing. Almost any work product that people can read and understand can be reviewed.

The key question for a review is simple: can people read and understand the work product well enough to evaluate it? If yes, a review can help. A business representative may review a user story for value and clarity. A tester may review acceptance criteria for testability — an essential early activity, because static testing of the test basis improves the quality of the tests later derived from it.

Static analysis is narrower because a tool needs structure. Source code, configuration files, formal models, structured text, and documents with checkable rules are good candidates. An informal whiteboard sketch may support a conversation, but it is not suitable for automated static analysis unless it is first turned into a structured model.

Static analysis can reveal issues that are awkward to expose with runtime tests: unreachable or dead code, undeclared or unused variables, duplicated code, excessive complexity, inconsistent naming, dependency-rule violations, unsafe patterns, and some security vulnerabilities. It also supports maintainability by highlighting code that is hard to change or understand.

The Value and Benefits of Static Testing

The syllabus stresses why static testing pays off, and the exam tests these benefits directly. The headline economic argument is the cost of defect correction: a defect found early in a requirement or design is far cheaper to fix than the same defect found after coding, in system test, or — most expensive of all — in production. Static testing enables this early detection because it can start before any code exists.

Key benefits the syllabus lists include:

• Detecting and correcting defects more efficiently, and before dynamic testing is even possible.
• Identifying defects that are difficult or impossible to find by dynamic testing, such as requirement contradictions, unreachable code, or missing test-basis coverage.
• Preventing defects in design or coding by catching inconsistencies and ambiguities early.
• Increasing development productivity (for example, through improved design or more maintainable code).
• Reducing development cost and time, and consequently reducing testing cost and time.
• Reducing the total cost of quality over the software's life by fewer in-field failures.
• Improving communication between team members through the collaboration of a review.

A second important point: static-analysis findings are anomalies, not automatically defects. A tool may report a warning or rule violation that requires human judgement. A complexity warning may be acceptable in generated code but serious in a safety-critical decision module. The exam often uses anomaly as a broader term than defect: an anomaly is any condition that deviates from expectation; only confirmed anomalies are defects.

A good CTFL answer fits the technique to the artefact. Reviewing a requirement for ambiguity is a review. Running a linter on source code is static analysis. Executing the program to check whether the requirement is met is dynamic testing. When a question asks whether a tester can simply read and understand a work product, that is usually the clue that a review is appropriate.

Reviews Versus Static Analysis in Practice

The two forms of static testing divide along who or what does the examining. A review relies on human examination — people read the work product and apply knowledge, experience, and checklists. Static analysis relies on tools — software parses a structured artefact and checks it against coding rules, modelling rules, or patterns. Both are static because neither executes the software under test, but they suit different products and find different problems.

Reviews excel at issues that require human judgement and domain knowledge: an acceptance criterion that is technically clear but business-wrong, a requirement that omits an important user scenario, a design that is feasible on paper but risky given the team's experience, or testware that fails to trace to the test basis. No tool can reliably catch a misunderstood business rule.

Static-analysis tools excel at scale and consistency: they tirelessly apply the same rules across thousands of lines and never get bored. Typical findings include:

• Coding-standard and style violations (naming, formatting, banned constructs).
• Programming defects such as undefined variables, unreachable/dead code, and boundary or type problems detectable without running the code.
• Maintainability signals such as excessive cyclomatic complexity, deep nesting, and duplicated code.
• Security weaknesses matching known vulnerable patterns.
• Dependency and architecture-rule violations.

A crucial exam point: static analysis is frequently integrated into the CI/CD pipeline, where it runs automatically on every commit and provides fast, early feedback — a concrete realisation of shift-left. But its output still needs triage. Tools produce false positives (flagging something that is not actually a problem) and can miss context-specific defects (false negatives), so a human decides which anomalies are real defects.

For the exam, when a scenario mentions standards conformance, complexity, or automated scanning of code, think static analysis. When it mentions people reading a document to judge clarity, completeness, or value, think review.