Software Testing and

Quality Assurance

Chapter 6: Static Testing

1
 Static Testing
 Static testing is a non-execution-based software testing
technique that involves examining source code and
related documentation to identify and rectify defects early
Key Benefits:
 Early Defect Detection: Pinpoints errors early, saving time
and cost.
 Improved Code Quality: Enforces coding standards and
best practices.
 Enhanced Reliability: Reduces vulnerabilities and
improves software robustness.
 There are mainly two type techniques used in Static Testing
1. Review
2. Static Analysis 2
 1. Review
 Static testing review is a systematic process to find and
fix errors in documents like software requirements
specifications.
 It involves:
 Informal Review: A casual discussion among peers to get
feedback.
 Walkthrough: A detailed review by an expert.
 Peer Review: A collaborative review among peers.
 Inspection: A formal review by a higher authority against
standards.
 Code Inspection: Manual review of code for errors,
inconsistencies, and non-compliance
3
 2. Static Analysis
 Static Analysis: Automated analysis using tools to
identify:
 Syntax errors
 Semantic errors
 Security vulnerabilities
 Performance issues
 Static Analysis is of three types:
 Data Flow
 Control Flow
 Cyclomatic Complexity

4
Figure6.1 The role Review in testing 5
 Benefits of Reviews
 Improved quality: Early defect detection leads to reliable
software.
 Increased productivity: Reduced rework and faster
development.
 Enhanced project management: Better scheduling and control.
 Team skill development: Training and quality culture.
 Cost savings: Reduced maintenance costs.
 Customer satisfaction: Higher-quality products.
 Early Detection:
 Simpler identification of defects.
 Lower repair costs.
 Reduced rework.
 Mitigated customer impact.
6
Inspections as a Type of Technical Review

7
Figure6.2 Inspections
Walkthroughs as a Type of Technical Review
 Walkthroughs are a technical review method where the
creator of the material guides the review process.
 Traditionally used for design and code, they involve a
line-by-line examination of the detailed design or code
using specific input values.
 This process, similar to manually executing the code,
allows participants to:
 Build a mental model of the design or code.
 Assess its quality and identify potential defects.

8
 Components of review plans
 An organization should develop a review plan template
that can be applied to all software projects.
 The template should specify the following items for
inclusion in the review plan.
 review goals;
 items being reviewed;
 preconditions for the review;
 roles, team size, participants;
 training requirements;
 review steps;
 checklists and to be disturbed to participants;
 time requirements;
 the nature of the review log and summary report;
9
 rework and follow-up
 Review Goals
 The general goals for the reviewers are to:
 identify problem components or components in the
software artefact that need improvement.
 identify components of the software artefact that do not
need improvement.
 identify specific errors or defects in the software artefact
(defect detection).
 ensure that the artefact conforms to organizational
standards.
 Additional goals might be to establish traceability
 Goals for inspections and walkthroughs are usually different;
those of walkthroughs are more limited in scope and are
usually confined to identification of defects.
10
 Preconditions and Items to be Reviewed
 Given the principal goals of a technical review early
defect detection, identification of problem areas, and
familiarization with software artifacts
 In many organizations the items selected for review
include:
 requirements documents;
 design documents;
 code;
 test plans (for the multiple levels);
 user manuals;
 training manuals;
 standards documents.
11
Roles, Participation, Team Size and Time Requirements

 Two major roles that need filling for a successful

review are (i) a leader or moderator, and (ii) a
recorder.
 These are shown in Figure 6.3. Some of the
responsibilities of the moderator have been described.
 These include planning the reviews, managing the
review meeting, and issuing the review report.
 The success of the review depends on the experience
and expertise of the moderator.

12
Figure 6.3 Review Roles 13
 Review team Members
 Organizational policies guide selection of review team
members. Membership may vary with the type of review
 As shown in Figure 6.4 the review team can consist of
software quality assurance staff members, testers, and
developers (analysts, designers, programmers).
 In some cases the size of the review team will be
increased to include a specialist in a particular area
related to the reviewed item; in other cases “outsiders”
may be invited.
 These outside members may include users/clients.
Users/clients should certainly be present at requirements,
user manual, and acceptance test plan reviews.
14
Figure 6.4 review team

15
 Review Procedures and Training
 For each type of review there should be a set of
standardized steps
 For example, the steps for an inspection are initiation,
preparation, inspection meeting, reporting results, and
rework and follow-up.
Review Training
 Review participants, and especially those who will be
