MC5503 SOFTWARE TESTING AND

QUALITY ASSURANCE
UNIT I TESTING TECHNIQUES & TEST CASE
DESIGN 9
Using White Box Approach to Test design - Test
Adequacy Criteria – Static Testing Vs. Structural Testing –
Code Functional Testing – Coverage and Control Flow
Graphs – Covering Code Logic – Paths – Their Role in
White box Based Test Design – Code Complexity Testing
– Evaluating Test Adequacy Criteria. Test Case Design
Strategies – Using Black Box Approach to Test Case
Design – Random Testing – Requirements based testing –
Boundary Value Analysis –Decision tables – Equivalence
Class Partitioning – State based testing – Cause-effect
graphing – Error guessing – Compatibility testing – User
documentation testing – Domain testing – Case study for
Control Flow Graph and State based Testing.
 What is Software Testing
 The process or method of finding error/s or bugs in
a software application or program.
 It is defined as an activity to check whether the
actual results match the expected results and
 To ensure that the software system is Defect free.
 It is a process, to find whether the
developed software met the specified requirements or
not.
Why Software testing is important?
 1. To point out the defects and errors that were
made during the development.
 2. To satisfy the customer needs.
 Software Quality Assurance

 What is Quality?
Quality is meeting the requirement, expectation, and needs of
the customer is free from the defects.
 What is Assurance?
Assurance is provided by organization management, it means
giving a positive declaration on a product.
 What is Control?
Control is to test or verify actual results by comparing it with
the defined standards.
 What is Quality Assurance?
It is defined as an activity to ensure that an organization is
providing the best possible product or service to customers.
 It is a set of activities for ensuring quality in software
engineering processes that ultimately results, or at least gives
confidence, in the quality of software products.
 Basic definitions
Errors
  An error is a mistake or misunderstanding on the
part of a software developer.
  In the category of developer we include
1. Software engineers,
2. Programmers,
3. Analysts, and
4. Testers.
For example,
 A developer may misunderstand a design notation, or
 A programmer might type a variable name
incorrectly.
 Basic definitions (Cont.,)
Faults (Defects)
A fault (defect) is introduced into the
software as the result of an error.
Faults or defects are sometimes called -
bugs.
Use of the term ―defect is also associated
with software artifacts such as requirements
and design documents.
Defects occurring in these artifacts are also
caused by errors and are usually detected in
the review process.
 Basic definitions (Cont.,)
Failures
A failure is the inability of a software system
or component to perform its required
functions within specified performance
requirements.
During execution of a software component
or system, a tester, developer, or user
observes that it does not produce the
expected results.
In some cases a particular type of
misbehavior indicates a certain type of fault
is failure.
 Test case
A test case contains the following
information:
1. A set of test inputs. These are data items
received from an external source by the code
under test. 
◦ The external source can be hardware, software, or
human.
2. Execution conditions. These are
conditions required for running the test,
3. Expected outputs. These are the specified
results to be produced by the code under test.
 The Smart Tester
Software components have defects.
Developers cannot prevent/eliminate all
defects during development.
Therefore, software must be tested before it
is delivered to users.
Testing is usually performed under budget
and time constraints.
The smart tester must plan for testing, select
the test cases, and monitor the process to
insure that the resources and time allocated
for the job are utilized effectively.
 Test Case Design Strategies
 In an effective test case is good possibility of
illuminating a defect.
 The ability to develop effective test cases is important
to an organization evolving toward a higher-quality
testing process.
 For example, if test cases are effective there is
 (i) a greater probability of detecting defects,
 (ii) a more efficient use of organizational resources,
 (iii) a higher probability for test reuse,
 (iv) closer adherence to testing and project schedules
and budgets, and,
 (v) the possibility for delivery of a higher-quality
