Unit 3: Static Testing

Static Testing

Examines software work products without executing the software

Before

Static Testing focuses on finding detects ____ the program is run

Manual Reviews

Automated Static Analysis

(2) Static Testing is Performed Through

Peer Reviews

Walkthroughs

Inspections

Code Reviews

(4) Examples of Manual Reviews

SonarQube

Tool Example for Automated Static Analysis

Static Testing

It may be applied to requirements, designs, documentations, and source code

Detect Defects Early and Improve Software Quality

(2) Main Goal of Static Testing

Static Testing

Evaluating work products through manual examination or tools without executing the software. SonarQube represents the automated side of this by checking code for quality and security issues before release.

Software Artifact

Review/Static Analysis

Defects Found

Fix

(4) Process of Static Testing

Requirements Specifications

Design/Architecture

Source Code

Test Plans

Test Cases/Scripts

Project Documentation

(6) Documents/Deliverables Examined

Requirements Specifications

This document/deliverable checks:

Missing, unclear, conflicting requirements

Design/Architecture

This document/deliverable checks:

Incorrect or inconsistent design decisions

Source Code

This document/deliverable checks:

Bugs, vulnerabilities, code smells, standards violations

Test Plans

This document/deliverable checks:

Missing scope, objectives, or test coverage

Test Cases/Scripts

This document/deliverable checks:

Incorrect steps, expected results, or incomplete coverage

Project Documentation

This document/deliverable checks:

Inconsistencies, omissions, unclear information

User Stories

Product Backlog Items

Models

Contracts

Test Charters

(5) Other Examinable Work Products

True

(T/F) ISTQB states that almost any readable and understandable work product can undergo review.

True

(T/F) For source code specifically, tools such as SonarQube automatically identify issues related to reliability,

maintainability, and security.

Software is not executed for Static; Software is executed for Dynamic

Static vs Dynamic Testing - Execution

Work products and defects

Static Testing - Focus

Software behavior and failures

Dynamic Testing - Focus

Static can start very early; Dynamic requires executable software

Static vs Dynamic Testing - When

Reviews, Inspections, SonarQube

(3) Examples of Static Testing *table pg 10

Unit, Integration, System Testing

(3) Examples of Dynamic Testing *table pg 10

Static finds defects directly; Dynamic finds failures caused by defects

Static vs Dynamic Testing

Requirements

Designs

Code

Documents

(4) Static Testing Can Examine

Executable Software

Dynamic Testing Can Examine

Unreachable Code and Unclear Requirement

(2) Static Testing Example Issue

Incorrect Output

Crash

Slow Response

(3) Dynamic Testing Example Issue

Early Defect Detection

Improved Stakeholder Understanding

Better Communication

Reduced Later Corrective Effort

(4) Static Testing Benefits and Importance

Human Code Review

Research supports combining Automated Static-Analysis Tools with _______

True

(T/F) A study of OpenStack and Qt found that human review remains valuable for security-defect detection because automated tools do not capture every context or scenario.

False. The empirical comparison of static-analysis tools found SonarQube effective in detecting software defects across Java, C++, and Python datasets

(T/F) A 2024 empirical comparison of static-analysis tools did not find SonarQube effective in detecting software defects across Java, C++, and Python datasets.

Software Review

Is a structured examination of a work product.

Requirements Document

Design

Source Code

Test Plan

(4) A Software Review can be any of the following:

Software Review

This is carried out by one or more

individuals to find anomalies, evaluate

quality, gain understanding, or reach

agreement, without executing the software; also making it a form of static testing.

Planning

Kick Off

Preparation

Review Meeting

Rework

Follow Up

(6) Formal Review Process Phases

Planning

In this Formal Review Process Phase, The team reviews the enrollment requirements because past projects suffered from ambiguous requirements. A technical review with a checklist technique is chosen.

Kick Off

In this Formal Review Process Phase, The requirements document and checklist are distributed to the tester, developer, analyst, and a user representative.

Preparation

In this Formal Review Process Phase, Each reviewer independently reads the document. One flags: "The system shall process enrollment quickly."

Review Meeting

In this Formal Review Process Phase, The team agrees that "quickly" is an ambiguous, untestable term.

Rework

In this Formal Review Process Phase, Comments may be informal

Follow Up

In this Formal Review Process Phase, The moderator confirms the correction was made and closes

the issue.

Manager

Author

Moderator/Facilitator

Review Leader

Reviewer(s)

Scribe/Recorder

(6) Key Roles

Manager

Decides what work products get reviewed and provides the

necessary staff, time, budget, and resources; supports the

process from a project-management level without joining the

technical discussion directly.

Author

Creates the work product under review. They clarify unclear points for reviewers and are responsible for fixing the defects that are found.

Moderator/Facilitator

Runs the review meeting itself by managing the time, keeping

discussion focused and constructive, and mediating disagreements between participants. Remains neutral and does not hunt for defects personally.

Review Leader

Holds overall responsibility for the review, who is responsible

for deciding who is invited, and when and where it happens,

and oversees the process from planning through follow-up.

Review Leader

In many organizations this role is combined with the moderator.

Reviewer(s)

Individuals with relevant technical or business backgrounds (e.g. developer, tester, business analyst, user representative) who examine the work product and identify and describe defects. Reviewers are deliberately chosen to represent different perspectives.

Scribe/Recorder

Logs every defect, issue, question, open point, and decision raised during the review meeting, and produces the review record/report so nothing discussed is lost.

Review Type

"What kind of review are we conducting?"

Review Technique

"How will reviewers actually examine the work product?"

Review Types

This sits along a spectrum of formality, from no defined process at all, to a fully documented procedure with metrics and sign-off.

