3.

Static Testing 1
 3.1 Static 2

Testing Basics
Static Testing
Keywords

 Static testing
Testing a work product without the work product code being executed.

 Dynamic testing 3

Testing that involves the execution of the test item.

Dynamic/Static testing - web page
Web page dynamic tests are nothing more than, for example, verifying (by clicking) the purchasing
process.

1
2

3
4
Dynamic/Static testing - web page
Web page static tests are testing the page structure.

CAN THE STRUCTURE OF THE WEB

PAGE BE OPTIMIZED?

Web page structure

Reference: https://www.marketing91.com/what-is-website-architecture/
Dynamic/Static testing - web page

YES
The architecture shown on the left is
unbalanced - one branch is very deep, and
page 3, 4, 5 are located just below the main
page. As a result, it takes as many as ve clicks
to get to pages 12, 13, 14. The architecture on
the right is better - each page can be accessed
in at most two steps. 6

Example website structure optimization

"A Study Guide to the ISTQB® Foundation Level 2018 Syllabus" - Adam Roman
 3.1.1 Work
Products that
Can Be 7

Examined by
Static Testing
Work Products that Can Be Examined by Static Testing
Static testing techniques provide a variety of bene ts. When applied early in the software
development lifecycle, static testing enables the early detection of defects before dynamic testing is
performed.

Almost any work product can be examined using static testing, for example:
Speci cations, including business User guides WordPress User Manual,
requirements, functional requirements, and Web pages
security requirements 8
Contracts, project plans, schedules, and
Epics, user stories, and acceptance criteria budget planning
Architecture and design speci cations Con guration set up and infrastructure set
WordPress Database Documentation, up
Code WordPress application code, Models, such as activity diagrams
Testware, including test plans, test cases, test
procedures, and automated test scripts
3.1.2 Bene ts
of Static 9

Testing
Bene ts of Static Testing
Bene ts of static testing:
Detecting and correcting defects more
e ciently, and prior to dynamic test
execution
Identifying defects which are not easily found
by dynamic testing
Preventing defects in design or coding by
uncovering inconsistencies, ambiguities,
• Reducing testing cost and time
• Reducing total cost of quality over the
software’s lifetime, due to fewer failures later
in the lifecycle or after delivery into operation
• Improving communication between team
members in the course of participating in
reviews 10

contradictions, omissions, inaccuracies, and

redundancies in requirements
Increasing development productivity
Reducing development cost and time
Bene ts of Static Testing

11

Reference: "Code Complete 2nd Edition" MaConnell S., 2004.

Reference: 3. Early testing saves time and money.

 3.1.3
Di erences
between 12

Static and
Dynamic
Testing
Defects static testing
Defects Examples
Requirement defects
• inconsistencies

• ambiguities

• contradictions

• contradictions

• inaccuracies

• redundancies

Design defects
• ine cient algorithms or database structures

• high coupling
13
• low cohesion

Coding defects
• variables with unde ned values

• variables that are declared but never used

• unreachable code

• duplicate code

Deviations from standards

• lack of adherence to coding standards

Incorrect interface speci cations

• di erent units of measurement used by the calling system than by the called system

Security vulnerabilities
• susceptibility to bu er over ows

Gaps or inaccuracies in test basis

traceability or coverage • missing tests for an acceptance criterion
Dynamic/Static testing - web page
Let's go back to the example with web page tests.

WHAT FAILURES CAN WE FOUND BY DYNAMIC TESTING AND WHAT

DEFECTS WILL WE FOUND WHEN TESTING A STATIC WEB PAGE?
14
Dynamic/Static testing - web page

Dynamic testing Static testing

Failures (dynamic tests) / Defects
(static tests)
• possibility of registering the same user
many times
• incorrectly API connection to
payment system

• no validation of the e-mail eld • lack of adherence to coding

standards
• problem with bonus codes 15

• incorrect display of product graphics • variables that are declared but

never used

• inconsistencies requirements
3.2 Review 16

Process
Reviews
Reviews vary from informal to formal

 Formal review  Informal review

A type of review that follows a de ned process with a A type of review that does not follow a de ned process
formally documented output. and has no formally documented output.
17
Reviews

Although reviews can be used for various purposes, one of the main objectives is to uncover defects.

The types of reviews:

formal review
informal review (e.g., buddy check, pairing, pair review)
walkthrough
18
inspection

Further, more detailed reviews and roles are possible, as described in ISO standard (ISO/IEC 20246)
3.2.1 Work
Product 19

