Chapter-6 Static Testing

Download as pdf or txt
Download as pdf or txt
You are on page 1of 19

Chapter 6: Static Testing

1 Tadele M.
Software Testing

2
Software Testing

Static Testing Dynamic Testing

• Code is not executed • “Dynamic” means changing. changing values or


• It starts earlier in the development life cycle, conditions by executing the code
i.e. verification testing. • It is performed at the validation stage
• Preparation of checklist • Performed at a later stage of SDLC
• It can be done manually or by using a set of tools • Execution of test cases
• find out the errors, code flows, potentially malicious • Performed in the runtime environment
code in the application • find out the functional behavior of the software,
• Static testing is followed by the dynamic testing CPU response time, memory, performance
3
Static Testing

 Static testing techniques involve examination of the project’s documentation, software


and other information about the software products without executing them with the
intention of finding errors/faults.
 Also called dry-run testing
 Static- not while running or not while executing
 For example:
 You review software requirements as part of Static Testing.You may identify potential conflicts
that could be difficult to address later in the development cycle.
 Similarly, if you review code during Static Testing, you may spot issues like
 coding errors,
 inconsistent naming conventions that could negatively impact the software’s performance or quality.

4
When to Perform Static Testing?

 Static testing is performed at the early stage of SDLC, before the testing
phase.
 Static testing is recommended to be done during the design,
documentation, and development phases before dynamic testing
commences.

5
Participants in static testing

 Manager
 Allocate time in the project schedule and determine
whether review process objectives have been met.
 Moderator
 leads the review of the document(s), including
– planning the review,
– running the meeting,
– following-up after the meeting
 Author
 Writer or person with chief responsibility for the
document(s) to be reviewed.

6
Participants in static testing

 Reviewers (or checkers, or inspectors)


 Individuals with a specific technical or business
background who, after the necessary
 preparation, identify and describe findings (e.g.,
defects) in the product under review
 Scribe (or recorder)
 documents all the items identified during the meeting
like issues, problems, and open points

7
Features: What is Subject to Static Testing?

 Requirements & Specifications Review


 Structural Design Analysis: the system’s static structure and
flow diagrams
 Manually inspecting and analyzing the source code
 Database Analysis: database objects consistency and
alignment with the database design
 Documentation Review
 User Manual Review:

8
Static Testing
 Types of the defects that are easier to find during the static testing are:
 Deviations from standards.
 Missing requirements.
 Design defects.
 Non-maintainable code.
 Inconsistent interface specifications.
 Programming errors (e.g. Infinite Loops)

9
Static Testing Techniques
 Static techniques can be grouped under two categories:
1. Reviews : evaluation of technical matter by a group of people working together.
2. Static Analysis: the code is analyzed to find any structural defects that could lead to
errors when the program runs.
 Reviews can be of following types:
 Informal Reviews
 Walkthroughs
 Technical Review
 Inspections

10
Informal Reviews

 A review done by peers in an informal fashion without any documented findings or


process.
 An informal review involves two or more people looking through a document or codes
that one or the other of them has written.
 The purpose is still to detect defects, but there are usually no check-lists used and the
result does not need to be documented.
 asking a colleague or a friend to look at something we have produced
 The review conference is scheduled at their convenience.
 The participants are normally just the author and one or
two reviewers chosen by the author.

11
Walkthroughs

 It is not a formal process


 It is led by the author.
 Author guide the participants through the document according to his or her thought
process to achieve a common understanding and to gather feedback.
 Participants can ask questions if any.
 Scribe makes note of review comments

12
Technical Review

 It is less formal review


 It is led by the trained moderator but can also be led by a technical expert
 It is often performed as a peer review without management participation
 Defects are found by the experts (such as architects, designers, key users) who focus on the
content of the document.
 This review concentrates mainly on the technical document related to the software such
as test strategy, test plan and requirement specification documents

13
Inspection
 It is the most formal review type
 It is led by the trained moderators
 Reviewers have checklist to review the work products.
 They record the defect and inform the participants to rectify those errors.

14
Stages in a review process (formal)
 Formal reviews follow a formal process. A typical formal review process consists
of six main steps:
1. Planning
 Selecting the personnel, allocating roles; defining the entry and exit criteria for more
formal review types (e.g. inspection); and selecting which parts of documents to look a
2. Kick-off
 Distributing documents; explaining the objectives, process and documents to the
participants; and checking entry criteria
3. Preparation
 Work done by each of the participants on their own before the review meeting, noting
potential defects, questions and comments.

15
Stages in a review process (formal)…

4. Review meeting
 Discussion or logging, with documented results or minutes (for more formal review
types). The meeting participants may simply note defects, make recommendations
for handling the defects, or make decisions about the defects.
5. Rework
 Fixing defects found, typically done by the author
6. Follow-up
 Checking that defects have been addressed, gathering metrics and checking on exit
criteria

16
Static Code Analysis
 It is the systematic process of analyzing the source code of the software without
actually executing it.
 In this process, the source code for the software is analyzed for different
parameters, such as below:
 Whether or not the code meets the industry coding standards?
 Are there any loopholes in the dry run of the code?
 Is the syntax correct?
 Is the source code optimized or needs more optimizations?
 Is there any dead code or unreachable code?
 Are there any unassigned variables?
 Infinite loops present in the code.

17
Static Code Analysis
 Static code analysis can be performed either manually or automatically by using tools.
 Some of the tools which can be used for static analysis of code are:
 SourceMeter
 Find Bugs
 PMD
 PyCharm
 JTest
 Checkstyle
 Clang
 Sonarqube
 Soot
 Thread Safe
 JArchitect

18
Review questions
1. What is the difference between static testing and dynamic testing?
2. Which documents can be reviewed in static testing?
3. List the roles participated during static testing and their responsibilities
4. What are the different types of review in static testing? Identify their levels of
formality.
5. What are the stages of a formal review process?
6. What is Static Code Analysis? Mention some tools used to which can be used for
static analysis of code.

19

You might also like