Chapter 3: Static Test

The Test of Work Product

Introduction to Static Testing
• Static test is testing conducted without execution of program/codes
• The opposite of static test is actually dynamic test(whereby execution
of codes is needed)
• It can be done by
• Review: manual examination on work product (artefacts of software
development) or I
• Static Analysis : it can be done using tool to perform evaluation of tests
Example of Artefacts or work product
• Specifications, including business requirements, functional requirements, and
security requirements
• Epics, user stories, and acceptance criteria
• Architecture and design specifications
• Code
• Testware, including test plans, test cases, test procedures, and automated test
scripts
• User guides
• Web pages
• Contracts, project plans, schedules, and budgets
• Models
Benefits of static testing
• Promotes early testing
• Identifying defects which are not easily found by dynamic testing
• Preventing defects in design or coding by uncovering inconsistencies, ambiguities,
contradictions, omissions, inaccuracies, and redundancies in requirements
• Increasing development productivity (e.g., due to improved design, more
maintainable code)
• Reducing development cost and time
• 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
Static Testing Vs. Dynamic Testing
• One main distinction is that static testing finds defects in work
products directly rather than identifying failures caused by defects
when the software is run. A defect can reside in a work product for a
very long time without causing a failure. The path where the defect
lies may be rarely exercised or hard to reach, soit will not be easy to
construct and execute a dynamic test that encounters it. Static testing
may be able to find the defect with much less effort
• Another distinction is that static testing can be used to improve the
consistency and intern work products, while dynamic testing typically
focuses on externally visible behaviors
Continued.
Common Requirements defects detectable
1) Ambiguities:
Requirements defined are subjective or not clear.
System shall allow the PM to check the outcome.
2) Incompleteness: No further actions defined.
Eg: Upon three invalid passwords. System shall lock user's account.
3) Untestability: The requirements defined cannot be tested.
Eg: System shall provide 100% availability.
4) Excessive dependencies.
Eg: One module connect to 100 modules. (Low coupling vs high
cohesiveness)
Continued.
• Deviations from standards
• Security vulnerabilities
• Coding defects (data flow and control flows defects)
Work Product Review Process
• Planning
• Initiate Review
• Individual Review
• Issue communication and analysis
• Fixing and reporting
Planning
• Defining 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 effort and timeframe

• Identifying review characteristics such as the review type with roles,

activities, and checklists

• Selecting the people to participate in the review and allocating roles

• Defining the entry and exit criteria for more formal review types (e.g.,
inspections)
• Checking that entry criteria are met (for more formal review types)
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 may have about the review
Individual Review (individual preparation)

Reviewing all or part of the work product

Noting potential defects, recommendations, and questions
Issue communication and analysis
• Communicating identified 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 findings against the exit criteria to make a
review decision (reject; major
changes needed; accept, possibly with minor changes)
Fixing and Reporting
• Creating defect reports for those findings that require changes
• Fixing defects found (typically done by the author) in the work product
reviewed
• Communicating defects to the appropriate person or team (when found in
a work product related to the work product reviewed)
• Recording updated status of defects (in 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
Roles and Responsibilities of individuals in review
A typical formal review will include the roles below:
Author
• Creates the work product under review
• Fixes defects in the work product under review (if necessary)
Management
• Is responsible for review planning
• Decides on the execution of reviews
• Assigns staff, budget, and time
• Monitors ongoing cost-effectiveness
• Executes control decisions in the event of inadequate outcomes
• Facilitator (often called moderator)
• Ensures effective 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 Responsibility (Continued.)
Review leader
• Takes overall responsibility for the review
• Decides who will be involved and organizes when and where it will take place
Reviewers
• May be subject matter experts, persons working on the project, stakeholders with
an interest in the work product, and/or individuals with specific technical or
business backgrounds
• Identify potential defects in the work product under review
• May represent different perspectives (e.g., tester, programmer, user, operator,
business analyst,
usability expert, etc.)
Continued. (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)

ISO standard (ISO/IEC 20246).

Review Types
• Informal Review
• Walkthrough
• Technical Review
• Inspection
Informal Review
Main purpose: detecting potential defects
Possible additional purposes: generating new ideas or solutions,
quickly solving minor problems
Not based on a formal (documented) process
May not involve a review meeting
May be performed by a colleague of the author (buddy check) or by
more people
Results may be documented
Varies in usefulness depending on the reviewers
Use of checklists is optional
Very commonly used in Agile development
Walkthrough
Main purposes: find defects, improve the software product, consider alternative
implementations,
evaluate conformance to standards and specifications
Possible additional purposes: exchanging ideas about techniques or style
variations, training of
participants, achieving consensus
Individual preparation before the review meeting is optional
Review meeting is typically led by the author of the work product
Scribe is mandatory
Use of checklists is optional
May take the form of scenarios, dry runs, or simulations
potential defect logs and review reports may be produced
May vary in practice from quite informal to very formal
Technical Review
• Technical review
Main purposes: gaining consensus, detecting potential defects
Possible further purposes: evaluating quality and building confidence in
the work product, generating new ideas, motivating and enabling authors
to improve future work products, considering alternative implementations
Reviewers should be technical peers of the author, and technical experts
in the same or other
disciplines
Individual preparation before the review meeting is required
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
Potential defect logs and review reports are typically produced
Inspection
Main purposes: detecting potential defects, evaluating quality and building
confidence 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
Follows a defined process with formal documented outputs, based on rules and
checklists
Uses clearly defined roles, such as those specified which are mandatory, and may
include a dedicated reader (who reads the work product aloud during the review
meeting)
Individual preparation before the review meeting is required
Reviewers are either peers of the author or experts in other disciplines that are
relevant to the work product
Inspection (Continued.)
Specified 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
Metrics are collected and used to improve the entire software
development process, including the
inspection process
Success Factors for reviews
Organizational factors:
• Each review has clear objectives, defined during review planning, and used as
measurable exit criteria
• Review types are applied which are suitable to achieve the objectives and are
appropriate to the type and level of software work products and participants
• Any review techniques used, such as checklist-based or role-based reviewing, are
suitable for effective defect identification in the work product to be reviewed
• Any checklists used address the main risks and are up to date
• Large documents are written and reviewed in small chunks, so that quality control is
exercised by providing authors early and frequent feedback on defects
• Participants have adequate time to prepare
• Reviews are scheduled with adequate notice
• Management supports the review process (e.g., by incorporating adequate time for
review activities in project schedules)
Success Factors (People related)
• The right people are involved to meet the review objectives, for example,
people with different skill sets or perspectives, who may use the
document as a work input
• Testers are seen as valued reviewers who contribute to the review and
learn about the work product, which enables them to prepare more
effective tests, and to prepare those tests earlier
• Participants dedicate adequate time and attention to detail
• Reviews are conducted on small chunks, so that reviewers do not lose
concentration during individual review and/or the review meeting (when
held)
• Defects found are acknowledged, appreciated, and handled objectively
• The meeting is well-managed, so that participants consider it a valuable
use of their time
• The review is conducted in an atmosphere of trust; the outcome will not
be used for the evaluation of the participants
Success Factors (People related)
• Participants avoid body language and behaviors that might indicate
boredom, exasperation, or hostility to other participants
• Adequate training is provided, especially for more formal review
types such as inspections
• A culture of learning and process improvement is promoted
Static Analysis
Static Analysis of Program Codes
• Syntax Violations
• Convention and standard deviations
• Security Vulnerabilities
• Control Flow
• Data Flow