Unit 3

Software Design and

Testing
Software Design
• Sequence of steps that enable the designer to
describe all aspects of the software to be built.
• Design is the place where quality is fostered in
software engineering. design
• More creative than analysis Satisfy

Customer Developers
(Implementers)
The design needs to be
Correct & complete
Understandable
At the right level
Maintainable
 Initial requirements

Gather data on user requirements

Analyze requirements data

Validate the design Obtain answers to
against the requirement
requirements questions
Conceive of a high level design

Refine & document the design

Completed design

Fig. 1 : Design framework

A two part design process
D
e
si How
What
g
Conceptual design n Technical design
er
s

Customer A two part design System

process Builders
 Conceptual design answers Technical design answers

Where will the data come from? Hardware Configuration

What will happen to data in the system Software Needs

How will the system look to Users? Communication Interfaces

What choices will be offered to users? I/O of the Systems

What is the timings of events? Software Architecture

How will the reports and screens look Network Architecture and any other
like? thing that translates the requirements
in to a solution to the customer’s
problem
Modularity in Software Design
• Modularity is the single attribute of software that
allows a program to be intellectually manageable.
• It enhances design clarity, which in turn eases
implementation, debugging, testing, documenting,
and maintenance of software product.
• Examples of Modules: Fortran subroutine; Ada
package; Procedures & functions of PASCAL & C;
C++ / Java classes ; Java packages
Advantage of Modular Design
i. Well defined subsystem
ii. Well defined purpose
iii. Can be separately compiled and stored in a library.
iv. Module can use other modules
v. Module should be easier to use than to build
vi. Simpler from outside than from the inside.
Two important terms
• Module Coupling: Coupling is the measure of the
degree of interdependence between modules.

• Module Cohesion : Cohesion is a measure of the

degree to which the elements of a module are
functionally related.
Uncoupled : Loosely coupled: Highly coupled:
no some dependencies many dependencies
dependencies
(a) (B) (C)
 Module Coupling
This can be achieved as:
❑ Controlling the number of parameters passed amongst modules.
❑ Avoid passing undesired data to calling module.
❑ Maintain parent / child relationship between calling & called modules.
❑ Pass data, not the
Edit student recordcontrol information. Edit student record

Student name, Student

Student ID Student
student ID, address, record EOF record EOF
course
Retrieve student Retrieve student
record record

Poor design: Tight Coupling Good design: Loose Coupling

 Types of Module Coupling
Data coupling Best
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst

The types of module coupling

Given two procedures A & B, we can identify number of
ways in which they can be coupled.

12
• Data Coupling: The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they communicate by only
passing of data. Other than communicating through data, the two modules are
independent.
• Stamp Coupling: Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.
• Control Coupling: Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually accomplished by
means of flags that are set by one module and reacted upon by the dependent
module.
• Common Coupling: With common coupling, module A and module B have
shared data. Global data areas are commonly found in programming languages.
Making a change to the common data means tracing back to all the modules
which access that data to evaluate the effect of changes.
Module Cohesion
• Cohesion is a measure of the degree to which the
elements of a module are functionally related.

Module strength

Cohesion=Strength of relations within

modules
Types of Cohesion
Functional Cohesion
Sequential Cohesion
Procedural Cohesion
Temporal Cohesion
Logical Cohesion
Coincident Cohesion
Types of module cohesion
• Functional Cohesion : A and B are part of a single functional task. This is very
good reason for them to be contained in the same procedure.
• Sequential Cohesion Module A outputs some data which forms the input to B.
This is the reason for them to be contained in the same procedure.
• Procedural Cohesion : Procedural Cohesion occurs in modules whose
instructions although accomplish different tasks yet have been combined
because there is a specific order in which the tasks are to be completed.
• Temporal Cohesion: Module exhibits temporal cohesion when it contains tasks
that are related by the fact that all tasks must be executed in the same
time-span.
• Logical Cohesion : Logical cohesion occurs in modules that contain instructions
that appear to be related because they fall into the same logical class of
functions.
• Coincidental Cohesion: Coincidental cohesion exists in modules that contain
instructions that have little or no relationship to one another.
Relationship between Cohesion & Coupling
If the software is not properly modularized, a host of seemingly
trivial enhancement or changes will result into death of the project.
Therefore, a software engineer must design the modules with goal of
high cohesion and low coupling.

View of cohesion and coupling