software product
Test Case Design Strategies
There are two basic strategies that can be used to
design test cases.
These are called the black box (sometimes called
functional or specification) and white box
(sometimes called clear or glassbox) test
strategies.
The smart tester knows that to achieve the goal of
providing users with
1. low-defect,
[Link]-quality software,
both of these strategies should be used to design
test cases.
WHITE BOX APPROACH TO TEST CASE
DESIGN
 The tester’s goal is to determine if all the logical and data
elements in the software unit are functioning properly.
 The knowledge needed for the white box test design approach
to the tester is the later phases of the software life cycle.
 Specifically during the detailed design phase of development.
 White box testing is also known as
 Clear Box testing,
 Open Box testing,
 Structural testing,
 Transparent Box testing,
 Code-Based testing, and
 Glass Box testing
What do you verify in White Box
Testing?

Testing of each statement.

The functionality of conditional loops.
Broken or poorly structured paths in the
coding processes.
The flow of specific inputs through the
code.
Expected output.
How do you perform White Box
Testing?
We have divided it into two basic steps.
1. Understand the Source Code.
2. Create Test Case and Execute.
1. Understand the Source Code
 The first thing a tester will learn and understand
the source code of the application.
 The tester must be very knowledgeable in the
programming languages used in the applications
they are testing.
2. Create Test Case and Execute.
 The second basic step to white box testing involves testing the
application's source code for proper flow and structure.
White Box Testing Example
 Consider the following piece of code

Printme (int a, int b) { ------------ Printme is a function

int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
} ----------- End of the source code
 The goal of White Box testing is to verify all the decision branches, loops,
statements in the code.
 To exercise the statements in the above code, WhiteBox test cases would
be
 A = 1, B = 1
 A = -1, B = -3
White Box Testing Techniques
Statement Coverage:-
◦ This technique requires every possible statement in
the code to be tested at least once during the testing
process.
Branch Coverage - 
◦ This technique checks every possible path (if-else and
other conditional loops) of a software application.
Apart from above, there are numerous coverage
types such as
◦ Condition Coverage, Multiple Condition Coverage,
Path Coverage, Function Coverage etc.
White Box Testing Techniques
Statement Coverage
 Execute every statement in the code at
least once during test case execution.
Coverage
Statement Testing = (Number of Statements
Exercised / Total Number of Statements) x 100 %
Branch Testing = (Number of decisions
outcomes tested / Total Number of decision
Outcomes) x 100 %
Path Coverage = (Number paths exercised /
Total Number of paths in the program) x 100 %
Advantages of white-box testing
Efficient in finding errors and problems.
Required knowledge of internals of the
software under test is beneficial for
thorough testing.
Extra lines of code can be removed which
can bring in hidden defects.
Due to required internal knowledge of the
software, maximum coverage is obtained.
 Disadvantages of white-box testing

Skilled testers are required

Cost of the resources is high
Might not find missing features
 Test adequacy criteria
The goal for white box testing is
◦ To ensure that the internal components of a
program are working properly.
◦ A common focus is statements and branches.
The tester develops test cases to determine if
defects exist in the program structure.
Testers need a framework for deciding
which structural elements to select as the focus of
testing, and then choosing the appropriate test
data, and
For deciding when the testing efforts are
adequate enough to terminate.
Test adequacy criteria (Cont.,)
The application scope of adequacy
criteria also includes:
◦ (i) helping testers to select properties of a
program to focus on during test;
◦ (ii) helping testers to select a test data set for a
program based on the selected properties;
◦ (iii) supporting testers with the development
of quantitative or measurable objectives for
testing;
◦ (iv) indicating to testers whether or not testing
can be stopped for that program
 Test adequacy criteria (Cont.,)
 Ifa tester sets a goal for a unit specifying that the tests should
be statement adequate,
 This goal is often expressed as a requirement for complete, or
100%, statement coverage.
 The test cases developed must insure that all the statements in
the unit are executed at least once.
 When a coverage-related testing goal is expressed as a
