AST — Applied Software Testing

Chapter 4: Static Testing

Complete Study Notes

4.0 Introduction to Static Testing

Definition
"Static testing is a testing technique where work products are examined and analyzed WITHOUT
executing the software."

Two Ways to Perform Static Testing

Method Description

Manual One or more persons closely examining documents

Tool-based Using automated analysis tools

Core Concept — Prevention

"The underlying concept of static testing is PREVENTION — find errors BEFORE they cause damage."
• Errors identified before they negatively affect further development
• All relevant work products quality-assured before further work begins
• Prevents faulty interim products from entering development flow
• Fixing a fault in a document is far cheaper than fixing it in finished code
• Especially important in safety-critical industries like aviation and medicine

Static vs Dynamic Testing

Aspect Static Testing Dynamic Testing

Execution No execution of software Software is executed

What is tested Any work product Executable program

When During/before coding After coding

Finds faults Before coding stage After coding stage

 Example Review of requirements doc Running test cases on software

4.1 What Can We Analyze and Test?

Static testing is a versatile technique — it can be applied to almost anything produced during development.

Work Products That Can Be Statically Tested

Category Examples

Requirements & Specifications Functional, non-functional, security requirements, business requirements, epics and user stories (

Design Documents Architecture specs, design specifications, class diagrams, UML models

Code Source code, website code, link verification, programming guideline checks

Testing Documents Test plans, test cases, test procedures, scripts, acceptance criteria

Project Documents Contracts, project plans, schedules, budgets, user manuals

Types of Defects Found by Static Analysis

Defect Type Meaning

Inconsistencies Parts of document contradict each other

Ambiguities Unclear statements open to interpretation

Contradictions Direct conflicts between statements

Gaps Missing information or requirements

Inaccuracies Incorrect information

Redundancies Repeated or duplicate content

Bonus Benefit — Process Improvement

• If certain defects occur repeatedly during specific development steps — that step needs investigation
• Usually accompanied by additional staff training and process changes

4.2 Static Test Techniques

Human Skills Are Essential

• Static testing relies on human mental and analytical skills
• People must understand the documents they are reading
• Must comprehend the statements and definitions contained
• Static tests are often the ONLY effective way to check the semantics of documentation
Static testing techniques differ in:
Factor Explanation

Thoroughness How deeply they examine the work product

Resources required How many people and how much time needed

Objectives pursued What they are trying to achieve

The Review — Most Important Technique

"The review is the commonest and most important static testing technique."

Multiple Meanings of 'Review'

Usage Meaning

Specific meaning Static analysis of a specific work product

General meaning All static analysis techniques performed by humans

Inspection Formal execution of a static test with metrics and data collection according to predefined rules

Informal vs Formal Reviews

Aspect Informal Review Formal Review

Process No predefined process Predefined process

Results No clear definition of intended results Planned set of results documented

Logging Nothing logged Everything documented

Structure Flexible Strict

Factors That Determine Which Review to Choose

Factor Question to Ask

Development lifecycle model Which model are you using? Which interim results are suitable for review?

Maturity of development process How mature is the process? How high is document quality?

Complexity of documents Which documents are complex enough to need a formal review?

Legal or regulatory requirements Which regulations must be followed? What proof of QA is required?

Review Objectives Determine Review Type

Objective Type of Review Needed

Defect detection Formal, thorough review

General comprehensibility Less formal review

Familiarizing new team members Walkthrough style review

Reaching consensus decisions Group review

4.3 The Review Process

The review process has 6 main activities:

Step Activity Key Action

1 Planning Decide what, how, who, and when to review

2 Initiating (Kick-off) Distribute all materials and explain objectives

3 Individual Preparation Each reviewer studies document intensively

4 Issue Communication & Analysis Collate, discuss and classify all findings

5 Fixing Author corrects identified defects

6 Reporting Document findings, check exit criteria, gather metrics

Activity 1 — Planning
Who does it? Project Management is responsible.

Task Detail

Choose documents Decide which documents or parts need reviewing

Choose review type Decide which type of review to conduct

Define roles Select skilled participants and assign roles

Define quality characteristics Decide which characteristics to evaluate

Estimate effort Plan how long each review will take

Check document readiness Verify authors confirm documents are reviewable

Define viewpoints Assign different aspects to different reviewers

Entry/exit criteria Formal reviews require these to be predefined

• Different viewpoints increase effectiveness of the review

• You do NOT have to review the entire document — focus on high-risk parts
• If entry criteria not met — formal review should NOT begin

Activity 2 — Initiating (Kick-off)

"The point at which all participants receive all necessary materials to begin the review."

Method Description

Simple written invitation Basic notification with materials attached

Pre-review meeting Discuss importance, purpose and objectives face to face

Baseline Documents
"Materials that help decide whether something is a deviation, fault/defect, or correct statement."
• Examples: use cases, design documents, guidelines, standards
 • Checklists and logging forms also distributed at kick-off
• Formal review: if entry criteria NOT fulfilled — review must be CANCELLED

Activity 3 — Individual Preparation

"A review can only be successful if ALL participants are well prepared."
• Each reviewer individually and intensively studies the review object
• Uses baseline documents as reference
• Notes defects, recommendations, questions and comments

Activity 4 — Issue Communication and Analysis

All individual findings are collated and discussed as a group.

Method Description

Review meeting Face-to-face discussion of findings

Online forum Company internal remote discussion

Review Team Recommendation

Recommendation Meaning

Accepted without changes (or slight changes) Document is good — minor tweaks only

Revision necessary Document needs significant rework

Not accepted Document is completely rejected

Defect Classification
Classification Meaning

Critical Not suitable for intended purpose — MUST be corrected before release

Major defect Usability limited — MUST be corrected before release

Minor defect Slight deviation (e.g. grammatical error) — does NOT affect usage

Good Free of defects — do NOT alter during revision

Rules for Review Meetings

Rule Reason

Limit meeting to 2 hours Longer meetings lose focus — hold follow-up next day if needed

Moderator can cancel if unprepared Unprepared reviewers waste everyone's time

Discuss work product NOT the author Avoid personal criticism — focus on the document

Author must not defend themselves But can justify decisions if useful

Moderator cannot be a reviewer Conflict of interest

No general style discussions Only discuss what is covered by review criteria

 No solution development Review team finds problems — not solutions

Every reviewer must present findings Ensure all voices are heard

Reach and record consensus Agreement must be documented

Findings NOT as correction instructions Suggestions for improvement are fine — not orders

Activities 5 & 6 — Fixing and Reporting

• As a rule — the AUTHOR rectifies any defects revealed by the review
• Review meeting minutes contain all required information
• Defects can also be communicated directly — requires good interpersonal skills

Extra Steps for Formal Reviews

Extra Step Detail

Record defect status Current status of each defect must be tracked

Status change requires agreement Only possible with responsible reviewer's agreement

Check exit criteria Must verify all exit criteria have been fulfilled

Evaluate results Helps improve the review process itself

Update guidelines/checklists Keep documentation current

Gather metrics Required for process improvement

Complete Chapter 4 Summary

Concept Key Point

Static Testing Testing without executing the software

Core Concept Prevention — find errors before they cause damage

Two methods Manual review OR tool-based analysis

What is tested Requirements, design, code, test docs, project docs

Defects found Inconsistencies, ambiguities, gaps, contradictions, redundancies

Process improvement Repeated defects signal need for process optimization

Human skills Essential for understanding document semantics

Review Most important static testing technique

Informal review No predefined process, nothing logged

Formal review Predefined process, everything documented

Choice of review Depends on lifecycle model, maturity, complexity, regulations

Review objectives Defect detection, comprehensibility, familiarization, consensus

Review process Plan, Kick-off, Prepare, Analyze, Fix, Report

Defect classification Critical, Major, Minor, Good

Recommendation Accept, Revise, or Reject

Baseline documents Reference materials used to judge correctness

Entry/exit criteria Must be defined and fulfilled in formal reviews

Meeting rules 2 hours max, discuss product not author, no solutions

Fixing Author corrects defects

Formal review extras Status tracking, exit criteria check, metrics

End of Chapter 4 Notes