Reviews, Inspections and Static Quality Analysis

Introduction and Context

Software quality assurance (SQA) is not limited to testing executable software. A substantial proportion of defects can be detected before execution by examining requirements, architecture, design models, source code, configuration files, test specifications, and operational procedures. Reviews, inspections, audits, and static analysis provide disciplined ways to discover such defects early.

Early detection is economically valuable because defects become more expensive to correct as development progresses. A requirements ambiguity may be corrected by changing a document, whereas the same ambiguity discovered after deployment may require code modification, database migration, user communication, and incident management. Static quality activities therefore support both defect prevention and cost-effective risk management.

This chapter examines four complementary activities: informal and formal reviews, walkthroughs, inspections, and audits. It also explains coding standards, automated static analysis, complexity measurement, secure coding checks, and technical-debt assessment. The central theme is that quality is created through engineering decisions and evidence, not merely inspected into a finished product.

Learning Objectives

After studying this chapter, a learner should be able to:

1. Distinguish walkthroughs, peer reviews, inspections, and audits.

2. Plan and conduct an effective review using defined roles, evidence, and follow-up.

3. Apply coding standards and interpret findings from static-analysis tools.

4. Explain software complexity measures and their limitations.

5. Identify common secure-coding weaknesses through static checks.

6. Assess technical debt using evidence rather than intuition alone.

7. Evaluate the managerial, ethical, and governance implications of review results.

8. Integrate human review, automation, and continuous integration into a quality strategy.

1. The Role of Static Quality Assurance

Dynamic testing observes behavior when software executes. Static quality assurance examines an artifact without executing its intended business behavior. The artifact may be a requirements specification, UML model, source file, infrastructure-as-code script, database schema, test case, or deployment configuration.

Static activities detect several classes of problems:

• defects, such as an incorrect condition or missing requirement;
• nonconformance, such as violation of an organizational standard;
• maintainability risks, such as duplicated or excessively complex code;
• security weaknesses, such as injection-prone data flow;
• process weaknesses, such as an unapproved design or missing traceability;
• technical debt, meaning a future cost created by expedient current decisions.

Static analysis does not prove that software is correct. A tool may report a possible defect that is not actually harmful, while failing to identify a defect outside its analysis model. Human judgment remains essential for understanding business intent, architectural consequences, usability, and ethical impact.

A mature SQA system uses layered assurance:

1. standards and design guidance prevent predictable errors;

2. peer review provides contextual human judgment;

3. automated analysis provides repeatable and scalable checking;

4. formal inspection supplies rigorous defect detection and measurement;

5. audits provide independent assurance of process and governance;

6. testing and operational monitoring validate executable behavior.

These layers overlap but are not interchangeable.

2. Reviews, Walkthroughs, Inspections, and Audits

2.1 Review as a general concept

A review is an evaluation of a work product by one or more people other than its author. Work products include requirements, designs, code, test plans, user documentation, and operational runbooks. Reviews may be informal or highly structured. Their purposes include finding defects, sharing knowledge, evaluating alternatives, and determining readiness for a subsequent lifecycle activity.

A review should have a defined scope. “Review the module” is weaker than “evaluate input validation, error handling, authorization, and compliance with the organization’s Java coding standard.” The review also needs an explicit completion condition, such as resolution or accepted disposition of all high-severity findings.

2.2 Walkthroughs

A walkthrough is usually led by the author, who explains the work product to colleagues. Participants ask questions, identify possible defects, and suggest improvements. Walkthroughs are useful when knowledge transfer and early feedback are important, especially for new designs or unfamiliar domains.

Advantages include low administrative overhead, rapid feedback, and strong learning value. Limitations include author bias, variable preparation, and the risk that participants become passive listeners. A walkthrough should not be treated as a ceremonial presentation. Participants should receive materials in advance and be assigned areas to examine.

2.3 Peer reviews

A peer review is an evaluation by colleagues with relevant expertise. It may be conducted synchronously in a meeting or asynchronously through a code-review platform. Peer review is especially effective for checking local correctness, readability, design assumptions, test adequacy, and maintainability.

Good peer review practice includes small change sets, clear descriptions, evidence from automated checks, respectful language, and separation of person from artifact. Review comments should explain the risk and, where useful, suggest a principle rather than prescribe an unnecessarily narrow implementation.

2.4 Formal inspections