percent, it is often called the degree of coverage.
 The planned degree of coverage is usually specified as 100%
 If the tester wants to completely satisfy the commonly
applied test adequacy, or coverage criteria.
 Under some circumstances, the planned degree of coverage
may be less than 100%due to the following reason.
Test adequacy criteria (Cont.,)
The nature of the unit
◦ Some statements/branches may not be reachable.
The lack of resources
◦ The time set aside for testing is not adequate to
achieve 100% coverage.
◦ There are not enough trained testers to achieve
complete coverage for all of the units.
Other project-related issues such as timing,
scheduling, and marketing constraints.
STATIC VS STRUCTURAL
TESTING
 Static Testing
Under Static Testing, code is not executed.
Rather it manually checks the code, requirement
documents, and design documents to find errors.
Hence, the name "static".
The main objective of this testing is to improve
the quality of software products by finding
errors in the early stages of the development
cycle.
This testing is also called a Non-execution
technique or verification testing.
 Static Testing (Cont.,)
Static Testing is a software testing technique in
which the software is tested without executing
the code. It has two parts as listed below: 
Review - Typically used to find and eliminate
errors in documents such as requirements,
design, test cases, etc.
Static analysis - The code written by
developers are analysed (usually by tools) for
structural defects that may lead to defects.
 Types of Reviews:
The types of reviews can be given by a
simple diagram:

Testing
 
Techniques used for Static Testing:

[Link] Reviews:
• This is one of the types of review which doesn't follow any process to
find errors in the document.
• Under this technique, you just review the document and give informal
comments on it.
 Types of Reviews: (cont.,)
2. Technical Reviews:
A peer’s team review the technical specification of the software product and
checks whether it is suitable for the project.
To find any discrepancies in the specifications and standards followed.
This review concentrates mainly on the technical document related to the
software such as Test Plan and requirement specification documents.
3.  Walkthrough:
The author of the work product explains the product to his team.
Participants can ask questions if any. Meeting is led by the author.
Note the review comments
  Inspection:
 The main purpose is to find defects and meeting is led by trained moderator.
 This review is a formal type of review where it follows strict process to find the
defects.
 Reviewers have checklist to review the work products .
 They record the defect to rectify those errors.
 Static code Review:
[Link] is systematic review of the software source code without executing the
code.
[Link] checks the syntax of the code, coding standards, etc.
[Link] review can be done at any point during development.
 Static Analysis - By Tools:
Following are the types of defects found by the
tools during static analysis:
 
A variable with an undefined value 
Inconsistent interface between modules and
components 
Variables that are declared but never used 
Unreachable code (or) Dead Code 
Programming standards violations 
Security Issues and 
Syntax violations
 Examples of Work documents
Requirement specifications
Design document
Source Code
Test Plans
Test Cases
Help or User document
Web Page content  
 Dynamic Testing
 Dynamic testing involves validation.
 Unit Testing: Under Unit Testing, individual units or
modules are tested by the developers. It involves testing
of source code by developers.
 Integration Testing: Individual modules are grouped
together and tested by the developers.
 System Testing: System Testing is performed on the
whole system by checking whether the system or
application meets the requirement specification
document.
 Also, Non-functional testing like
performance, Installation Testing, Security Testing fall
under the category of dynamic testing.
 Static Vs Dynamic Testing
Static Testing Dynamic Testing

Testing was done without executing the Testing is done by executing the
program program

This testing does the verification Dynamic testing does the validation
process process

Static testing is about prevention of Dynamic testing is about finding and

defects fixing the defects

Static testing gives an assessment of Dynamic testing gives bugs in the

code and documentation software system.

Static testing involves a checklist and Dynamic testing involves test cases for
process to be followed execution

This testing can be performed before Dynamic testing is performed after

compilation compilation

Cost of finding defects and fixing is less Cost of finding and fixing defects is
high

