Static Testing in Software Engineering: Peer Review, Walkthrough & Code Inspection
Suppose your team has written a seat-booking rule, but nobody has run the program yet. Can you still find a defect? Yes. A careful reader may spot a missing condition before the first test case is executed.
In this chapter
What is static testing?
Static testing means checking a work product by examining it without running the software being tested. The product may be a requirement document, a design diagram, a user story, source code, a test plan or even a test case. A review done by people and static analysis done by tools both belong to static testing.
Why do we do it early? A sentence such as “the booking should be fast” is unclear before anyone writes code. A review can ask, “How fast, under what load, and how will we measure it?” Catching that ambiguity before development saves later confusion. If you want to understand where requirements originate, see requirement documentation and review.
Static testing can reveal missing or contradictory requirements, design gaps, unreachable or duplicated code, inconsistent interfaces and coding-standard issues. It also helps the team share an understanding of the work. It cannot, by itself, demonstrate how the software behaves at runtime under real inputs, network failures or load.
Static testing vs dynamic testing
Read a booking rule and notice that an unavailable seat might still be reported as successfully reserved. The program is not executed.
Run the booking function with an unavailable seat, observe the incorrect response, and trace the failure back to its cause.
They support each other. Static testing can find defects in documents that cannot be executed. Dynamic testing reveals behaviour that a review may overlook. The broader software testing chapter explains testing objectives, levels and the difference between static and dynamic activities.
One example we will review in three ways
Requirement: a seat may be reserved only if it exists and is available. A failed attempt must return a failure result. Here is an early draft of the function:
function reserveSeat(seat) {
if (seat.available) {
seat.available = false;
}
return { success: true };
}Review finding A: if seat.available is false, the function still returns { success: true }. This disagrees with the requirement.
Review finding B: if seat is missing, reading seat.available would fail. The requirement says a nonexistent seat must be rejected.
We found both by reading the requirement and the code. The code was not executed. A reviewer might also ask how simultaneous reservation attempts are handled in the real storage layer. That is a design question for the wider system; this tiny function does not provide enough information to declare a concurrency defect.
After review, one clearer version of the local rule is:
function reserveSeat(seat) {
if (!seat || typeof seat.available !== "boolean") {
return { success: false, reason: "INVALID_SEAT" };
}
if (!seat.available) {
return { success: false, reason: "ALREADY_RESERVED" };
}
seat.available = false;
return { success: true };
}The revision is a proposed fix for this local example. The team should still execute tests for missing, available and already reserved seats, and review how the complete booking service updates shared storage. For isolated executable checks, read unit testing techniques and examples.
1. Peer review: another pair of eyes
A peer review happens when one or more colleagues examine a work product and give feedback. In a coding team, this may be a pull request review. A colleague reads the change, compares it with the requirement, and comments on a specific line. They may ask for a fix before approving the change.
For our draft, a peer can write: “When the seat is unavailable, this line still returns success. Should we return a failure result here?” This comment identifies a condition, an observed code path, and the expected behaviour. It is more useful than “code is wrong.”
Peer review is a broad practical term. Its formality can vary between teams. ISTQB's named review types include informal review, walkthrough, technical review and inspection. A peer review may be informal or use a more structured process; it is not a single fixed category in that list.
Small changes, quick feedback, readability and requirement checks.
Comments, questions, change requests and approval decisions.
“Looks good” without actually reading the risky paths.
2. Walkthrough: the author explains the work
In a walkthrough, the author takes others through the requirement, diagram or code step by step. The goal may include understanding the work, finding anomalies, gathering ideas and building agreement. Reviewers can ask questions while the author explains a scenario. Individual preparation may help, but a walkthrough does not always require it.
For the booking function, the author might say: “We first check availability, set it to false, and then report success.” A reviewer asks: “What happens when the seat was already unavailable?” The author traces that path on paper and sees the unconditional success result. Another reviewer asks what happens when no seat object is supplied.
A walkthrough is especially useful when team members need to learn a design or agree on a workflow. It is not automatically a code-only activity: a requirement, architecture diagram or test plan can also be walked through.
3. Code inspection: a formal, prepared review
Inspection is the most formal of these review types. The team defines what will be inspected, who will participate, what rules to check and when the inspection is complete. Reviewers examine the material individually before discussion, record anomalies, discuss them, and follow up on fixes. Inspection aims to find as many relevant anomalies as practical, not to grade the author.
For our booking example, reviewers may use a checklist: Does every outcome return the correct result? Are missing inputs handled? Does the implementation match each requirement? Are the failure reasons clear? Is a follow-up test needed? They log findings with locations and the affected rule. The author fixes confirmed defects. A follow-up confirms whether the agreed actions were completed.
Formal-role detail: in an ISTQB-style inspection, the author cannot act as the review leader or the scribe. This helps keep the inspection and its record independent of the person fixing the work.
Code inspection names the inspected artifact as code. Formal inspections can also examine other artifacts, such as requirements or design documents. A static analysis tool may warn about patterns in code, but a tool report is not by itself a human inspection.
Review process and team roles
The formality varies by review type. A complete generic review process follows these activities; a small informal peer review may use a lighter version.
- Planning: decide the work product, review purpose, focus, participants, timing and completion criteria.
- Review initiation: give everyone the correct version, supporting requirements and their roles.
- Individual review: reviewers read their portion and record questions or suspected problems.
- Communication and analysis: discuss findings. A suspected issue is an anomaly until the team checks whether it really is a defect or needs another action.
- Fixing and reporting: assign confirmed defects, revise the work, follow up and record the result.
Who does what?
Creates the work product and fixes confirmed defects.
Examines the work, raises questions and records anomalies.
Facilitates the discussion, timing and respectful participation.
Records findings, decisions and actions.
Organises the review and takes overall responsibility for it.
Chooses what needs review and provides people and time.
In a small review, one person may take more than one role where the chosen process allows it. For an inspection, keep the restriction on the author's review-leader and scribe roles in mind.
A checklist students can use on real projects
Are statements complete, consistent, unambiguous and testable?
What happens for valid, missing and invalid input?
Does every branch return the intended result?
Are updates recorded correctly? What if data is already changed?
Do parameter types and return values match what the caller expects?
What access, error or edge case deserves a later executable test?
Keep the review focused on a manageable chunk and a clear goal. When reviewing the design around this code, software design and architectural design gives the larger module view.
Peer review vs walkthrough vs code inspection
Choose a review method that fits the risk and the work. A one-line text change may need a quick colleague check. A complex payment rule may need prepared reviewers, clear records and a thorough follow-up. The same work product can move through more than one kind of review.
Common mistakes and the correct way to think
- “Static testing means no tools.” Static analysis tools can examine code without executing the software under test.
- “Every review meeting is an inspection.” Inspection has defined roles and a formal process; an author-led conversation may be a walkthrough.
- “A review comment is automatically a defect.” First analyse the anomaly against the requirement and context.
- “The reviewer fixes everything.” Reviewers identify and discuss; the author normally makes the agreed changes.
- “A good review removes the need for runtime tests.” Run relevant unit and integration tests after fixes to check actual behaviour.
The wider quality process also includes verification and validation. You can connect this chapter with software quality assurance, verification and validation.
Exam-ready answer and quick revision
Static testing is the evaluation of a software work product without executing the software. It can be applied to requirements, design documents, source code and test cases. Peer review involves colleagues examining the work and giving feedback. In a walkthrough, the author leads participants through the work to improve understanding and find anomalies. Inspection is a formal review with planned scope, preparation, assigned roles, recorded findings and follow-up. These methods can find ambiguities and defects early, while dynamic testing is still needed to observe actual program behaviour.
Memory trick: Peer = colleague reads; Walkthrough = author guides; Inspection = team follows a formal check. For the generic process, remember Plan → Share → Read → Discuss → Fix.
For a 10-mark answer: begin with the definition, list reviewable work products, compare static and dynamic testing, explain the three approaches with the seat example, draw the five-step process, name the roles, and end with benefits and limits.
Frequently asked questions
Is peer review a type of static testing?
Yes. A colleague can evaluate a work product without executing it. The exact process may be informal or more structured.
Who leads a walkthrough?
The author of the work product leads the walkthrough and explains it to the participants.
Does code inspection require running the code?
No. Inspectors read and analyse the code and related information. Runtime tests may follow after issues are fixed.
Is static analysis the same as peer review?
No. Static analysis typically uses a tool to check a structured work product. Peer review is examination by people. Both are static testing activities.
Can a requirement document be inspected?
Yes. Reviews and formal inspections can examine requirements and designs as well as code.
What is the difference between an anomaly and a defect?
An anomaly is a suspected issue or observation raised during review. The team analyses it to decide whether it is a defect, a question or another kind of action.
Technical reference: ISTQB Certified Tester Foundation Level Syllabus, section 3: Static Testing. The seat-booking example, comments and diagrams are original teaching material.