18
Types of modular Designs
• Bottom-Up Design:These modules are collected
together in the form of a “library”.
• Top-Down Design
A top down design approach starts by identifying the major
modules of the system, decomposing them into their lower level
modules and iterating until the desired level of detail is achieved.
This is stepwise refinement; starting from an abstract design, in
each step the design is refined to a more concrete level, until we
reach a level where no more refinement is needed and the design
can be implemented directly.
Hybrid Design:
•For top-down approach to be effective, some
bottom-up approach is essential for the
following reasons:
•To permit common sub modules.
•Near the bottom of the hierarchy, where the
intuition is simpler, and the need for
bottom-up testing is greater, because there
are more number of modules at low levels
than high levels.
FUNCTION ORIENTED DESIGN
• The design is decomposed into a set of interacting units
where each unit has a clearly defined function. Thus, system
is designed from a functional viewpoint.
Design Notations
Design notations are largely meant to be used during the
process of design and are used to represent design or design
decisions. For a function oriented design, the design can be
represented graphically or mathematically by the following:
• Data flow diagrams
• Data Dictionaries
• Structure Charts
• Pseudocode
Using pseudocode, the designer describes system
characteristics using short, concise, English language phrases
that are structured by key words such as It-Then-Else, 23
 Structure Chart
It partition a system into block boxes. A black box means
that functionality is known to the user without the
knowledge of internal design.

Hierarchical format of a structure chart 24

A structure chart for “update file”

Fig.: Update file 25

 Some Definitions
i. Design entity. An element (Component) of a design that
is structurally and functionally distinct from other
elements and that is separately named and referenced.
ii. Design View. A subset of design entity attribute
information that is specifically suited to the needs of a
software project activity.
iii. Entity attributes. A named property or characteristics of
a design entity. It provides a statement of fact about the
entity.
iv. Software design description (SDD). A representation
of a software system created to facilitate analysis,
planning, implementation and decision making.
26
• The SDD shows how the software system will be structured to satisfy the
requirements identified in the SRS. It is basically the translation of
requirements into a description of the software structure, software
components, interfaces, and data necessary for the implementation
phase. Hence, SDD becomes the blue print for the implementation
activity.
• Design Description Information Content
• Introduction
• Design entities
• Design entity attributes
 Design Views
Design View Scope Entity attribute Example representation

Decomposition Partition of the system into design Identification, type purpose, Hierarchical decomposition
description entities function, subordinate diagram, natural language

Dependency Description of relationships among Identification, type, purpose, Structure chart, data flow
description entities of system resources dependencies, resources diagrams, transaction diagrams

Interface List of everything a designer, Identification, function, Interface files, parameter tables
description developer, tester needs to know to interfaces
use design entities that make up the
system

Detail description Description of the internal design Identification, processing, data Flow charts, PDL etc.
details of an entity

28
 Object Oriented Design
Object Oriented Design begins with an examination of the
real world “things” that are part of the problem to be
solved. These things (which we will call objects) are
characterized individually in terms of their attributes and
Object Oriented Design is not dependent on any
behavior.
specific implementation language. Problems are
modeled using objects. Objects have:
• Behavior (they do things)
• State (which changes when they do things)
29
Concepts of Object Oriented Design
• Objects
• Classes
• Messages
• Abstraction
• Encapsulation
• Polymorphism
• Hierarchy
• Attributes
Steps for analysis & design of object oriented system
Activity Diagram State –Chart Diagram

Sequence Diagram
33
 Software Testing
• What is Testing?
Many people understand many definitions of testing :

1. Testing is the process of demonstrating that errors are not present.

2. The purpose of testing is to show that a program performs its intended
functions correctly.
3. Testing is the process of establishing confidence that a program does
what it is supposed to do.
These definitions are incorrect.
34
 Software Testing
A more appropriate definition is:

“Testing is the process of executing a program with the

intent of finding errors.”

Although software testing is itself an expensive activity, yet

launching of software without testing may lead to cost
potentially much higher than that of testing, specially in
systems where human safety is involved.
35
 Software Testing
• Who should Do the Testing ?
o Testing requires the developers to find errors from their software.
o It is difficult for software developer to point out errors from own
creations.
o Many organizations have made a distinction between development
and testing phase by making different people responsible for each
• We should test the program’s responses to every possible input. It means, we
should .test for all valid and invalid inputs. Suppose a program requires two 8 bit
phase
integers as inputs. Total possible combinations are 28x28. If only one second it
required to execute one set of inputs, it may take 18 hours to test all combinations.
Practically, inputs are more than two and size is also more than 8 bits. We have also
36
not considered invalid inputs where so many combinations are possible. Hence,
 Software Testing