More reviews comments are highly More defects are highly recommended
recommended for good quality for good quality.
 Coverage and Control Flow
Graph
The application of coverage analysis is
associated with the use of control and data flow
models.
The logic elements for coverage are based on
the flow of control in a unit of code.
For example,
1. program statements;
2. decisions/branches (these influence the program
flow of control);
3. conditions (expressions that evaluate to true/false)
4. combinations of decisions and conditions;
5. paths (node sequences in flow graphs).
 Coverage and Control Flow
Graph (Cont.,)
All structured programs can be built from
three basic types
1. sequential (e.g., assignment statements),
2. decision (e.g., if/then/else statements), and
3. iterative (e.g., while, for loops).
Graphical representations for these three
types are shown in the following Figure.
Coverage and Control Flow
Graph (Cont.,)
 Coverage and Control Flow
Graph (Cont.,)
 The flow graph can be used by the tester
◦ to evaluate the code with respect to its testability,
◦ to develop white box test cases.
 A flow graph representation for the code example in
Figure 1.2 is found in Figure 1.3.
 In the flow graph the nodes represent sequential
statements, as well as decision and looping predicates.
 Edges in the graph represent transfer of control.
 The direction of the transfer depends on the outcome
of the condition in the predicate (true or false).
Code Sample with Branch and Loop
(Figure 1.2)
Control Flow Graph Representation
(Figure 1.3)
Coverage and Control Flow
Graph (Cont.,)

A control flow representation for the

software under test facilitates the design
of white box–based test cases as it clearly
shows the logic elements needed to design
the test cases.
Paths: Their Role in White-Box Test
Design
The role of a control flow graph as an aid to
white box test design.
The cyclomatic complexity attribute is very
useful to a tester.
The complexity value is usually calculated from
the control flow graph (G) by the formula

The uses of Cyclomatic Complexity is to

provide an approximation of the number of test
cases needed for branch coverage in a module.
Paths: Their Role in White-Box Test
Design (Cont.,)
The value E is the number of edges in the
control flow graph and N is the number of
nodes.
This formula can be applied to flow graphs
where there are no disconnected components.
As an example, the cyclomatic complexity of
the flow graph in Figure 1.3 is calculated as
follows:
Paths: Their Role in White-Box Test
Design (Cont.,)
A path is a sequence of control flow nodes usually
beginning from the entry node of a graph through to the
exit node.
 A path may go through a given segment of the control
flow graph one or more times.
 We usually designate a path by the sequence of nodes it
encompasses.
 For example, one path from the graph in Figure 1.3 is

◦  1-2-3-4-8
 Where the dashes represent edges between two nodes.
 For example, the sequence “4-8” represents the edge
between nodes 4 and 8.
Paths: Their Role in White-Box Test
Design (Cont.,)
A set of independent paths for a graph is
sometimes called a basis set.
For most software modules it may be possible to
derive a number of basis sets.
If we examine the flow graph in Figure 1.3, we
can derive the following set of independent
paths starting with the first path identified above
◦ 1-2-3-4-8
◦  1-2-3-4-5-6-7-4-8
◦  1-2-3-4-5-7-4-8
 Example
T
3
1 1 2
F
4
CFG CFG

 Only one path is needed:  Two paths are needed:

◦ [1]
 [1–2–4]
 [1–2–3–4]

T
2
1 4  Two paths are needed:
 [1–2–4]
F 3  [1–3–4]
CFG
 Path Testing (Cont.,)
In the above diagram 2 paths or condition that
need to be tested to get the output,
Path 1: 1-2-4
Path 2: 1-3-4
The basic steps involved in basis path testing
include
◦ Draw a control graph (to determine different program
paths)
◦ Calculate Cyclomatic complexity (metrics to
determine the number of independent paths)
◦ Find a basis set of paths
◦ Generate test cases to exercise each path
Using the Block Box Approach to
Test Case Design
 In the black box test strategy, only inputs and outputs as