Informal Review

Walkthrough

Technical Review

Inspection

(4) Types of Reviews

Informal Review

This type of review is led by anyone (peer)

Walkthrough

This type of review is led by the author

Technical Review

This type of review is led by a trained moderator (not by the author)

Inspection

This type of review is led by a trained moderator / facilitator (not the author)

Informal Review

This type of review has no formal process or required documentation. It is an inexpensive way to get quick feedback (e.g., a colleague reading over a draft, or pair programming). Its usefulness, however, varies with the reviewer.

Walkthrough

This type of review has an Author-led, step-by-step session, often using

scenarios/dry runs; preparation is optional. The main purpose is to build common understanding, knowledge-

sharing, and gather feedback.

Technical Review

This type of review is formal and planned in advance (date, attendees, venue set beforehand) and focuses on technical correctness and reaching consensus on specifications/test plans. It produces documented findings.

Inspection

This type of review is the most formal type which involves strict entry/exit

criteria, clearly defined roles, checklists, detailed defect logging, and metrics collection. It is aimed at finding the

maximum number of defects.

True

(T/F) During individual preparation, reviewers can be guided by one of several review techniques. These determine how a reviewer reads the document, not how formal the overall review meeting is.

Ad Hoc

It involves little to no structured guidance and the reviewer reads freely and reports issues as they're noticed.

Ad Hoc

This technique is best for quick, low-stakes reviews; highly dependent on the individual reviewer's skills and may produce duplicate findings

Checklist-based

Reviewers work through a maintained list of questions targeting common defect types (e.g., "Is every requirement testable?"), while still watching for issues

outside the list.

Checklist-based

This technique is best for recurring reviews of similar artifacts where known

defect patterns exist; gives systematic, repeatable coverage.

Scenario-based

Reviewers perform structured "dry runs" of the work product based on its expected usage (e.g., a user's step-by-step journey through a system).

Scenario-based

This technique is best for requirements or designs for workflow-heavy systems,

where missing steps or exception handling need to surface.

Role-based

Reviewers evaluate the product from the

perspective of a specific stakeholder role (e.g., new user, system administrator, security auditor).

Role-based

This technique is best for systems with sharply different types of users, where

each role would care about different requirements.

Perspective-based

Similar to role-based, but reviewers adopt broader stakeholder viewpoints (end user, tester, designer, operations) and may try to produce the output that stakeholder would normally derive (e.g., a tester drafting test cases from the requirements).

Perspective-based

This technique is best for requirements involving many stakeholder groups; uncovers gaps a single-viewpoint read would miss.

True

(T/F) Techniques are not mutually exclusive. A sample scenario is when a tester uses a checklist while reviewing specifically from the tester's perspective, combining systematic coverage with domain-specific insight. Choosing a technique depends on the review's objective, the type and criticality of the work product, available time, and the reviewers' expertise.

Software Inspection

Is a formal and systematic peer review used to identify defects in software work products without executing the software. It can be applied to requirements, designs, source code, test cases, and other technical documents.

Structured and Defect-Focused

(2) Inspection Characteristic

*check page 31

What Makes Inspections DIFFERENT from Other Reviews?

Informal Review

Walkthrough

Technical Review

Inspection

(4) Examples of Other Reviews

Informal Review

Flexible review with little or no

formal process; commonly used for

quick feedback

Walkthrough

Usually led by the author to explain

the work and gather comments or

identify issues

Technical Review

Conducted by technically qualified

peers to evaluate technical

correctness and alternatives

Inspection

Formal, role-based, prepared,

defect-focused, documented, and

followed by rework and verification

True

(T/F) Every inspection is a review, but not every review is an inspection

Find Problems Early

Reduce Rework

Improve Quality and Development Practices

(3) Why Are Inspections Valuable?

Find Problems Early

Inspections detect defects in requirements, designs, and code before they develop into larger problems later in the software lifecycle.

Reduce Rework

Correcting defects early prevents them from spreading into later designs, code, and tests, reducing unnecessary debugging and redevelopment.

Improve Quality and Development Practices

Inspection results help teams improve software quality, share technical knowledge, identify recurring defects, and improve future development processes.

Static Analysis or Static Program Analysis

Is a process to discover the

semantics or semantic properties of a system or program without running them.

Static Testing

...is a narrower process focused on the source code, abstract syntax trees (AST), bytecode, and configuration files, including syntax, logic, and technical flow.

Static Analysis

...is a broader process covering

requirements and design documentation, client or user needs, and system infrastructure.

1. Verification of Specifications

2. Verification of Programs

3. Synthesis of Optimized Code

4. Refactoring and Maintenance of Software Applications

(4) Static Analysis Key Roles in Program Development - According to Rival and Yi (2020)

Analyzed Material (Source Code, Config Files, Compiled ByteCode) -> Static Analysis Tools -> Potential Findings (Vulnerabilities, Defects, Requirement Deviations, and Documentation Non-Compliance)

What Static Analysis Looks For *page 50

SonarQube

Semantic GREP

CodeQL

Coverity

(4) Static Analysis Tools

SonarQube

This static analysis tool continuously inspects source code for bugs, vulnerabilities, code smells, and duplication.

1. Enforces Quality Gates in CI/CR and IDEs

2. Tracks Code Health Metrics

(2) Key Features of SonarQube

Semantic GREP

This static analysis tool is a fast, lightweight SAST engine that detects vulnerabilities, secrets, and policy violations using pattern matching.

1. Custom rules without complex AST scripting

2. Fast cross-file taint analysis

(2) Key Features of Semantic GREP

CodeQL

This static analysis tool treats code as queryable data by compiling codebases into relational databases using its own query language (QL).