Some Terminologies
Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a
syntax error or misunderstanding of specifications. Sometimes,
there are
When logical errors.
developers make mistakes while coding, we call these
mistakes “bugs”.
A fault is the representation of an error, where representation is the
mode of expression, such as narrative text, data flow diagrams, ER
diagrams, source code etc. Defect is a good synonym for fault.
A failure occurs when a fault executes. A particular fault may cause
different failures, depending on how it has been exercised.
37
 Software Testing
Test, Test Case and Test Suite
Test and Test case terms are used interchangeably. In practice, both are same and
are treated as synonyms. Test case describes an input description and an expected
output description.
Test Case ID
Section-I Section-II
(Before Execution) (After Execution)
Purpose : Execution History:
Pre condition: (If any) Result:
Inputs: If fails, any possible reason (Optional);

Expected Outputs: Any other observation:

Post conditions: Any suggestion:
Written by: Run by:
Date: Date:

Fig. : Test case template

The set of test cases is called a test suite. Hence any combination of
test cases may generate a test suite. 38
 Software Testing
Verification and Validation
Verification is the process of evaluating a system or component to determine
whether the products of a given development phase satisfy the conditions
imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at the
end of development process to determine whether it satisfies the specified
requirements .
Testing= Verification+Validation

39
 Software Testing
Alpha, Beta and Acceptance Testing
The term Acceptance Testing is used when the software is developed for a specific
customer. A series of tests are conducted to enable the customer to validate all
requirements. These tests are conducted by the end user / customer and may
range from adhoc tests to well planned systematic series of tests.
The terms alpha and beta testing are used when the software is developed as a
product for anonymous customers.
Alpha Tests are conducted at the developer’s site by some potential customers.
These tests are conducted in a controlled environment. Alpha testing may be
started when formal testing process is near completion.
Beta Tests are conducted by the customers / end users at their sites. Unlike alpha
testing, developer is not present here. Beta testing is conducted in a real
environment that cannot be controlled by the developer. 40
 Software Testing
Functional Testing
Input Output
domain domain

Input test System Output test

data under test data

Fig. : Black box testing

41
 Software Testing
Boundary Value Analysis
Consider a program with two input variables x and y. These input variables have
specified boundaries as: a≤x≤b
c≤y≤d

Input domain

d
y
c
a b
x
Fig.: Input domain for program having two input variables 42
 Software Testing
The boundary value analysis test cases for our program with two inputs variables
(x and y) that may have any value from 100 to 300 are: (200,100), (200,101),
(200,200), (200,299), (200,300), (100,200), (101,200), (299,200) and (300,200). This input
domain is shown in Fig. 8.5. Each dot represent a test case and inner rectangle is the
domain of legitimate inputs. Thus, for a program of n variables, boundary value analysis
yield 4n + 1 test cases. Input domain
400
300
y 200
100

0 100 200 300 400

x
Fig. : Input domain of two variables x and y with
boundaries [100,300] each 43
 Software Testing
The boundary value test cases for a Quadratic Equation are :
Test Case a b c Expected output

1 0 50 50 Not Quadratic
2 1 50 50 Real Roots
3 50 50 50 Imaginary Roots
4 99 50 50 Imaginary Roots
5 100 50 50 Imaginary Roots
6 50 0 50 Imaginary Roots
7 50 1 50 Imaginary Roots
8 50 99 50 Imaginary Roots
9 50 100 50 Equal Roots
10 50 50 0 Real Roots
11 50 50 1 Real Roots
12 50 50 99 Imaginary Roots
13 50 50 100 Imaginary Roots

44
 Software Testing
Robustness testing
It is nothing but the extension of boundary value analysis. Here, we would like to
see, what happens when the extreme values are exceeded with a value slightly
greater than the maximum, and a value slightly less than minimum. It means, we
want to go outside the legitimate boundary of input domain. This extended form
of boundary value analysis is called robustness testing and shown in Fig. 6
There are four additional test cases which are outside the legitimate input
domain. Hence total test cases in robustness testing are 6n+1, where n is the
number of input variables. So, 13 test cases are:

(200,99), (200,100), (200,101), (200,200), (200,299), (200,300)

(200,301), (99,200), (100,200), (101,200), (299,200), (300,200), (301,200) 45
 Software Testing
