Learning objectives — Chapter 3
3.1 Static Testing Basics
3.2 Feedback and Review Process
K-level legend
| Level | Verb | What the exam asks |
|---|---|---|
| K1 | Remember / Recall | "Which of the following is a role in a review?" |
| K2 | Understand / Explain | "Which statement BEST describes the value of static testing?" |
3.1 Static Testing Basics
What is static testing?
Objectives: improve quality, detect defects, assess readability, completeness, correctness, testability, consistency.
Can be used for both verification (are we building it right?) and validation (are we building the right thing?).
Work products examinable by static testing (K1)
Almost any readable/inspectable artifact — not just code.
Can be examined ✓
- Requirements specifications
- User stories & backlog items
- Source code
- Test plans & test cases
- Architecture & design documents
- Models (UML, state diagrams)
- Contracts & project documents
- Web pages, build scripts, config files
NOT suitable ✗
- Third-party executable code (legal/access reasons)
- Work products that cannot be reviewed (no readable form)
Value of static testing (K2 — very important)
- Finds defects very early — cheapest and fastest point to fix
- Finds defects that dynamic testing cannot find — e.g., unreachable code, wrong design patterns, issues in non-executable documents
- Builds shared understanding among stakeholders
- Improves communication across the team
- Reduces overall project cost (fewer expensive fixes later)
- Static analysis in CI pipelines is very efficient — runs automatically on every commit
3.2 Feedback and Review Process
Benefits of early & frequent stakeholder feedback (K1)
- Prevents misunderstandings between stakeholders and the team
- Reduces costly rework later in the project
- Helps the team focus on valuable features
- Improves risk management by catching issues early
Review process — 5 activities (K2 — memorize the order)
Planning
Define scope, purpose, work product to review, effort and time required, exit criteria. Assign roles.
Review initiation
Ensure everyone is prepared — access to materials, roles confirmed, reviewers given preparation time.
Individual review
Each reviewer checks the work product independently using checklists, scenarios, or their expertise. Anomalies recorded.
Communication & analysis
Team meeting — discuss anomalies, decide status (real defect / false positive / question), assign owners and actions.
Fixing & reporting
Author fixes defects found. Defect reports created. Results reported to stakeholders. Exit criteria checked — review may pass or require re-review.
Success factors for reviews (K1 — recall all)
- Clear objectives + measurable exit criteria (never evaluate people)
- Choose the right review type for the work product and context
- Review small chunks only
- Give participants enough preparation time
- Management support
- Make reviews part of company culture
- Provide training to all participants
- Good facilitation — safe environment, no blame
Principal roles in a review (K1)
Six roles — responsibilities
👔 Manager
Decides what gets reviewed. Allocates resources (people, time, budget). Supports the review process.
✍️ Author
Created the work product being reviewed. Fixes defects after the review. Cannot be leader or scribe in an Inspection.
🎙️ Moderator (Facilitator)
Runs the review meeting. Keeps it on track and on time. Creates a psychologically safe environment.
📝 Scribe (Recorder)
Records all anomalies and decisions during the meeting. Produces the meeting minutes/defect log.
🔍 Reviewer
Performs the actual review individually. Can be anyone with relevant knowledge (domain expert, tester, developer, customer).
⭐ Review leader
Has overall responsibility for the review. Plans, coordinates, communicates results. Often also the Moderator.
Role quick-reference
| Role | Key action | In Inspection — restriction? |
|---|---|---|
| Manager | Decides what to review, provides resources | None |
| Author | Creates work product, fixes defects post-review | Cannot be leader or scribe |
| Moderator | Facilitates meeting, maintains safe environment | None |
| Scribe | Records anomalies and decisions | Cannot be author |
| Reviewer | Individually reviews the work product | None |
| Review leader | Plans and coordinates, overall responsibility | Cannot be author |
Review types comparison (K2)
Four review types — ordered by formality
| Review Type | Formality | Led by | Main objective | Key characteristics |
|---|---|---|---|---|
| Informal | Lowest | Anyone | Find anomalies quickly | No formal process or mandatory output. Ad hoc. Buddy review, pair programming review. |
| Walkthrough | Low | Author | Learning, building consensus, finding anomalies, new ideas | Author presents to reviewers. Reviewers may prepare but is not required. Open-ended discussion. |
| Technical review | Medium | Moderator (not author) | Technical decisions + quality evaluation | Technical experts only (developers, architects). Focuses on technical correctness. No mandatory metrics. |
| Inspection | Highest | Moderator (not author) | Find maximum anomalies | Formal process, defined entry/exit criteria, metrics collected. Author cannot be leader or scribe. Individual review before meeting (preparation mandatory). |
• "Who leads a Walkthrough?" → Author (only review type led by the author)
• "Which is most formal?" → Inspection
• "Which collects metrics?" → Inspection
• "Which has no formal output?" → Informal
Formality spectrum at a glance
lowest
author-led
medium
highest
← Less formal More formal →
Static testing vs dynamic testing (K2)
Side-by-side comparison
| Aspect | Static Testing | Dynamic Testing |
|---|---|---|
| Code execution | ❌ No execution required | ✅ Must execute the code |
| What it finds | Defects directly (anomalies in the work product) | Failures first → then debugging to find underlying defect |
| Best for | Non-executable work products, early SDLC | Executable code, later SDLC |
| Prerequisites | Good review process + preparation time | Test environment, test data, and infrastructure |
| Dependency | Reviewer skill & attention | Code must be ready to run |
| Cost timing | Finds early → cheap to fix | Finds later → more expensive and time-consuming to fix |
| Quality characteristics | Maintainability, security (non-runtime) | Performance, reliability (runtime) |
| Typical defects | Requirements issues, design flaws, unreachable code, interface mismatches | Runtime failures, logic errors, race conditions, memory leaks |
| Coverage | Risk of missing defects in non-executable items | Harder to achieve 100% coverage due to complexity |
| Complementary? | Yes — they are complementary. Neither replaces the other. | |
Unique defects each type finds
Only static testing can find:
- Unreachable / dead code
- Undefined variables
- Missing requirements coverage in design
- Wrong design patterns
- Interface definition mismatches
- Ambiguous or contradictory requirements
- Security vulnerabilities in code structure
Only dynamic testing can find:
- Runtime failures and crashes
- Memory leaks (appear only under execution)
- Performance bottlenecks under load
- Timing & race conditions
- Integration failures between live components
- Environment-specific defects
Static testing methods — two types
Reviews (manual)
Human inspection of a work product. Types: Informal, Walkthrough, Technical, Inspection.
Applies to: requirements, design, code, test cases, user stories, contracts — anything readable.
Static analysis (automated tools)
Tools analyse code or models without running them. Examples: linters, code quality tools (SonarQube), compilers, spell checkers.
Very efficient in CI/CD pipelines — runs automatically on every commit.
All 10 keywords (K1 — recall all)
| Term | Definition |
|---|---|
| static testing | Testing that does not involve execution of the software under test — uses reviews or static analysis tools |
| dynamic testing | Testing that involves executing the software under test to observe its behaviour |
| static analysis | Automated processing of a software work product to detect issues without executing it (e.g., linters, compilers, code quality tools) |
| review | A type of static testing in which a work product is manually examined by one or more individuals to find anomalies |
| informal review | The least formal review type — no defined process or mandatory output. Done ad hoc. |
| walkthrough | A review type led by the author — primary objectives are learning, consensus, and finding anomalies. Reviewers may prepare but it is not required. |
| technical review | A medium-formality review focused on technical quality and decisions, led by a moderator, attended by technical experts |
| inspection | The most formal review type — led by a moderator (not the author), defined entry/exit criteria, metrics collected, maximum defect finding. Author cannot be leader or scribe. |
| formal review | A review that follows a defined process with documented results — includes Technical Review and Inspection |
| anomaly | Any condition that deviates from expectation — found during a review or test. May or may not turn out to be a real defect. |
• "Which review type is led by the author?" → Walkthrough only
• "Which review collects metrics?" → Inspection only
• "Which review has no mandatory output?" → Informal
• "Static testing finds failures" → FALSE — it finds defects directly (not failures)
• "Dynamic testing finds defects directly" → FALSE — it finds failures first, then debugging finds the defect