a basis for designing test cases.
 A suitable set of inputs choosing from the set of all
possible valid and invalid inputs.
 As an example, suppose you tried to test a single
procedure that calculates the square root of a number.
 Test would have to try all positive input values, all
negative numbers, and fractions.
 The goal for the smart tester is to effectively utilize the
resources and yields maximum of defects for the time
and effort spent.
 Techniques for Black box
approaches
The techniques opted for black box
approaches are as follows
◦ Random Testing
◦ Requirement based Testing
◦ Boundary Value Analysis
◦ Equivalence class partitioning
◦ State-based Testing
◦ Cause-effect Graphing
◦ Compatibility Testing
◦ User documentation Testing
◦ Domain Testing
 Random Testing
Each software module or system test input data
is selected from input domain.
If a tester randomly selects inputs from the
domain, this is called random testing.
For example, if the valid input domain for a
module is all positive integers between 1 and
100.
The tester randomly, select values from within
that domain; for example, the values 55, 24, 3
might be chosen.
 Random Testing (Cont.,)
Given this approach, some of the issues
that remain open are the following:
◦  Are the three values adequate to show that the
module meets its specification?
◦ Are there any input values, other than those
selected, more likely to reveal defects?
◦ Should any values outside the valid domain be
used as test inputs? For example, floating
point values, negative values, or integer values
greater than 100?
 Random Testing (Cont.,)
Use of random test inputs may save some
of the time and effort.
Selecting test inputs randomly has very
little chance of producing an effective set
of test data.
This type of testing can be very useful
especially at the system level.
 Equivalence Class Partitioning
Equivalent Class Partitioning is a black box
technique (code is not visible to tester)
It can be applied to all levels of testing like unit,
integration, system, etc.
In this technique, you divide the set of test
condition into a partition that can be considered
the same.
It divides the input data of software into
different equivalence data classes.
You can apply this technique, where there is a
range in the input field.
Equivalence Class Partitioning
Let's consider the behavior of Order Pizza
Text Box Below
Pizza values 1 to 10 is considered valid.
A success message is shown.
While value 11 to 99 are considered
invalid for order and an error message
will appear, "Only 10 Pizza can be
ordered“
Order Pizza:      Submit
Equivalence Class Partitioning
Here is the test condition
◦ Any Number greater than 10 entered in the
Order Pizza field(let say 11) is considered
invalid.
◦ Any Number less than 1 that is 0 or below,
then it is considered invalid.
◦ Numbers 1 to 10 are considered valid
◦ Any 3 Digit Number say -100 is invalid.
Equivalence Class Partitioning

We cannot test all the possible values because if

done, the number of test cases will be more than
100.
We divide the possible values into groups.
The divided sets are called Equivalence
Partitions or Equivalence Classes.
Equivalence Class Partitioning
 Boundary Testing
 Boundary testing is the process of testing between extreme ends
or boundaries between partitions of the input values.
 So these extreme ends like Start- End, Lower- Upper,
Maximum-Minimum, Just Inside-Just Outside values are called
boundary values and the testing is called "boundary testing".
 The basic idea in boundary value testing is to select input
variable values at their:
◦ Minimum
◦ Just above the minimum
◦ A nominal value
◦ Just below the maximum
◦ Maximum

Boundary Testing (Cont.,)
 Decision Table Testing

Decision table testing is a software testing

technique used to test system behavior for
different input combinations. 
This is a systematic approach where the
different input combinations and their
corresponding system behavior (Output)
are captured.
Decision Table Testing (cont.,)
 Decision Table Testing (cont.,)
The condition is simple if the user
provides correct username and password
the user will be redirected to the
homepage.
If any of the input is wrong, an error
message will be displayed.
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Username F T F T
(T/F)
Password F F T T
(T/F)
Output (E/H) E E E H
 Decision Table Testing (cont.,)