400
300
y 200
100

0 100 200 300 400

x

Fig. : Robustness test cases for two variables x and y with

range [100,300] each
46
 Software Testing
Worst-case testing
If we reject “single fault” assumption theory of reliability and may like to see what
happens when more than one variable has an extreme value. In electronic circuits
analysis, this is called “worst case analysis”. It is more thorough in the sense that
boundary value test cases are a proper subset of worst case test cases. It requires
more effort. Worst case testing for a function of n variables generate 5n test cases
as opposed to 4n+1 test cases for boundary value analysis.

47
 Software Testing
Equivalence Class Testing
In this method, input domain of a program is partitioned into a finite number of
equivalence classes such that one can reasonably assume, but not be absolutely sure,
that the test of a representative value of each class is equivalent to a test of any other
value.

1.TwoThe
steps are requiredclasses
equivalence to implementing this method:
are identified by taking each input condition and
partitioning it into valid and invalid classes. For example, if an input condition
specifies a range of values from 1 to 999, we identify one valid equivalence
class [1<item<999]; and two invalid equivalence classes [item<1] and
2. [item>999].
Generate the test cases using the equivalence classes identified in the
previous step. This is performed by writing test cases covering all the valid
equivalence classes. Then a test case is written for each invalid equivalence
class so that no test contains more than one invalid class. This is to ensure
48
that no two invalid classes mask each other.
Invalid input

Valid System under

test Outputs
inputs

Input domain Output domain

 Software Testing
Cause Effect Graphing Technique
▪ Consider single input conditions
▪ do not explore combinations of input circumstances
Steps
1. Causes & effects in the specifications are identified.
A cause is a distinct input condition or an equivalence class of input conditions.
An effect is an output condition or a system transformation.
2. The semantic content of the specification is analysed and transformed into a
boolean graph linking the causes & effects.
3. Constraints are imposed
4. graph – limited entry decision table
Each column in the table represent a test case.
5. The columns in the decision table are converted into test cases.
50
 Software Testing
Myers explained this effectively with following example. “The characters in column 1 must
be an A or B. The character in column 2 must be a digit. In this situation, the file update is
made. If the character in column 1 is incorrect, message x is issued. If the character in
column 2 is not a digit, message y is issued”.
The causes are
c1: character in column 1 is A
c2: character in column 1 is B
c3: character in column 2 is a digit
and the effects are
e1: update made
e2: message x is issued
e3: message y is issued

51
 Software Testing
Structural Testing
A complementary approach to functional testing is called structural / white box testing. It
permits us to examine the internal structure of the program.
Path Testing
Path testing is the name given to a group of test techniques based on judiciously selecting a
set of test paths through the program. If the set of paths is properly chosen, then it means
that we have achieved some measure of test thoroughness.
This type of testing involves:
1. generating a set of paths that will cover every branch in the program.
2. finding a set of test cases that will execute every path in the set of program
paths.

52
 Software Testing
Flow Graph
The control flow of a program can be analysed using a graphical representation known as
flow graph. The flow graph is a directed graph in which nodes are either entire statements
or fragments of a statement, and edges represents flow of control.

Fig. : The basic construct of the flow graph

53
Software Testing

Independent paths are:

(i) ABFGNPQR
(ii) ABFGNOQR
(iii) ABCEGNPQR
(iv) ABCDEGNOQR
(v) ABFGHIMQR
(vi) ABFGHJKMQR
(vii) Graph
Fig.: DD Path ABFGHJMQR

(Decision-to decision path)

54
 Software Testing
Cyclomatic Complexity
McCabe’s cyclomatic metric V(G) = e – n + 2P.
For example, a flow graph shown in figure with entry node ‘a’ and exit node ‘f’.

55
Calculate Cyclomatic complexity of the following Graph:

Graph containing 3 Connected Components

 Software Testing
Let us denote the total graph above with 3 connected components as

= 13-13+2*3
=6
This method with P 1 can be used to calculate the complexity of a collection of
programs, particularly a hierarchical nest of subroutines.

57
 Software Testing
Two alternate methods are available for the complexity calculations.
1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of
predicate (decision) nodes plus one.
V(G)= +1
Where is the number of predicate nodes contained in the flow graph
G.
2. Cyclomatic complexity is equal to the number of regions of the flow
graph.

58
 Software Testing