Review
Process
Review process
1. Planning
De ning the scope, which includes the
purpose of the review, what documents or
parts of documents to review, and the quality
characteristics to be evaluated
Estimating e ort and timeframe
Identifying review characteristics such as the
review type with roles, activities, and 20

checklists
Selecting the people to participate in the
review and allocating roles
De ning the entry and exit criteria for more
formal review types (e.g., inspections)
Checking that entry criteria are met (for more
formal review types)
Review process
2. Initiate review
Distributing the work product (physically or
by electronic means) and other material,
such as issue log forms, checklists, and
related work products
Explaining the scope, objectives, process,
roles, and work products to the participants
Answering any questions that participants 21

may have about the review

Review process
3. Individual review (i.e., individual
preparation)
Reviewing all or part of the work product
Noting potential defects, recommendations,
and questions

22
Review process
4. Issue communication and analysis
Communicating identi ed potential defects
(e.g., in a review meeting)
Analyzing potential defects, assigning
ownership and status to them
Evaluating and documenting quality
characteristics
Evaluating the review ndings against the exit 23

criteria to make a review decision (reject;

major changes needed; accept, possibly with
minor changes)
Review process
5. Fixing and reporting
Creating defect reports for those ndings
that require changes to a work product
Fixing defects found (typically done by the
author) in the work product reviewed
Communicating defects to the appropriate
person or team
Recording updated status of defects (in 24

formal reviews), potentially including the

agreement of the comment originator
Gathering metrics (for more formal review
types)
Checking that exit criteria are met (for more
formal review types)
Accepting the work product when the exit
criteria are reached
3.2.2 Roles and
responsibilities 25

in a formal
review
Roles and responsibilities

Management
• Is responsible for review planning
• Decides on the execution of reviews
• Assigns sta , budget, and time
•
26
Monitors ongoing cost-e ectiveness
• Executes control decisions in the event of inadequate outcomes
Roles and responsibilities

Review leader
• Takes overall responsibility for the review
• Decides who will be involved and organizes when and where it will take place

27

Facilitator (often called moderator)

• Ensures e ective running of review meetings (when held)
• Mediates, if necessary, between the various points of view
• Is often the person upon whom the success of the review depends
Roles and responsibilities

Author
• Creates the work product under review
• Fixes defects in the work product under review (if necessary)

28

Reviewers
• May be subject matter experts, persons working on the project, stakeholders with an interest in
the work product, and/or individuals with speci c technical or business backgrounds
• Identify potential defects in the work product under review
• May represent di erent perspectives (e.g., tester, developer, user, operator, business analyst,
usability expert, etc.)
 Roles and responsibilities

Scribe (or recorder)

• Collates potential defects found during the individual review activity
• Records new potential defects, open points, and decisions from the review meeting (when held)

In addition, with the advent of tools to support the review process, especially the logging of defects, 29

open points, and decisions, there is often no need for a scribe.

 In some review types, one person may play more than one role, and the actions associated with each role may also vary
based on review type
3.2.3 Review 30

Types
Informal review (e.g., buddy check, pairing, pair review)

Main purposes • detecting potential defects

Possible further purposes • generating new ideas or solutions, quickly solving minor problems

Formal / informal • Not based on a formal (documented) process

• May not involve a review meeting

Implementation • May be performed by a colleague of the author (buddy check) or by more people
31

• Results may be documented

• Use of checklists is optional

Additional • Varies in usefulness depending on the reviewers

• Very commonly used in Agile development

Walkthrough

Main purposes • nd defects

• improve the software product

• consider alternative implementations

• evaluate conformance to standards and speci cations

Possible further purposes • exchanging ideas about techniques or style variations

• training of participants

• achieving consensus 32

Formal / informal • May vary in practice from quite informal to very formal

Implementation • Review meeting is typically led by the author of the work product

• Scribe is mandatory

• May take the form of scenarios, dry runs, or simulations

• Potential defect logs and review reports are produced

Additional • Individual preparation before the review meeting is optional

Technical review

Main purposes • gaining consensus

• detecting potential defects

Possible further
purposes
• evaluating quality and building con dence in the work product

• generating new ideas

• motivating and enabling authors to improve future work products

• considering alternative implementations

•
33
Formal / informal Review meeting is optional

Implementation • Reviewers should be technical peers of the author, and technical experts in the same or other
disciplines

• Review meeting is optional, ideally led by a trained facilitator (typically not the author)

• Scribe is mandatory, ideally not the author

• Use of checklists is optional

