The document provides a comprehensive overview of test case design and techniques in software testing, covering both black-box and white-box methods. It elaborates on various testing approaches like equivalence partitioning, boundary value analysis, and data flow testing, emphasizing their significance in identifying defects and ensuring software quality. The document also outlines the components of test cases and the importance of structured testing methods to enhance reliability and effectiveness.

1. Quality Assurance /
Software Testing Training
Test Case Design and Technique

2. Page 2Classification: Restricted
Agenda
• Test Case Design and Techniques
• Black-box: Three major approaches
• Steps for drawing cause-Effect Diagram:
• Behavior Testing
• Random Testing
• White Box Techniques
• Path Testing
• Statement Coverage
• Data Flow Testing

3. Page 3Classification: Restricted
Test Case Design and Techniques
Test case is defined as
• A set of test inputs, execution conditions and expected results,
developed for a particular objective.
• Documentation specifying inputs, predicted results and a set of
execution conditions for a test item.
• Specific inputs that will be tried and the procedures that will be
followed when the software tested.
• Sequence of one or more subtests executed as a sequence as the
outcome and/or final state of one subtests is the input and/or initial
state of the next.
• Specifies the pretest state of the AUT and its environment, the test
inputs or conditions.
• The expected result specifies what the AUT should produce from the
test inputs.

4. Page 4Classification: Restricted
Test Cases
• Test case name
• Test case id
• Objective
• Steps
• Expected result
• Actual result
• Pass/fail
• Comments

5. Page 5Classification: Restricted
Good Test Cases
Find Defects
• Have high probability of finding a new defect.
• Unambiguous tangible result that can be inspected.
• Repeatable and predictable
• Traceable to requirements or design documents
• Push systems to its limits
• Execution and tracking can be automated
• Do not mislead
• Feasible

6. Page 6Classification: Restricted
Test Case Design Technique
Black-box testing (or functional testing):
• Equivalence partitioning
• Boundary value analysis
• Cause-effect graphing
• Behavioural testing
• Random testing

7. Page 7Classification: Restricted
Black-box: Three major approaches
• Analysis of the input/output domain of the program:
Leads to a logical partitioning of the input/output domain into
‘interesting’ subsets
• Analysis of the observable black-box behavior:
Leads to a flow-graph-like model, which enables application of
techniques from the white-box world (on the black-box model)
• Techniques like risk analysis, random input, stress testing

8. Page 8Classification: Restricted
Black-box : Equivalence Partitioning
Equivalence Partitioning also called as equivalence class partitioning. It is
abbreviated as ECP. It is a software testing technique that divides the input
test data of the application under test into each partition at least once of
equivalent data from which test cases can be derived.
An advantage of this approach is it reduces the time required for performing
testing of a software due to less number of test cases.
Example:
The Below example best describes the equivalence class Partitioning:
Assume that the application accepts an integer in the range 100 to 999
Valid Equivalence Class partition: 100 to 999 inclusive. Non-valid
Equivalence Class partitions: less than 100, more than 999, decimal

9. Page 9Classification: Restricted
Boundary value analysis
Boundary value analysis is a type of black box or specification based testing
technique in which tests are performed using the boundary values.
Example:
An exam has a pass boundary at 50 percent, merit at 75 percent and
distinction at 85 percent. The Valid Boundary values for this scenario will be
as follows:
49, 50 - for pass
74, 75 - for merit
84, 85 - for distinction
Boundary values are validated against both the valid boundaries and invalid
boundaries.
The Invalid Boundary Cases for the above example can be given as follows:
0 - for lower limit boundary value
101 - for upper limit boundary value

10. Page 10Classification: Restricted
Cause Effect Graph
Cause Effect Graph is a black box testing technique that graphically illustrates
the relationship between a given outcome and all the factors that influence
the outcome.
It is also known as Ishikawa diagram as it was invented by Kaoru Ishikawa or
fish bone diagram because of the way it looks.
Circumstances - under which Cause-Effect Diagram used
• To Identify the possible root causes, the reasons for a specific effect,
problem, or outcome.
• To Relate the interactions of the system among the factors affecting a
particular process or effect.
• To Analyze the existing problems so that corrective action can be taken
at the earliest.