Solution
Cyclomatic complexity can be calculated by any of the three methods.
1. V(G) = e – n + 2P
= 13 – 10 + 2 = 5
2. V(G) =π+1
=4+1=5
3. V(G) = number of regions
=5
Therefore, complexity value of a flow graph in Fig. is 5.
59
 Software Testing
Graph Matrices
A graph matrix is a square matrix with one row and one column for every node in the graph.
The size of the matrix (i.e., the number of rows and columns) is equal to the number of
nodes in the flow graph. Some examples of graphs and associated matrices are shown in fig.

Fig (a): Flow graph and graph matrices 60

 Software Testing
Data Flow Testing
Data flow testing is another from of structural testing. It has nothing to do with data flow
diagrams.
i. Statements where variables receive values.
ii. Statements where these values are used or referenced.
As we know, variables are defined and referenced throughout the program. We
may have few define/ reference anomalies:
i. A variable is defined but not used/ referenced.
ii. A variable is used but never defined.
iii. A variable is defined twice before it is used.
61
 Software Testing
Levels of Testing
There are 3 levels of testing:
i. Unit Testing
ii. Integration Testing
iii. System Testing

62
 Software Testing
Unit Testing
There are number of reasons in support of unit testing than testing the entire
product.
1. The size of a single module is small enough that we can locate an error
fairly easily.
2. The module is small enough that we can attempt to test it in some
demonstrably exhaustive fashion.
3. Confusing interactions of multiple errors in widely different parts of the
software are eliminated.

63
 Software Testing
There are problems associated with testing a module in isolation. How do we run a
module without anything to call it, to be called by it or, possibly, to output
intermediate values obtained during execution? One approach is to construct an
appropriate driver routine to call if and, simple stubs to be called by it, and to insert
output statements in it.
✔ Stubs serve to replace modules that are subordinate to (called by) the module to
be tested. A stub or dummy subprogram uses the subordinate module’s interface,
may do minimal data manipulation, prints verification of entry, and returns.
This overhead code, called scaffolding represents effort that is import to testing, but
does not appear in the delivered product.

64
 Software Testing

Fig. 29 : Scaffolding required testing a program unit (module) 65

 Software Testing
Integration Testing
The purpose of unit testing is to determine that each independent module is
correctly implemented. This gives little chance to determine that the interface
between modules is also correct, and for this reason integration testing must be
performed. One specific target of integration testing is the interface: whether
parameters match on both sides as to type, permissible ranges, meaning and
utilization.

66
 Software Testing

Fig. 30 : Three different integration approaches 67

 Software Testing
System Testing
Of the three levels of testing, the system level is closet to everyday experiences.
We test many things; a used car before we buy it, an on-line cable network
service before we subscribe, and so on. A common pattern in these familiar
forms is that we evaluate a product in terms of our expectations; not with respect
to a specification or a standard. Consequently, goal is not to find faults, but to
demonstrate performance. Because of this we tend to approach system testing
from a functional standpoint rather than from a structural one. Since it is so
intuitively familiar, system testing in practice tends to be less formal than it might
be, and is gives
Petschenik compounded by the reduced
some guidelines testing
for choosing testinterval that usually
cases during system remains
testing.
before a delivery deadline.
68
 Software Testing
During system testing, we should evaluate a number of attributes of the
software that are vital to the user and are listed in Fig. 31. These represent the
operational correctness of the product and may be part of the software
specifications.
Usable Is the product convenient, clear, and predictable?

Secure Is access to sensitive data restricted to those with authorization?

Compatible Will the product work correctly in conjunction with existing data,
software, and procedures?
Dependable Do adequate safeguards against failure and methods for recovery exist in
the product?
Documented Are manuals complete, correct, and understandable?

Fig : Attributes of software to be tested during system testing 69

 Software Testing
Validation Testing
o It refers to test the software as a complete product.
o This should be done after unit & integration testing.
o Alpha, beta & acceptance testing are nothing but the various ways of involving
customer during testing.

70
 Software Maintenance
Regression Testing
Regression testing is the process of retesting the modified parts of the software
and ensuring that no new errors have been introduced into previously test code.
“Regression testing tests both the modified code and other parts of the program
that may be affected by the program change. It serves many purposes :

increase confidence in the correctness of the modified program

locate errors in the modified program
preserve the quality and reliability of software
ensure the software’s continued operation
71
 Software Maintenance
▪ Development Testing Versus Regression Testing
Sr.N Development testing Regression testing
o.