Additional • Individual preparation before the review meeting is required

Inspection
Main purposes • detecting potential defects

• evaluating quality and building con dence in the work product

• preventing future similar defects through author learning and root cause analysis

Possible further
purposes
• motivating and enabling authors to improve future work products and the software
development process

• achieving consensus

Formal / informal • Follows a de ned process with formal documented outputs, based on rules and checklists
34
Implementation • Reviewers are either peers of the author or experts in other disciplines that are relevant to the
work product

• Speci ed entry and exit criteria are used

• Scribe is mandatory

• Review meeting is led by a trained facilitator (not the author)

• Author cannot act as the review leader, reader, or scribe

• Potential defect logs and review report are produced

Additional • Individual preparation before the review meeting is required

• Metrics are collected and used to improve the entire software development process
3.2.4 Applying
Review 35

Techniques
Review techniques
There are a number of review techniques that can be applied during the individual review (i.e.,
individual preparation) activity to uncover defects.
Examples of di erent individual review techniques for various review types are listed below.

• Ad hoc,
• Checklist-based
• Scenarios and dry runs 36

• Perspective-based
• Role-based
Review techniques
AD HOC Checklist-based

• little or no guidance on how this task should • systematic technique

be performed
• systematic coverage of typical defect types
• technique needing little preparation
• consists of a set of questions based on
• many duplicate issues being reported by potential defects
di erent reviewers
37

Tasks, tasks, subtasks ...

"Reviewers paddle one's own canoe"
Review techniques
Scenarios and dry runs Role-based

• scenario-based review • reviewers evaluate the work product from the

perspective of individual stakeholder roles
• structured guidelines on how to read through
the work product
• speci c end user types
• simple checklist entries
• reviewers should not be constrained to the • experienced
documented scenarios • inexperienced 38

• senior
• child, etc
• speci c roles in the organization

• user administrator
• system administrator
• performance tester, etc.
Review techniques
Perspective-based

• reviewers take on di erent stakeholder

viewpoints in individual reviewing

• end user, Empirical studies have shown perspective-based

• marketing reading to be the most e ective general
technique for reviewing requirements and
• designer, 39
technical work products. A key success factor is
• tester, etc.
including and weighing di erent stakeholder
• requires the reviewers to attempt to use the viewpoints appropriately, based on risks.
work product
• using checklist
 TASK
2 40

Review techniques
TASK 2
The company you work for is taking part in the tender for "Design, execution and implementation of a local IT system for the
City Clinic in Warsaw". The tender includes the delivery of the Local Information System along with the implementation of
functionalities in the eld of medical activity (including electronic medical documentation), delivery and implementation of e-
services for patient service. The system will be used by the following people:

• Registrar / Nurse - 20 users

• Doctor - 20 users

• Physiotherapist - 3 users

• Statistics - 2 users

• Pharmacy Technician - 1 users 41

Your task is to review the design graphical user interface (GUI) based on mock-ups provided by the web designer.

What review technique works best for your task?

3.2.5 Success
Factors for 42

Reviews
Success factors for reviews
Organizational success factors:
clear objectives, de ned during review
planning, and used as measurable exit
criteria
Review types are applied which are
suitable to achieve the objectives
Any review techniques used, such as
checklist-based or role-based reviewing
People-related success factors:
• The right people are involved to meet the
review objectives
• Testers are seen as valued reviewers
• Participants dedicate adequate time and
attention to detail
• Reviews are conducted on small chunks
43

Large documents are written and reviewed

in small chunks
Participants have adequate time to
prepare
Reviews are scheduled with adequate
notice
Management supports the review process
Reviews are integrated in the company's
quality and/or test policies
• Defects found are acknowledged, appreciated,
and handled objectively
• The meeting is well-managed
• The review is conducted in an atmosphere of
trust
• Adequate training is provided
• A culture of learning and process
improvement is promoted
Chapter SUMMARY 44
SUMMARY

After this chapter you should be able to:<

Recognize types of software work product that can be examined by the di erent static testing
techniques
Use examples to describe the value of static testing
Explain the di erence between static and dynamic techniques, considering objectives, types of
defects to be identi ed, and the role of these techniques within the software lifecycle
Summarize the activities of the work product review process 45

Recognize the di erent roles and responsibilities in a formal review

Explain the di erences between di erent review types: informal review, walkthrough, technical
review, and inspection
Apply a review technique to a work product to nd defects
Explain the factors that contribute to a successful review.
 Time
for Quiz 3 46

Static Testing
 The end 47
Go to next chapter