Test Design Techniques

Neha Kalbande
15th April’08

December 8, 2021 TCS Confidential

 Test Development Process

– Terms to be known:

 test case specification

 test design
 test execution schedule
 test procedure specification
 test script
 traceability

December 8, 2021 2
Test Process Involves…

December 8, 2021 3
 Black-box testing

Black-box techniques (which include specification-based and

experience-based techniques) are a way to derive and select test
conditions/test cases based on an analysis of the test basis
documentation and the experience of developers ,testers and users,
whether functional or non-functional, for a system without reference
to its internal structure.

December 8, 2021 4
 Types of black-box techniques

 Equivalence partitioning

• The tester identifies various equivalence classes for partitioning

• A class is a set of input conditions that are is likely to be handled the same way
by the system.

• If the system were to handle one case in the class erroneously, it would handle
all cases erroneously.

• For example, specifications state that a maximum of 4 purchase orders can be

registered against anyone product. The equivalence classes are : the valid
equivalence class: (number of purchase orders is greater than or equal to 1 and
less than or equal to 4 , also written as (1 < = no. of purchase orders < = 4) the
invalid class (no. of purchase orders> 4) the invalid class (no. of purchase
orders < 1)

December 8, 2021 5
Contd…

Advantages:

• To reduce the number of test cases to a necessary minimum.

• To select the right test cases to cover all possible scenarios.

Disadvantages:

• Software testing efforts at the extreme ends of the equivalence classes may not
be covered.

December 8, 2021 6
Contd…

 Boundary value analysis

• The maximum and minimum values of a partition are its boundary values
• Boundary value analysis is a method which refines equivalence partitioning. Boundary
value analysis generates test cases that highlight errors better than equivalence
partitioning.
• Unlike equivalence partitioning, it takes into account the output specifications when
deriving test cases.
• Example:" Input should be greater than equal to 10 and less than 50"
9, 10, 11 and 48, 49, 50

lower boundary -1, lower boundary, lower boundary+1 and upper boundary-1, upper
boundary, upper boundary+1

December 8, 2021 7
Contd…

 Decision table testing

• A decision table lists causes and effects in a matrix. Each column represents a unique
combination.
• Decision tables are a good way to capture system requirements that contain logical
conditions, and to document internal system design.
• Each column of the table corresponds to a business rule that defines a unique
combination of conditions, which result in the execution of the actions associated with that
rule. The coverage standard commonly used with decision table testing is to have at least
one test per column, which typically involves covering all combinations of triggering
conditions.

December 8, 2021 8
Contd…

Example
• No charges are reimbursed to the patient until the deductible has been met. After the
deductible has been met, reimburse 50% for Doctor's Office visits or 80% for Hospital
visits.
• There will be 4 rules. The first condition (Is the deductible met?) has two possible
outcomes, yes or no. The second condition (type of visit) has two possible outcomes,
Doctor's office visit (D) or Hospital visit (H). Two times two is four.

December 8, 2021 9
Contd…

 State transition testing

• Models each state a system can exist in
• All the possible inputs to the machine are enumerated across the columns of the
table. All the possible states are enumerated across the rows. From the state
transition table given above, it is easy to see that if the machine is in S1 (the first
row), and the next input is character 1, the machine will stay in S1. If a character 0
arrives, the machine will transition to S2 as can be seen from the second column. In
the diagram this is denoted by the arrow from S1 to S2 labeled with a 0.

December 8, 2021 10
Contd…

Use Case Testing

• Tests can be specified from use cases or business scenarios.

• Each use case has preconditions, which need to be met for a use case to work
successfully.
• Each use case terminates with post-conditions, which are the observable results and final
state of the system after the use case has been completed.

December 8, 2021 11
 White-box testing

White-box techniques (also called structural or structure-based

techniques) are based on an analysis of the structure of the
component or system.

Structure-based testing/white-box testing is based on an identified structure of the

software or system, as seen in the following examples:
• Component level: the structure is that of the code itself, i.e. statements, decisions or
branches.
• Integration level: the structure may be a call tree (a diagram in which modules call other
modules).
• System level: the structure may be a menu structure, business process or web page
structure.

December 8, 2021 12
 Types of white-box testing

 Statement testing and coverage

Statement coverage is the assessment of the percentage of executable statements that

have been exercised by a test case suite.

 Decision testing and coverage

Decision coverage, related to branch testing, is the assessment of the percentage of

decision outcomes (e.g. the True and False options of an IF statement) that have been
exercised by a test case suite.

Note:
100% decision coverage guarantees 100% statement coverage, but not vice
versa.

December 8, 2021 13
Contd…

For example:
If x=3 then
Display_messageX;
If y=2 then
Display_messageY;
Else
Display_messageZ;
Else
Display_messageZ;

December 8, 2021 14
 Experience-based Testing

• Use of experience to design test cases

• Experience can include
– Domain knowledge
– Knowledge of developers involved
– Knowledge of typical problems
• Two main types
– Ad Hoc Testing
– Exploratory Testing

December 8, 2021 15
Contd…

• Ad-hoc Testing
– Informal testing
– No preparation
– Not repeatable
– Cannot be tracked
• Exploratory Testing
– Informal
– Actually involves test design and control
– Useful when no specification is available
– Notes are taken and progress tracked

December 8, 2021 16
 Difference between Path, Branch and Statement Coverage

• How can 100% coverage be insufficient? Because statement and branch coverage do not
tell you whether the logic in your code was executed. Statement and branch coverage are
great for uncovering glaring problems found in unexecuted blocks of code, but they often
miss bugs related to both decision structures and decision interactions. Path coverage, on
the other hand, is a more robust and comprehensive technique that helps reveal defects
early.

• Achieving 100% statement and 100% branch coverage may not be adequate. A path
represents the flow of execution from the start of a method to its exit. A method with N
decisions has 2^N possible paths, and if the method contains a loop, it may have an
infinite number of paths. Fortunately, you can use a metric called cyclomatic complexity to
reduce the number of paths you need to test.

• The cyclomatic complexity of a method is one plus the number of unique decisions in the
method. Cyclomatic complexity helps you define the number of linearly independent paths,
called the basis set, through a method. The definition of linear independence is beyond the
scope of this article, but, in summary, the basis set is the smallest set of paths that can be
combined to create every other possible path through a method

December 8, 2021 17
Is Statement coverage enough?

December 8, 2021 18
Thank you

December 8, 2021 19