Conditions Case 1 Case 2 Case 3 Case 4 Case 5 Case 6 Case 7 Case 8

Format .jpg .jpg .jpg .jpg Not .jpg Not .jpg Not .jpg Not .jpg

Size Less Less than >= 32kb >= 32kb Less than Less than >= 32kb >= 32kb
than 32kb 32kb 32kb
32kb

resolution 137*177 Not 137*177 Not 137*177 Not 137*177 Not

137*177 137*177 137*177 137*177

Output Photo Error Error Error Error Error Error Error

uploaded message message message message message message message
resolution size size and for format format for format for
mismatch mismatch resolution mismatch and and size format,
mismatch resolution mismatch size, and
mismatch resolution
mismatch
 Decision Table Testing (cont.,)
1. Upload a photo with format '.jpg', size less than 32kb and
resolution 137*177 and click on upload. Expected result is Photo
should upload successfully
2. Upload a photo with format '.jpg', size less than 32kb and
resolution not 137*177 and click on upload. Expected result is
Error message resolution mismatch should be displayed
3. Upload a photo with format '.jpg', size more than 32kb and
resolution 137*177 and click on upload. Expected result is Error
message size mismatch should be displayed
4. Upload a photo with format '.jpg', size less than 32kb and
resolution not 137*177 and click on upload. Expected result is
Error message size and resolution mismatch should be displayed
5. Upload a photo with format other than '.jpg', size less than 32kb
and resolution 137*177 and click on upload. Expected result is
Error message for format mismatch should be displayed
 Decision Table Testing (cont.,)
 Upload a photo with format other than '.jpg', size less
than 32kb and resolution not 137*177 and click on
upload. Expected result is Error message format and
resolution mismatch should be displayed
 Upload a photo with format other than '.jpg', size more
than 32kb and resolution 137*177 and click on upload.
Expected result is Error message for format and size
mismatch should be displayed
 Upload a photo with format other than '.jpg', size more
than 32kb and resolution not 137*177 and click on
upload. Expected result is Error message for format, size
and resolution mismatch should be displayed
Decision Table Testing
Advantages of Decision Table Testing
◦ This table will help to make effective combinations and can ensure a better
coverage for testing.
◦ Any complex business conditions can be easily turned into decision tables.
◦ In a case we are going for 100% coverage typically when the input
combinations are low, this technique can ensure the coverage.
 Disadvantages of Decision Table Testing
◦ The main disadvantage is that when the number of input increases the
table will become more complex.
 Requirements based Testing

Requirements-based testing is a testing approach

in which test cases, conditions and data are
derived from requirements.
Testing must be carried out in a timely manner.
Testing process should add value to the software
life cycle, hence it needs to be effective.
Testing process needs to be efficient as well.
Testing must provide the overall status of the
project, hence it should be manageable.
 Requirements Testing process
 So the requirements based testing process
addresses each of the above issues as follows :
 The Requirements based testing process starts at
the very early phase of the software development,
as correcting issues/errors is easier at this phase.
 It begins at the requirements phase as the chances
of occurrence of bugs have its roots here.
 It aims at quality improvement of requirements.
Insufficient requirements leads to failed projects.

 Requirements Testing process
Various studies have shown that software
projects fail due to the following reasons:
1. Incomplete requirements and specifications.
2. Frequent changes in requirements and
specifications.
3. When there is lack of user input to
requirements.
 Stages in Requirements based
Testing
 Defining Test Completion Criteria - Testing is
completed only when all the functional and non-
functional testing is complete.
 Design Test Cases - A Test case has five parameters
namely the initial state or precondition, data setup, the
inputs, expected outcomes and actual outcomes.
 Execute Tests - Execute the test cases against the
system under test and document the results.
 Verify Test Results - Verify if the expected and actual
results match each other.
 Verify Test Coverage - Verify if the tests cover both