11. Page 11Classification: Restricted
Benefits:
• It Helps us to determine the root causes of a problem or quality using a
structured approach.
• It Uses an orderly, easy-to-read format to diagram cause-and-effect
relationships.
• It Indicates possible causes of variation in a process.
• It Identifies areas, where data should be collected for further study.
• It Encourages team participation and utilizes the team knowledge of the
process.
• It Increases knowledge of the process by helping everyone to learn
more about the factors at work and how they relate.

12. Page 12Classification: Restricted
Steps for drawing cause-Effect Diagram:
Step 1 : Identify and Define the Effect
Step 2 : Fill in the Effect Box and Draw the Spine
Step 3: Identify the main causes contributing to the effect being studied
Step 4 : For each major branch, identify other specific factors which
may be the causes of the EFFECT.
Step 5 : Categorize relative causes and provide detailed levels of causes.

13. Page 13Classification: Restricted
Behavior Testing
Behavioral Testing is a testing of the external behavior of the program, also
known as black box testing. It is usually a functional testing.

14. Page 14Classification: Restricted
Random Testing
What is Random Testing?
Random Testing, also known as monkey testing, is a form of functional
black box testing that is performed when there is not enough time to
write and execute the tests.
Random Testing Characteristics:
• Random testing is performed where the defects are NOT identified in regular
intervals.
• Random input is used to test the system's reliability and performance.
• Saves time and effort than actual test efforts.
• Other Testing methods Cannot be used to.
Random Testing Steps:
• Random Inputs are identified to be evaluated against the system.
• Test Inputs are selected independently from test domain.
• Tests are Executed using those random inputs.
• Record the results and compare against the expected outcomes.
• Reproduce/Replicate the issue and raise defects, fix and retest.

15. Page 15Classification: Restricted
White Box Techniques
White Box Techniques
• Path Testing
• Statement Coverage
• Data Flow
• Syntax Testing

16. Page 16Classification: Restricted
Path Testing
What is Path Testing?
Path Testing is a structural testing method based on the source code or
algorithm and NOT based on the specifications. It can be applied at different
levels of granularity.
Path Testing Assumptions:
• The Specifications are Accurate
• The Data is defined and accessed properly
• There are no defects that exist in the system other than those that affect
control flow
Path Testing Techniques:
• Control Flow Graph (CFG) - The Program is converted into Flow graphs by
representing the code into nodes, regions and edges.
• Decision to Decision path (D-D) - The CFG can be broken into various Decision
to Decision paths and then collapsed into individual nodes.
• Independent (basis) paths - Independent path is a path through a DD-path
graph which cannot be reproduced from other paths by other methods.

17. Page 17Classification: Restricted
Statement Coverage
Statement coverage is a white box testing technique, which involves the
execution of all the statements at least once in the source code. It is a metric,
which is used to calculate and measure the number of statements in the
source code which have been executed.
Using this technique we can check what the source code is expected to do
and what It should not. It can also be used to check the quality of the code
and the flow of different paths in the program.
The main drawback of this technique is that we cannot test the false
condition in it

18. Page 18Classification: Restricted
(Statement coverage = No of statements Executed/Total no of statements in the source code *
100)
Example:
Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif
Set1 :If A =5, B =2
No of statements Executed: 5
Total no of statements in the source code: 7
Statement coverage =5/7*100 = 71.00 %
Set1 :If A =2, B =5
No of statements Executed: 6
Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20 %
This is purely a white box testing method. It tests the software’s internal coding and
infrastructure and so the programmer is the one who should take the initiative to do this.
This technique is very suitable for programmers.

19. Page 19Classification: Restricted
Data Flow Testing
What is Data Flow Testing?
Data flow testing is a family of test strategies based on selecting paths
through the program's control flow in order to explore sequences of
events related to the status of variables or data objects. Dataflow
Testing focuses on the points at which variables receive values and the
points at which these values are used.
Advantages of Data Flow Testing:
• Data Flow testing helps us to pinpoint any of the following issues:
• A variable that is declared but never used within the program.
• A variable that is used but never declared.
• A variable that is defined multiple times before it is used.
• Deallocating a variable before it is used.

20. Page 20Classification: Restricted
Thank You