A formal inspection is a defined, data-oriented review process with explicit roles, preparation, meeting rules, defect recording, rework, and verification. Traditional inspection roles include:

• author: creates and explains the work product and performs rework;
• moderator: plans the inspection, controls the meeting, and protects its objectives;
• reader: presents the artifact in logical units from the perspective of its users;
• inspectors: examine the artifact using assigned perspectives or checklists;
• recorder: documents each agreed defect and its location.

A typical inspection has these stages:

1. Planning: define scope, participants, entry criteria, standards, and schedule.

2. Overview: provide context, purpose, interfaces, and terminology.

3. Individual preparation: inspectors examine the artifact independently.

4. Inspection meeting: participants identify and classify defects without redesigning the entire product.

5. Rework: the author corrects defects or records justified deviations.

6. Follow-up: the moderator verifies corrections and determines closure.

7. Measurement: defect data are analyzed for process improvement.

The meeting should focus on finding and recording defects, not assigning blame or solving every issue in real time. If a discussion becomes a design workshop, the moderator should record the issue and move detailed resolution elsewhere.

2.5 Audits

An audit is an independent, systematic examination of evidence against defined criteria. An audit may assess compliance with an internal development procedure, a contractual obligation, a regulatory requirement, or a standard such as ISO 9001-related quality-management expectations or an organization’s secure-development policy.

Audits ask questions such as:

• Was the required approval obtained?
• Is the approved version identifiable?
• Can the organization demonstrate traceability from requirement to test?
• Were exceptions authorized and documented?
• Are corrective actions closed and effective?

An audit is not the same as a code review. Code review examines technical quality of a change; an audit examines conformity and evidence. An audit can sample projects and records rather than inspect every line of code. Independence, objective evidence, confidentiality, and transparent reporting are fundamental.

3. Designing an Effective Review Process

3.1 Entry and exit criteria

Entry criteria determine whether a work product is ready for review. Examples include a stable version, identified author, available supporting documents, completed self-check, and successful automated build. Exit criteria may require that all critical defects are corrected, all major findings have an approved disposition, and review records are stored.

Without criteria, reviews are often started too early or closed without evidence. Criteria should be risk-based: a safety-critical interface requires stronger preparation and independent expertise than a low-risk formatting change.

3.2 Review preparation

Preparation is one of the strongest predictors of review effectiveness. Participants should understand the purpose, users, assumptions, interfaces, and applicable standards. Reviewers should examine the artifact individually before the meeting. Checklists are useful when they encode known failure modes, but they must be periodically updated; a stale checklist creates false confidence.

The review leader should select reviewers according to risk. For example, a payment component may require a domain expert, security specialist, database specialist, and maintainer. Excessive participation can increase coordination cost without increasing detection capability.

3.3 Defect recording and classification

A defect record should contain a unique identifier, artifact and location, concise description, category, severity, evidence, owner, disposition, and verification status. Categories might include logic, interface, data, requirements, standards, security, performance, or documentation.

Severity describes consequence, whereas priority describes urgency. A low-frequency security weakness may have high severity even if its immediate priority is moderated by compensating controls. Confusing severity and priority produces poor decisions.

Possible dispositions include fixed, duplicate, not a defect, deferred with rationale, accepted risk, or external dependency. “Won’t fix” without an explanation is not adequate governance.

3.4 Review metrics

Useful measures include preparation rate, review effort, defect density, defect type distribution, rework effort, and escaped defects. A simple defect density can be expressed as:

Defect density = confirmed defects / size of artifact

The size unit must be stated, such as thousand lines of code, function points, pages, or requirements. The metric is meaningful only when counting rules and size definitions are consistent. Lines of code are affected by programming language and coding style, so comparisons across languages can be misleading.

Inspection yield may be expressed as:

Inspection yield = defects found during inspection / (defects found during inspection + defects found later)

This is an operational measure, not a universal quality law. It is influenced by the completeness of later testing, defect-reporting behavior, and the time window selected.

Metrics should support learning rather than punish teams. If managers use defect counts as individual performance scores, people may under-report defects or avoid difficult reviews.

4. Coding Standards and Review Checklists

Coding standards establish a shared baseline for naming, formatting, error handling, documentation, dependencies, logging, resource management, testing, and security. Their purpose is not aesthetic uniformity alone. Consistent code reduces cognitive load and makes defects easier to recognize.

A useful standard distinguishes:

• mandatory rules: violation requires correction or approved exception;
• recommended practices: generally beneficial but context-sensitive;
• advisory guidance: suggestions requiring engineering judgment.

Standards should be version-controlled, tool-supported where possible, and accompanied by examples. Rules that cannot be explained in terms of readability, reliability, security, portability, or maintainability should be reconsidered.

A review checklist should be specific enough to prompt examination but short enough to use. Typical questions include:

• Are inputs validated at the trust boundary?
• Are authorization decisions made on the server side?
• Are errors handled without exposing secrets?
• Are resources closed on all relevant paths?
• Are concurrency assumptions explicit?
• Are units, time zones, and numeric ranges clear?
• Is duplicated logic likely to diverge?
• Do tests cover normal, boundary, and failure cases?

5. Automated Static Analysis

Static-analysis tools examine representations of software using lexical rules, abstract syntax trees, control-flow graphs, data-flow analysis, type systems, or symbolic reasoning. Common categories are:

• style and lint tools: formatting, naming, unreachable code, and simple patterns;
• type and compiler analysis: incompatible types, missing cases, and some nullability errors;
• data-flow analysis: propagation of values through assignments, branches, and calls;
• control-flow analysis: paths, loops, unreachable statements, and possible exceptions;
• bug-finding tools: suspicious API use, resource leaks, and error-prone constructs;
• security analyzers: taint flow from untrusted sources to sensitive sinks;
• dependency and configuration scanners: vulnerable libraries, licenses, and insecure settings.

5.1 False positives and false negatives

A false positive is a reported issue that is not a real defect under the application’s context. A false negative is a real issue that the tool fails to report. No practical analyzer eliminates both. Rules should therefore be triaged using severity, confidence, exploitability, reachability, and business context.

Teams should establish a policy for suppressions. A suppression should identify the rule, reason, responsible person, date or review condition, and any compensating control. Blanket disabling of a noisy rule destroys the value of the analysis.

5.2 Integrating tools into the lifecycle

Static analysis is most effective when integrated into the developer workflow and continuous integration pipeline. Fast checks can run on every commit; deeper analysis can run nightly or before release. A quality gate may block a merge when new critical security findings occur, when compilation warnings increase, or when required review approval is absent.

Quality gates should focus on new or changed code as well as total backlog. Requiring immediate elimination of every historical warning may make adoption impractical. A better strategy is to prevent deterioration, prioritize high-risk legacy findings, and reduce the backlog incrementally.

Tools should be calibrated using representative code. A pilot should measure finding relevance, execution time, developer effort, and missed defect types. Tool output is evidence for decision-making, not a substitute for engineering responsibility.

6. Complexity Measurement

Complexity measures help identify code that may be difficult to understand, test, change, or review. They are indicators, not direct measurements of quality.

6.1 Cyclomatic complexity

For a connected control-flow graph, McCabe’s cyclomatic complexity can be calculated as:

M = E − N + 2

where E is the number of control-flow edges and N is the number of nodes. An equivalent form is M = P + 1, where P is the number of independent decision points, under the usual convention that each binary decision contributes one decision point.

The measure estimates the number of linearly independent paths in the control-flow graph and is therefore useful for identifying a minimum basis set of paths for structural testing. The assumptions include a defined control-flow graph and a consistent treatment of compound Boolean expressions, exception paths, and short-circuit operators. Different tools may count these constructs differently.

For example, a function with four independent binary decision points has M = 4 + 1 = 5 under the stated convention. This does not mean that exactly five tests prove correctness; it indicates a structural basis for path-oriented testing. Data combinations, loop iterations, exception behavior, and business rules may require more tests.

6.2 Other complexity indicators

Cognitive complexity attempts to reflect how difficult control flow is for humans to understand, often penalizing nesting and abrupt flow more than simple sequential structure. Halstead measures use counts of operators and operands to derive indicators such as vocabulary, length, and estimated volume. Maintainability indices combine several signals, but their formulas and thresholds vary by tool and should not be treated as universal scientific constants.

Class-level measures may examine coupling, cohesion, inheritance depth, or response sets. High coupling can make change risky; very low coupling is not automatically desirable if it reflects excessive indirection. Metrics must be interpreted with architecture, domain complexity, and team experience.

7. Secure Coding Checks

Security review begins with threat modeling and trust-boundary analysis, then uses standards and tools to detect implementation weaknesses. Static checks commonly target:

• injection caused by constructing commands or queries from untrusted data;
• cross-site scripting caused by unsafe output handling;
• broken authentication or authorization;
• hard-coded credentials and exposed secrets;
• insecure cryptographic algorithms or key management;
• path traversal and unsafe file operations;
• deserialization of untrusted data;
• missing input validation and unsafe type conversion;
• resource exhaustion and denial-of-service risks;
• improper logging of personal or confidential information.

A secure-coding finding must be evaluated in context. For example, a scanner may report tainted input reaching a database API. The finding is high risk if the query is constructed through string concatenation, but it may be a false positive if a verified parameterized abstraction is used and the analyzer cannot recognize it.

Security review also includes negative requirements: the software must not disclose secrets, bypass authorization, retain data beyond policy, or silently weaken audit trails. Privacy and security concerns should be considered during design, not only during code inspection.

8. Technical-Debt Assessment

Technical debt is the future cost of maintaining or changing a system because current implementation choices are suboptimal, incomplete, or insufficiently documented. Debt may be deliberate, such as releasing a limited feature to test a market hypothesis, or accidental, such as accumulating duplication through weak review.

Debt should be distinguished from ordinary work. A missing feature is not automatically technical debt; an expedient implementation that will require future rework is. Debt can occur in code, architecture, tests, infrastructure, documentation, data, and processes.

A practical debt assessment records:

• the debt item and affected component;
• the origin and rationale;
• symptoms and triggering conditions;
• principal, meaning estimated effort to remove or reduce it;
• interest, meaning recurring cost such as slower delivery or incidents;
• risk, including security, reliability, compliance, and obsolescence;
• dependencies and a proposed repayment strategy.

There is no universally valid formula for technical debt. Teams may use expert estimation, historical effort, incident data, change-failure rates, code metrics, or cost-of-delay analysis. These are decision aids rather than objective monetary truths. A debt register should be reviewed during portfolio planning and connected to product and operational risks.

A useful prioritization question is not “Which module has the worst score?” but “Which debt item creates the greatest expected harm relative to the effort and opportunity cost of addressing it?” This supports risk-based sequencing.

9. An Integrated Operating Model

A postgraduate SQA practitioner should design a complementary process rather than select one favorite technique. A possible operating model is:

1. Define quality attributes, standards, security expectations, and review scope.

2. Require author self-checks and automated fast feedback.

3. Conduct peer review for normal changes.

4. Escalate high-risk work to formal inspection with independent specialists.

5. Run security, dependency, and configuration analysis in the delivery pipeline.

6. Use audits to verify process evidence, approvals, traceability, and corrective action.

7. Record findings and technical debt in a visible system.

8. Analyze trends and improve standards, tools, training, and architecture.

This model recognizes that automation is scalable but context-limited, while human review is context-rich but expensive and variable. The objective is not maximum ceremony; it is appropriate assurance for the risk.

10. Illustrative Case: Review and Static Analysis in a Digital Payments Service

Background

The following is a fictional illustrative case. A financial-technology team is developing a service that authorizes card payments and sends transaction-status notifications. The service processes personal and financial data and must maintain an audit trail.

Problem

During a release candidate review, the team observes increasing review delays, duplicated authorization logic, and a growing static-analysis backlog. A scanner identifies possible SQL injection, hard-coded test credentials, and a resource leak. Cyclomatic complexity is high in the transaction-routing function. Developers argue that the findings are mostly tool noise and that the release schedule cannot accommodate extensive rework.

Analysis

The SQA lead first separates findings by confidence and consequence. The possible injection is traced from an HTTP request to a query builder. The query is indeed assembled through string concatenation on one path, so it is confirmed as a critical issue. The hard-coded credential is a non-production test value committed to the repository; although its access is limited, policy requires removal and secret rotation. The resource leak occurs when an exception bypasses closure of a database connection.

A peer review reveals that authorization rules are implemented independently in three endpoints. This creates a consistency risk not fully captured by the scanner. The routing function has five independent binary decisions, giving cyclomatic complexity M = 5 + 1 = 6 under the adopted convention. The value does not prove that six tests are sufficient, but it supports decomposition and targeted path testing.

Approach and solution

The team takes the following actions:

• replaces string-built queries with parameterized statements;
• removes credentials from source control, rotates the exposed value, and uses a managed secret store;
• applies structured resource management to guarantee closure;
• centralizes authorization in a tested policy component;
• divides the routing function into smaller units with explicit domain rules;
• adds boundary, denial, exception, and audit-trail tests;
• configures the pipeline to block new critical security findings;
• creates a debt register for lower-priority duplication and documentation gaps;
• conducts a focused formal inspection involving a security engineer, domain expert, and maintainer.

The inspection records defects without debating personal performance. Each correction is verified against the relevant commit and automated evidence. A later audit confirms that approvals, scan results, exception records, and traceability are retained.

Outcome

The release is delayed briefly but proceeds with materially lower security and maintainability risk. The team also changes its process: security checks run on pull requests, high-risk changes require specialist review, and technical-debt repayment is included in quarterly planning. The result is not merely a cleaner release; it is a more predictable quality system.

Learning points

First, tool findings require contextual investigation rather than automatic acceptance or dismissal. Second, complexity metrics are useful signals for review and test design, not pass/fail proof of quality. Third, architectural duplication can create risks that line-level analysis misses. Finally, governance evidence and technical correction must operate together in regulated or high-consequence systems.

11. Challenges, Limitations, and Governance

Reviews can become bureaucratic, slow delivery, or suppress dissent when managers treat them as approval rituals. Reviewers may suffer from confirmation bias, insufficient domain knowledge, or fatigue. Remote and asynchronous work can improve traceability but may reduce rich discussion. Small teams may lack independence and specialist expertise.

Static tools can produce noise, consume build resources, and encourage metric gaming. Complexity thresholds differ among languages and organizations. Debt estimates are uncertain and can be manipulated if presented as precise financial facts. Therefore, decisions should record assumptions, uncertainty, and accepted risks.

Ethically, organizations should avoid blaming individuals for defects discovered through a healthy review process. Confidential vulnerability findings must be access-controlled, and responsible disclosure procedures should be established when third-party or production risks are found. Personal data in logs, review comments, and analysis repositories must be handled according to privacy obligations and retention policies.

Auditable evidence should be trustworthy: timestamps, tool versions, configuration, approvals, exceptions, and correction links should be preserved. Artificial-intelligence coding assistants introduce additional review obligations. Generated code may contain insecure patterns, licensing concerns, fabricated APIs, or undocumented assumptions. AI-generated code should be treated as untrusted contribution: analyze it, review it, test it, and verify its provenance and licensing status.

12. Contemporary Practice and Best Practices

Modern development increasingly combines pull-request review, policy-as-code, software composition analysis, secret scanning, infrastructure-as-code analysis, and continuous compliance evidence. The most effective practices are:

• review small, coherent changes;
• define risk-based entry and exit criteria;
• automate deterministic checks early;
• retain humans for intent, architecture, security, and ethics;
• distinguish severity, priority, confidence, and exploitability;
• measure trends rather than rank individuals;
• maintain controlled suppressions and documented exceptions;
• prevent new debt while systematically reducing high-impact old debt;
• calibrate tools against real defects;
• make findings actionable and assign ownership;
• verify corrections independently for high-risk issues;
• improve standards and training using recurring defect patterns.

Chapter Summary

Reviews and static quality analysis detect defects and risks before software execution or deployment. Walkthroughs emphasize author-led explanation and learning; peer reviews provide collaborative evaluation; formal inspections use defined roles, preparation, defect records, rework, and verification; audits independently assess conformity against criteria and evidence. Coding standards create a maintainable baseline, while static-analysis tools examine syntax, types, control flow, data flow, security weaknesses, dependencies, and configurations. Their results require triage because false positives and false negatives are unavoidable.

Complexity measures, particularly cyclomatic complexity, support review and test planning but do not prove correctness. Secure-coding checks must be connected to trust boundaries, threat models, and contextual investigation. Technical debt represents future cost created by expedient or incomplete decisions and should be assessed through risk, principal, interest, evidence, and repayment planning. Effective SQA integrates automation, human judgment, formal governance, and continuous improvement. Ethical practice requires respectful review, responsible vulnerability handling, privacy protection, transparent exceptions, and careful validation of AI-generated code.

Key Terms

Review: Evaluation of a work product by people other than its author.

Walkthrough: Author-led review used for explanation, feedback, and defect discovery.

Peer review: Evaluation by colleagues with relevant technical or domain expertise.

Formal inspection: Structured review with defined roles, preparation, defect recording, rework, and follow-up.

Audit: Independent examination of evidence against specified criteria.