functional and non-functional aspects of the
requirement.
 State Based in Testing
 State based testing is defined as the software testing
technique in which changes in input conditions cause's
state changes in the Application.
 A program moves from state to state.
 In a given state, some inputs are valid, and others are
ignored or rejected.
 It is a black box testing technique in which the tester
analyzes the behavior of an application under test for
different input conditions in a sequence.
 In this technique, tester provides both positive and
negative input test values and record the system
behavior.  
Four Parts Of State Transition
Diagram or State Model
There are 4 main components of the State
Transition Model as below
1) States that the software might get

2) Transition from one state to another

Four Parts Of State Transition
Diagram
3) Events that origin a transition like
closing a file or withdrawing money

4) Actions that result from a transition

(an error message or being given the
cash.)
 Examples of a State Transition
Let's consider an ATM system function where if
the user enters the invalid password three times
the account will be locked.
In this system, if the user enters a valid
password in any of the first three attempts the
user will be logged in successfully.
If the user enters the invalid password in the
first or second try, the user will be asked to re-
enter the password.
And finally, if the user enters incorrect
password 3rd time, the account will be blocked.
State transition diagram
 State Transition Table
Correct PIN Incorrect PIN

S1) Start S5 S2

S2) 1st attempt S5 S3

S3) 2nd attempt S5 S4

S4) 3rd attempt S5 S6

S5) Access Granted - -

S6) Account blocked - -

 Examples of a State Transition
 In the flight reservation login screen,
 To enter correct agent name and password to access the
flight reservation application.
 It gives you the access to the application with correct
password and login name, but what if you entered the
wrong password.
 The application allows three attempts, and if users enter
the wrong password at 4th attempt, the system closes the
application automatically.
 The State Graphs helps you determine valid transitions to
be tested.
 In this case, testing with the correct password and with
an incorrect password is compulsory
State Transition Graph
State Table to determine invalid
system transitions
 User Documentation Testing
User Documentation  covers all the manuals,
user guides, installation guides, setup guides,
and online help that are provided along with the
software to help the end user to understand the
software system.
User Documentation Testing should have two
objectives:-
◦ To check if what is  stated in the document is
available in the software.
◦ To check if what is there in the product is explained
correctly in the document.
 User Documentation Testing
 Documentation testing includes checking of spellings and
grammar in the documents.
 Reviewing the documents manually to find errors, doubts
or inconsistencies in the documented artifacts.
 Some commonly used artifacts are as follows

◦ Requirement documents
◦ Test Plan
◦ Test Cases
◦ Bug reports
◦ Operator Manuals
◦ User Manuals
◦ Configuration of the software
 User Documentation Testing
Testing the documented objects that are
developed prior, during and after the testing of a
product is known as documentation testing.
It is a non-functional type of software testing.
We know that defects found in testing phase were
more costly than if they were found during the
requirement phase.
The cost of fixing a bug increase exponentially
the later you find it.
So documentation testing can start right from the
beginning of the software development process to
save a large amount of money.
 User Documentation Testing
 Documentation testing has a vital role in Software Testing.
 The users will refer this document when they start using the
software at their location.
 Poor documentation can affect the quality of the product.
 Good product documentation plays a important role in the
final product.
 Defects found in the user documentation need to be tracked to
closure like any regular software defect.
 Because these documents are the first interactions the users
with the product.
 A good User Documentation  aids in reducing customer
support calls.
 The effort and money spend on this effort would form a
valuable investment in the long run for the organisation.
 Error Guessing
 Designing test cases using the error guessing approach
is based on the tester’s/developer’s past experience with
code.
 That is similar to the code-under-test.
 The tester/developer is sometimes able to make an
educated “guess” as to which types of defects may be
present and design test cases.
 If defect data for similar code or past releases of the
code has been carefully recorded,.
 The defect types classified, and failure symptoms due to
the defects carefully noted.
 Such data would be available to testers in a TMM
