Static Testing: Reviews and Walkthroughs

What Is Static Testing? #

Static testing examines software work products — requirements, design documents, code, test plans — without executing the software. You are looking at the artifact itself, searching for defects, inconsistencies, and improvements.

Dynamic testing runs the software and checks its behavior. Static testing reads the software (or its documentation) and checks its correctness.

Think of it as proofreading a recipe before cooking versus tasting the dish after cooking. Both approaches find problems, but proofreading is cheaper — you catch “add 10 cups of salt instead of 1 teaspoon” before ruining the ingredients.

Why Static Testing Matters #

The cost of fixing a defect increases dramatically the later it is found:

Static testing catches defects at the earliest possible stage — before any code is written. IBM’s research found that inspections can remove 60-90% of defects before testing even begins.

What Can Be Statically Tested? #

• Requirements specifications
• User stories and acceptance criteria
• Architecture and design documents
• Source code
• Test plans and test cases
• Database schemas
• Configuration files
• CI/CD pipeline definitions

Types of Reviews #

Reviews are a human-driven form of static testing. They range from casual to highly formal.

Informal Review #

The simplest form. One person asks a colleague to look at their work. No documented process, no formal output.

Characteristics:

• No defined process or roles
• Often a quick desk check or “can you look at this?”
• No documented findings (or just verbal feedback)
• Low overhead, easy to do frequently

When to use: Daily code changes, quick sanity checks, early drafts of documents.

Walkthrough #

The author guides reviewers through the work product, explaining the content and gathering feedback. The author leads and drives the session.

Characteristics:

• Author-led presentation
• Can be open-ended or scenario-based
• Findings may or may not be documented
• Focus on learning and knowledge sharing as much as defect finding

When to use: Complex designs that need explanation, onboarding new team members, requirements that need business context.

Technical Review #

A peer review where technically qualified reviewers examine the work product independently before meeting to discuss findings. More structured than a walkthrough.

Characteristics:

• Led by a moderator (not the author)
• Reviewers prepare individually before the meeting
• Documented findings and decisions
• Focused on finding technical defects and ensuring standards compliance
• May use checklists

When to use: Critical code changes, architectural decisions, security-sensitive components.

Inspection (Fagan Inspection) #

The most formal review type, developed by Michael Fagan at IBM in 1976. It follows a strict process with defined roles, entry/exit criteria, and metrics.

Roles:

• Moderator — facilitates the process, ensures rules are followed
• Author — created the work product, answers questions but does not defend
• Reviewers — examine the artifact and identify defects
• Scribe — records all defects and decisions

When to use: Safety-critical systems, regulatory requirements, high-risk components, projects where defect data must be tracked.

The Review Process #

A structured review follows these phases:

1. Planning. The moderator selects reviewers, distributes materials, sets schedule, and verifies entry criteria (is the document ready for review?).

2. Overview/Kickoff. The author provides context. For inspections, the moderator explains the process and roles. For walkthroughs, the author presents the content.

3. Individual Preparation. Each reviewer examines the work product independently, noting potential defects and questions. This is the most critical phase — studies show that most defects are found during individual preparation, not during the meeting.

4. Review Meeting. Reviewers share findings. The scribe records defects. The group decides on each issue: defect, question, suggestion, or out of scope. The meeting should not solve problems — only identify them.

5. Rework. The author addresses all identified defects.

6. Follow-up. The moderator verifies that all defects were addressed. For inspections, they decide if a re-inspection is needed.

Review Checklists #

Checklists make reviews systematic and repeatable. Here are examples for different work products:

Requirements Review Checklist #

• Is each requirement uniquely identifiable (ID)?
• Is each requirement testable (can you write a test for it)?
• Are there contradictions between requirements?
• Are all assumptions explicitly stated?
• Are boundary conditions defined (min, max, empty, null)?
• Are error conditions and their handling specified?
• Is the requirement free of ambiguous terms (“fast”, “easy”, “user-friendly”)?
• Are all data formats specified (dates, currencies, units)?

Code Review Checklist #

• Does the code match the design/requirements?
• Are all error conditions handled?
• Are resources properly released (connections, files, memory)?
• Are input values validated before use?
• Are there any hardcoded values that should be configurable?
• Is the code free of security vulnerabilities (SQL injection, XSS)?
• Are there unit tests for the new code?
• Does the code follow the team’s style guide?

Benefits of Early Defect Detection #

Static testing provides benefits beyond finding bugs:

Knowledge sharing. Reviews spread understanding of the system across the team. If only one person understands a component, that is a risk.

Standard enforcement. Reviews ensure coding standards, naming conventions, and architectural patterns are consistently applied.

Mentoring. Junior developers learn from reviewing senior developers’ code and from receiving feedback on their own.

Documentation improvement. Reviewing requirements and designs forces clarity. Ambiguities that “everyone understands” get exposed.

Exercise: Conduct a Requirements Review #

Below is a requirements specification for a password reset feature. Using the checklist provided earlier, identify all defects, ambiguities, and missing information.

Requirements Specification: Password Reset Feature

REQ-1: When a user clicks “Forgot Password”, the system should quickly send a reset email.

REQ-2: The reset link should expire after some time.

REQ-3: The new password must be strong.

REQ-4: After resetting the password, the user should be able to log in with the new password.

REQ-5: The system should handle errors gracefully.

REQ-6: The reset email should contain a link to the password reset page.

REQ-7: The user must enter the new password twice for confirmation.

REQ-8: If the email address is not found in the system, do not reveal this to the user (security requirement).

REQ-9: The password reset token should be cryptographically secure.

REQ-10: Rate limiting: the user should not be able to request too many reset emails.

For each defect, specify:

1. The requirement ID
2. The defect type (ambiguity, missing information, contradiction, untestable)
3. A recommended fix

Review Metrics #

For formal reviews, track these metrics to improve the process:

Key Takeaways #

• Static testing examines work products without executing code, catching defects at the earliest and cheapest stage
• Reviews range from informal (desk check) to formal (inspection with defined roles and metrics)
• Individual preparation is the most effective phase — most defects are found before the meeting
• Checklists make reviews systematic and prevent common oversights
• The review process follows: planning, kickoff, preparation, meeting, rework, follow-up
• Static testing benefits go beyond defect finding: knowledge sharing, standard enforcement, and mentoring
• Requirements reviews are especially valuable — one ambiguous requirement can cascade into many implementation defects