1.
We create test suites and test plans We can make use of existing test suite and
test plans
2.
We test all software components We retest affected components that have
been modified by modifications.
3.
Budget gives time for testing Budget often does not give time for
regression testing.
4.
We perform testing just once on a We perform regression testing many times
software product over the life of the software product.
5.
Performed under the pressure of Performed in crisis situations, under greater
release date of the software time constraints.
72
 Software Maintenance
▪ Regression Test Selection
Regression testing is very expensive activity and consumes significant amount of
effort / cost. Many techniques are available to reduce this effort/ cost.

1. Reuse the whole test suite

2. Reuse the existing test suite, but to apply a regression test
selection technique to select an appropriate subset of the test suite
to be run.
Minimization methods can omit some test cases that might expose fault in the
modified software and so, they are not safe.
A safe regression test selection technique is one that, under certain assumptions,
selects every test case from the original test suite that can expose faults in the
73
modified program.
 Software Maintenance
▪ Selective Retest Techniques
Selective retest techniques may be more economical than the “retest-all” technique.

Selective retest techniques are broadly classified in three categories :

1. Coverage techniques : They are based on test coverage criteria.
They locate coverable program components that have been modified,
and select test cases that exercise these components.
2. Minimization techniques: They work like coverage techniques,
except that they select minimal sets of test cases.
3. Safe techniques: They do not focus on coverage criteria; instead they
select every test case that cause a modified program to produce
different output than its original version.
74
 Software Maintenance
Rothermal identified categories in which regression test selection techniques can
be compared and evaluated. These categories are:
Inclusiveness measures the extent to which a technique chooses test
cases that will cause the modified program to produce different output than
the original program, and thereby expose faults caused by modifications.
Precision measures the ability of a technique to avoid choosing test cases
that will not cause the modified program to produce different output than
the original program.
Efficiency measures the computational cost, and thus, practically, of a
technique.
Generality measures the ability of a technique to handle realistic and
diverse language constructs, arbitrarily complex modifications, and realistic
testing applications. 75
 Software Testing
The Art of Debugging
The goal of testing is to identify errors (bugs) in the program. The process of
testing generates symptoms, and a program’s failure is a clear symptom of the
presence of an error. After getting a symptom, we begin to investigate the cause
and place of that error. After identification of place, we examine that portion to
identify the cause of the problem. This process is called debugging.
Debugging Techniques
Pressman explained few characteristics of bugs that provide some clues.
1. “The symptom and the cause may be geographically remote. That is, the
symptom may appear in one part of a program, while the cause may actually be
located in other part. Highly coupled program structures may complicate this
2. situation.
The symptom may disappear (temporarily) when another error is corrected.
77
 Software Testing
3. The symptom may actually be caused by non errors (e.g. round off inaccuracies).

4. The symptom may be caused by a human error that is not easily traced.

5. The symptom may be a result of timing problems rather than processing

problems.
6. It may be difficult to accurately reproduce input conditions (e.g. a real time
application in which input ordering is indeterminate).
7. The symptom may be intermittent. This is particularly common in embedded
system that couple hardware with software inextricably.
8. The symptom may be due to causes that are distributed across a number of
tasks running on different processors”.
78
 Software Testing
Induction approach
Locate the pertinent data
Organize the data
Devise a hypothesis
Prove the hypothesis

79
 Software Testing

Fig. : The inductive debugging process 80

 Software Testing
Deduction approach
Enumerate the possible causes or hypotheses
Use the data to eliminate possible causes
Refine the remaining hypothesis
Prove the remaining hypothesis

81
 Software Testing

Fig. : The inductive debugging process

82
 Software Testing
Testing Tools
One way to improve the quality & quantity of testing is to make the process as
pleasant as possible for the tester. This means that tools should be as concise,
powerful & natural as possible.
The two broad categories of software testing tools are :

Static
Dynamic

83
 Software Testing
There are different types of tools available and some are listed below:

1. Static analyzers, which examine programs systematically and automatically.

2. Code inspectors, who inspect programs automatically to make sure they adhere
to minimum quality standards.
3. standards enforcers, which impose simple rules on the developer.
4. Coverage analysers, which measure the extent of coverage.

5. Output comparators, used to determine whether the output in a program is

appropriate or not.

84
 Software Testing
6. Test file/ data generators, used to set up test inputs.

7. Test harnesses, used to simplify test operations.

8. Test archiving systems, used to provide documentation about programs.

85