(Testing Maturity Model level 4 organization.
 Cause-and-Effect Graphing
A “Cause” represents a different input conditions.
 An “Effect” represent an Output condition, or system
transformation.
 A major weakness with equivalence class partitioning is
◦ It does not allow testers to combine conditions.
 It can be used to combine conditions and derive an
effective set of test cases.
 The specification must be transformed into a graph that
resembles a digital logic circuit.
 The tester is not required to have a background in
electronics,.
 But he should have knowledge of Boolean logic.
 The graph must be converted to a decision table that the
tester uses to develop test cases.
 Cause-and-Effect Graphing
Samples of cause-and-effect graph
notations.

Effect 3 occurs if both causes 1 and 2 are

present
Cause-and-Effect Graphing

Effect 2 occurs if cause 1 occurs.

Effect 2 occurs if cause 1 does not occur.

 Cause-and-Effect Graphing
 The steps in developing test cases with a cause-and-effect graph are
as follows
1. The tester must decompose the specification of a complex software
component into lower-level units.
2. For each specification unit, the tester needs to identify causes and
their effects.
◦ Putting together a table of causes and effects helps the tester to record the
necessary details.
◦ The logical relationships between the causes and effects should be determined.
◦ It is useful to express these in the form of a set of rules.
 3. From the cause-and-effect information, a Boolean cause-and-
effect graph is created.
◦ Nodes in the graph are causes and effects.
◦ Causes are placed on the left side of the graph and effects on the right.
◦ Logical relationships are expressed using standard logical operators such as
AND, OR, and NOT, and are associated with arcs.
 Cause-and-Effect Graphing
4. The graph may be describe combinations of causes and/or effects.
5. The graph is then converted to a decision table.
6. The columns in the decision table are transformed into test cases.

 The following example illustrates the application of this

technique.
 Suppose we have a specification for a module that allows a user to
perform a search for a character in an existing string.
 The specification states that the user must input the length of the
string and the character to search for.
 If the string length is out-of-range an error message will appear.
 If the character appears in the string, its position will be reported.
 If the character is not in the string the message “not found” will be
output.
 Cause-and-Effect Graphing
 The input conditions, or causes are as follows:
◦ C1: Positive integer from 1 to 80
◦ C2: Character to search for is in string

 The output conditions, or effects are:

◦ E1: Integer out of range
◦ E2: Position of character in string
◦ E3: Character not found

 The rules or relationships can be described as follows:

◦ If C1 and C2, then E2.
◦ If C1 and not C2, then E3.
◦ If not C1, then E1.
 Cause-and-Effect Graphing

The tester can use the decision table to

consider combinations of inputs to
generate the actual tests.
In this example, three test cases are called
for.
If the existing string is “abcde,” then
possible tests are the following:
Cause-and-Effect Graphing

Inputs Length Character to search for Outputs

T1 5 c 3
T2 5 w Not found
T3 90 Integer out of range
Cause-and-Effect Graphing

Cause-and-effect graph for the

character search example.
 Cause-and-Effect Graphing
Advantage
1. The graph allows a thorough inspection of the
specification.
2. Any omissions, inaccuracies, or inconsistencies are
likely to be detected.
3. combinations of test data that may not be considered
using other black box testing techniques.
4. To decompose a complex specification into lower-
level.
5. In a simpler components easy to develop cause-and-
effect graphs and decision tables.
 Cause-and-Effect Graphing
A decision table will have a row for each cause and each
effect.
 Entries in the table can be represented by a “1” for a
cause or effect that is present,.
 A “0” represents the absence of a cause or effect.
 And a “—” indicates a “don’t care” value.
 A decision table for our simple example is shown in the
followingTable.
 Where C1, C2, C3 represent the causes,
 E1, E2, E3 the effects, and
 Columns T1, T2, T3 the test cases.
Cause-and-Effect Graphing

Decision table for character search

example.