STATIC TESTING

GROUP 3
 Learning Objectives for STATIC
TESTING
1. Static Testing Basic
2. Recognize types of software work product that can be
examined by the different static testing techniques
3. Use examples to describe the value of static testing
4. Explain the difference between static and dynamic
techniques
5. Summarize the activities of the work product review process
6. Recognize the different roles and responsibilities in a formal
review
7. Explain the differences between different review types
8. Apply a review technique to a work product to find defects
 STATIC TESTING BASICS

• Static testing is the opposite of Dynamic testing

There are two types of static testing
1. Manual examination of work products (ex: code reviews,
requirements reviews
2. Tool-driven evaluation of code or other work products(static
analysis).
 static analysis

• static analysis is used in aviation, nuclear, and medical

software, and in security testing Both types of testing assess
the code or other work product without executing the code or
other work product being tested.
 Work Products that Can Be Examined
by Static Testing

• Specifications, including business requirements, functional

requirements, and security requirements
• Epics, user stories, and acceptance criteria
• Architecture and design specifications
• Code
 Work Products that Can Be Examined
by Static Testing

• Test ware, including test plans, test cases, test procedures,

and automated test scripts
• User guides
• Web pages
• Contracts, project plans, schedules, and budget planning
• Configuration set up and infrastructure set up
 Benefits of Static Testing

When static testing is applied early in the software

development lifecycle, static testing enables the early detection
of defects before dynamic testing is performed which is much
cheaper and cost effective.
 Other Benefit of Static Testing

1. Detecting and correcting defects more efficiently, and before dynamic test execution
identifying defects that are not easily found by dynamic testing.
2. Preventing defects in design or coding by uncovering inconsistencies, ambiguities,
contradictions, omissions, inaccuracies, and redundancies in requirements
3. Increasing development productivity (e.g., due to improved design, more maintainable
code)
4. Reducing development and testing costs 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
5. Improving communication between team members in the course of participating in
reviews
 DIFFERENCES BETWEEN STATIC AND
DYNAMIC TESTING

Static Testing Dynamic Testing

• Examines code, requirements, or • Involves executing the code and
design without executing them observing its behavior
• Finds defects in work products directly • Identifies failures caused by defects
when the software is run
• Improves consistency and internal
quality • Focuses on externally visible
behaviors
 DIFFERENCES BETWEEN STATIC AND
DYNAMIC TESTING

Static Testing Dynamic Testing

• Defects are easier and cheaper to find • Defects can be harder and more
and fix expensive to find and fix
• Code reviews, inspections, • Unit tests, integration tests, system
walkthroughs, static code analysis tests, acceptance tests
• Performed early in the development • Performed after or during the
lifecycle development phase
• Syntax errors, design flaws, • Runtime errors, performance issues,
documentation issues logical errors
 List of defects that are easier to find
and fix through static testing.
• Requirement defects (e.g., inconsistencies, ambiguities, contradictions,
omissions, inaccuracies, and redundancies)
• Design defects (e.g., inefficient algorithms or database structures, high
coupling, low cohesion)
• Coding defects (e.g., variables with undefined values, variables that are
declared but never used, unreachable code, duplicate code)
• Deviations from standards (e.g., lack of adherence to coding standards)
Security vulnerabilities (e.g., susceptibility to buffer overflows)
 Review Process

TWO TYPES OF REVIEW

Informal Reviews: are characterized by not following a defined process
and not having formal documented output.
Formal Reviews: Formal reviews are characterized by team
participation, documented results of the review, and documented
procedures for conducting the review.
The formality of a review is based on factors such as SDLC, maturity of
the development process, the complexity of the work product any legal
or regulatory requirements, and/or the need for an audit trail.
 Work Product Review Process
1. Planning: This includes defining the scope, time, and effort estimation, selecting
people to participate, success criteria, and identifying review characteristics such
as the review types, roles, and checklist.
2. Initiate review: this involves distributing and explaining the work products,
stating the scope, objectives, and roles, and answering any questions the
participants may have about the review.
3. Individual review: Individual reviewers examine al the parts of the work product
and note potential defects, recommendations, and questions
4. Issue communication and analysis: Communicating identified potential defects,
Analyzing potential defects, assigning ownership and status to them, and
Evaluating the review findings against the exit criteria to make a review decision.
5. Fixing and reporting: Creating defect reports, fixing defects found,
communicating the defect to appropriate people, recording the updated status for
the defects, checking the exit criteria are met, and accepting the work product
when the exit criteria are reached
 Roles and responsibilities in a formal
review
1.Author: create and fix the defect in the work product under review.
2.Management: responsible for the review planning, decides on
execution of the reviews, assigns staff, budget, and time, monitors
ongoing cost-effectiveness, and executes control decisions in the
event of inadequate outcome
3.Facilitator: Ensures effective running of review meetings, mediates
between the various points of view, and is often the person upon
whom the success of the review depends.
4. Review leader: Takes overall
responsibility for the review.
decides who will be involved and
organizes when and where it will
take place
5. Reviewers: May be subject matter
experts, a person working the
project or stakeholders with
interest in the work product. They
identify defects in the work product
6. Scribe (or recorder): Collates
potential defects found during the
individual review activity and
Records new potential defects,
open points, and decisions from
 REVIEW TYPES

• INFORMAL REVIEW: (e.g., buddy check, pairing, pair review) Main

purpose: detecting ponytail defects
• WALKTHROUGH: find defects, improve the software product, consider
alternative implementations, and evaluate conformance to standards and
specifications.
• TECHNICAL REVIEW: gaining consensus, detecting potential defects
• INSPECTION: detecting potential defects, evaluating quality and building
confidence in the work product, preventing future similar defects through
author learning and root cause analysis
 APPLYING REVIEW TECHNIQUES

1.Ad hoc: The reviewers are provided with little to no

guidance on how the review will be carried out. This
technique needs a little preparation. It highly depends on
the reviewer skills and it can lead to duplicates of defects
reported by different reviewers
2.Checklist-based: This is the systematic technique. The
reviewers detect issues based on the given checklist
 APPLYING REVIEW TECHNIQUES
3. Scenarios and dry runs: Reviewers are provided with structured
guidelines on how to read through the work product. The scenarios
provide reviewers with better guidelines on how to identify specific
defect types than simple checklist entries
4. Perspective-based: In perspective-based reading, similar to a role-
based review, reviewers take on different stakeholder viewpoints in
individual reviewing. Typical stakeholder viewpoints include end users,
marketing, designers, testers, or operations.
5. Role-based: A role-based review is a technique in which the reviewers
evaluate the work product from the perspective of individual
stakeholder roles. Ex: experienced, inexperienced, senior, child, etc
 SUCCESS FACTORS FOR REVIEWS

Organizational success factors

1. Reviews are integrated into the company's quality and/or
test policies
2. Participants have adequate time to prepare
3. Reviews are scheduled with adequate notice
4. Management supports the review process
 SUCCESS FACTORS FOR REVIEWS

People-related success factors

1. The right people are involved to meet the review objectives
2. Participants dedicate adequate time and attention to detail
3. Reviews are conducted in small chunks so that reviewers do
not lose concentration
 SUCCESS FACTORS FOR REVIEWS

People-related success factors

4. Defects found are acknowledged, appreciated, and handled
objectively
5. The meeting is well-managed so that participants consider it a
valuable use of their time
6. The review is conducted in an atmosphere of trust; the outcome
will not be used for the evaluation of the participants
 SUCCESS FACTORS FOR REVIEWS

People-related success factors

7. Adequate training is provided, especially in inspections

8. A culture of learning and process improvement is promoted
1. 23860 Iraguha Darren.
2. uwamahoro rebecca 233543
3. 23013 Manzi Niyongira Osee
4. 24247 Mupanda Lubuto Josephus
5. 24002 Senga Samuel Beni
6. Louison Bomposo 23394
7. Aimee Anne Musabwe 24567
8. 23172 Gihozo Pamela
9. 23064 Uwambaza Ruth
10.25207 Mahamat Ali chaha
11.24873 Irakarama Bergerac
12.24287 TUENY ATERDIT RIN
13.24914 Kamugunga Kevin
14.21998 Lilian Ingabire
15.23753 Irakoze Peace Arlaine
16.24749 Irakoze Tresor
17.24706 Mugisha Ivan.
18.24574 Mahamat Bardaga Diar
19. Deodate Mugenzi
20.Rachel Mutoni
21.23874 Uwase K Nicqueuse
22. 22770 Mugisha Donnella Amandine