Static analysis: Examination of software artifacts without executing their intended behavior.

Coding standard: Agreed rule set for consistent and safe development practices.

False positive: Tool finding reported as a problem when it is not a real defect in context.

False negative: Real defect not detected by a tool or review.

Quality gate: Defined condition that must be satisfied before progression in a workflow.

Defect density: Number of confirmed defects divided by a stated artifact-size unit.

Cyclomatic complexity: Control-flow measure estimating linearly independent paths.

Control-flow graph: Representation of program execution paths using nodes and edges.

Taint analysis: Tracking potentially untrusted data toward sensitive operations.

Trust boundary: Location where data or control crosses between different levels of trust.

Technical debt: Future cost caused by expedient, incomplete, or suboptimal current decisions.

Principal: Estimated effort required to remove or reduce technical debt.

Interest: Recurring cost imposed by leaving technical debt unresolved.

Suppression: Documented instruction to disregard a particular analysis finding.

Traceability: Ability to connect requirements, implementation, tests, approvals, and evidence.

Review Questions

Short Answer Questions

1. What is the principal difference between a walkthrough and a formal inspection?

2. Why should severity and priority be recorded separately?

3. Define a false positive in static analysis.

4. What does cyclomatic complexity indicate?

5. Name two types of evidence commonly examined during an audit.

Long Answer Questions

1. Explain the stages, roles, and success conditions of a formal inspection.

2. Discuss how coding standards and automated static analysis complement one another.

3. Explain the benefits and limitations of complexity metrics in software quality assurance.

4. Describe a risk-based process for identifying and repaying technical debt.

5. Evaluate the governance and ethical issues associated with software reviews and AI-generated code.

Analytical / Application Questions

1. A scanner reports a possible injection vulnerability, but developers claim that an internal library makes the data safe. Describe the evidence and analysis needed to decide whether the finding is genuine.

2. A project has many historical static-analysis warnings but few new defects. Design a quality-gate and debt-reduction strategy that prevents deterioration without blocking all development.

3. A safety-relevant function contains six independent decision points and several exception paths. Explain what cyclomatic complexity can and cannot tell the team, and propose an appropriate review and testing approach.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily led by the author of the work product?

A. Walkthrough

B. Audit

C. Formal inspection

D. Independent certification assessment

Correct Answer: A. Walkthrough

Question 2

What is the main purpose of an audit?

A. To redesign an algorithm

B. To examine evidence against defined criteria

C. To replace all software testing

D. To calculate lines of code

Correct Answer: B. To examine evidence against defined criteria

Question 3

Under the convention that each binary decision contributes one decision point, what is the cyclomatic complexity of a function with four independent decision points?

A. 3

B. 4

C. 5

D. 8

Correct Answer: C. 5

Question 4

Which statement correctly describes a false negative?

A. A tool reports a safe construct as defective

B. A real defect is not reported

C. A reviewer records the same defect twice

D. A finding is assigned the wrong owner

Correct Answer: B. A real defect is not reported

Question 5

Which practice most directly reduces injection risk?

A. Increasing indentation consistency

B. Using parameterized database statements

C. Adding more comments

D. Increasing inheritance depth

Correct Answer: B. Using parameterized database statements

Question 6

In a formal inspection, who normally controls the meeting and follow-up?

A. Author

B. Reader

C. Moderator

D. End user

Correct Answer: C. Moderator

Question 7

What is technical-debt interest?

A. The effort originally spent writing code

B. The recurring cost of leaving debt unresolved

C. The number of lines in a module

D. The license fee for a static-analysis tool

Correct Answer: B. The recurring cost of leaving debt unresolved

Question 8

Why should a static-analysis suppression be documented?

A. To hide all tool findings

B. To record its rationale and support future review

C. To eliminate the need for testing

D. To guarantee that the finding is a false positive

Correct Answer: B. To record its rationale and support future review

Question 9

Which statement about complexity metrics is most accurate?

A. They prove that software is correct

B. They are irrelevant to test planning

C. They are indicators requiring contextual interpretation

D. They eliminate the need for peer review

Correct Answer: C. They are indicators requiring contextual interpretation

Question 10

Which activity best verifies that a corrected inspection finding is actually resolved?

A. Deleting the original defect record

B. Independent follow-up against the correction and evidence

C. Increasing the project budget

D. Changing the coding language

Correct Answer: B. Independent follow-up against the correction and evidence