Static Testing
Find defects before a single line of code is executed. Master the five review types, their formality ladder, and where SAST tools fit in a modern pipeline.
Static Testing video walkthrough
A guided overview of chapter 3, connecting the exam language to practical testing decisions.
Briefing focus
Testing without executing code
This is a structured lesson briefing. Real video/audio can be added later as a media source.
Estimated time
8 min
- 1Testing without executing code
- 2The five roles in a review
- 3The formality ladder
- 4Static analysis (SAST) tools
Transcript brief
Find defects before a single line of code is executed. Master the five review types, their formality ladder, and where SAST tools fit in a modern pipeline. The walkthrough introduces the core concept, works through a realistic project example, and closes with the mistakes learners most often make in quiz and exam questions.
Key takeaways
- Recognise the exam wording for this chapter.
- Apply the concept to a real software delivery situation.
- Know which detail to check first when a scenario question feels ambiguous.
Testing without executing code
Static testing examines work products — requirements, designs, code, test cases, user manuals — without running the software. It is the cheapest place on earth to find a defect, because nothing has been built yet.
Cost curve
IBM’s long-running studies show a requirement defect found in review costs 1x to fix. The same defect in production costs 30–100x. Static testing is the single highest-ROI QA activity.
The five roles in a review
- Author
- Creator of the work product. Fixes defects identified by reviewers.
- Moderator (facilitator)
- Plans the review, runs the meeting, resolves disputes, signs off.
- Reviewer
- Qualified peer who examines the work product and logs defects.
- Scribe (recorder)
- Documents defects, decisions and action items.
- Review leader
- Overall responsible; decides the review type, schedule and participants.
The formality ladder
| Type | Formality | Defining trait |
|---|---|---|
| Informal review | Lowest | No defined process; a colleague glances at the work product. |
| Walkthrough | Low | Author leads the meeting; goal is knowledge-sharing and early feedback. |
| Technical review | Medium | Peer experts evaluate; focus is technical correctness and standards. |
| Inspection | Highest | Defined entry/exit criteria, trained moderator, metrics collected. |
Real-life scenario · FinTech
A review that saved the trading platform
Situation. During a technical review of a new matching-engine spec, a senior architect spotted an off-by-one error in the order-priority formula. Had it reached code, the bug would have mis-priced every limit order above £1M. The fix in the spec took 30 minutes; the same fix post-release would have required an incident response and FCA notification.
Lesson. Static testing is not a documentation activity — it is a defect-prevention activity with the highest ROI in the QA toolkit.
Static analysis (SAST) tools
Static analysis tools inspect source code without executing it. They catch security vulnerabilities, coding-standard violations and structural issues automatically — ideally on every pull request.
name: Static Analysis
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: yarn install --frozen-lockfile
- run: yarn lint
- uses: SonarSource/sonarcloud-github-action@master
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}Exam tip
Know which tool category solves which problem: SAST = static analysis, DAST = dynamic (runtime) analysis, IAST = interactive (runtime with instrumentation).