review leaders, need the training.
 Test specialists should also receive review training.
 Suggested topics for a training program are shown in
Figure 6.5 and described below.

16
 1 . Review of Process Concepts
 Reviewers should understand basic process concepts,
the value of process improvement, and the role of
reviews as a product and process improvement tool.

 Figure 6.5 topics 17

 Continued...
2 . Review of Quality Issues
 Reviewers should be made familiar with quality attributes
3 .Review of Organizational Standards for Software
Artefacts
 Reviewers should be familiar with organizational
standards for software artefacts.
4 . Understanding the Material to Be Reviewed
 Concepts of understanding and how to build mental
models during comprehension of code and software-
related documents should be covered.
5 . Defect and Problem Types
 Review trainees aware of the types of problems or errors
that are likely to occur during development. 18
 Continued...
6 . Communication and Meeting Management Skills
 The review leaders has a responsibility to communicate
with the review team, the preparers of the reviewed
document, management, and client
7 . Review Documentation and Record Keeping.
 Review leaders need to learn how to prepare checklists,
agendas, and logs for review meetings.
8 . Special Instructions
 During review training there may be some topics that
need to be covered with the review participants.
9 . Practice Review Sessions.
 Review trainees should participate in practice review
sessions. 19
 Review Checklists
 It provides structure and an agenda for the review
meeting.
 They guide the review activities, identify focus areas for
discussion and evaluation.
 Reviews include :
 Requirements reviews checklists
 Design reviews checklists
 Code reviews checklists
 Test plan reviews checklists

20
 Requirements Reviews
The checklist for a requirements review.
 Completeness (have all functional and quality requirements described in the
problem statement been included?);
 Correctness (do the requirements reflect the user’s needs? are they stated
without error?);
 Consistency (do any requirements contradict each other?);
 Clarity (it is very important to identify and clarify any ambiguous
requirements);
 Relevance (is the requirement pertinent to the problem area? Requirements
should not be superfluous);
 Redundancy (a requirement may be repeated; if it is a duplicate it should be
combined with an Equivalent one);
 Testability (can each requirement be covered successfully with one or more
test cases? can tests determine if the requirement has been satisfied?);
feasibility (are requirements implementable given the conditions under which
the project will progress?). 21
 Design Reviews
A phased approach is key:
 High-Level Review: Focus on architecture and alignment
with requirements.
 Detailed Review: Ensure clarity, completeness, and
correctness.
Checklist:
 Design Methodology: Clear explanation of the technique.
 Notation: Understanding of the symbols
 Alternative Evaluation: Justification for the chosen design.
 High-Level Architectural Model:
 Defined modules and their interactions.
 Identification of module types (new, revised, COTS, reused).
 Assessment of module coupling and cohesion.
22
 Continued...
 Description of module interfaces;
 Quality of the user interface;
 Quality of the user help facilities;
 Identification of execution criteria and operational
sequences;
 Clear description of interfaces between this system and
other software and hardware systems;
 Coverage of all functional requirements by design elements;
coverage of all quality requirements, for example, ease of
use, portability, maintainability, security, readability,
adaptability, performance requirements (storage, response
time) by design elements;
 Reusability of design components
23
 Code Reviews
 Code reviews are valuable tools for both defect detection and code
quality assessment.
 Some organizations mandate a clean compile as a prerequisite for
code review.
 The rationale is that automated tools are more efficient at
identifying syntax errors than human reviewers.
Test Plan Reviews
 Test plans are another important artifact that benefits from
review.
 Some organizations opt to review test plans alongside related
documents.
 For example, a master test plan and an acceptance test plan might
be reviewed with the requirements document, while integration,
system, and unit test plans could be reviewed with the
corresponding design documents. 24
 Reporting review results
Essential Components:
 Detailed Checklist: Itemized examination with comments and
observations.
 Status/Summary Report: Concise overview, signed by all
participants.
 Defect Log: Comprehensive list of defects with precise locations.
 Review Metrics: Quantitative data (defect count, duration, effort).
 Reviewer Responsibility: Ensure accuracy and completeness of the
report.
Status Options:
 Accept: Satisfactory or minor modifications.
 Conditional Accept: Requires specific rework and moderator
confirmation.
 Re-inspect: Needs substantial rework and subsequent inspection.
25
 Continued...
IEEE Standards Recommendations:
 Number of Participants
 Meeting Duration
 Item Size
 Total Preparation Time
 Item Status
 Rework Effort Estimate
 Estimated Rework Completion Date

26
Thank you!
Questions?

27