Test planning is the process of defining and documenting the strategy to verify that a product meets its requirements. A test plan should be created by quality management and answer questions like how, who, what, how long, and test coverage level required. According to IEEE standards, a test plan includes items like test plan identifier, introduction, features to be tested, approach, pass/fail criteria, responsibilities, and schedule. A test design specification describes features to be tested and specifies test scenarios/cases to provide software testing. Test design techniques include static techniques like reviews and dynamic techniques like structure-based, experience-based, and specification-based approaches. Choosing the right technique depends on factors like tester knowledge, expected defects, test objectives,

1. Test Design

2. Test Planning
 Test Planning – the process of defining
and documenting the strategy that will be
used to verify and ensure that a product or
system meets its design specifications and
other requirements.
 Test Plan document should be created by
QC management (QC Analyst/QC Lead/QC
Manager) and answer on the following
questions:
– How the testing will be done?
– Who will do it?
– What will be tested?
– How long it will take?
– What the test coverage will be, i.e. what
quality level is required?

3.  According to IEEE 829 (Standard for Software
Test Documentation ) Test Plan consists of:
– Test plan identifier
– Introduction
– Test items
– Features to be tested
– Features not to be tested
– Approach
– Item pass/fail criteria
– Suspension criteria and resumption requirements
– Test deliverables
– Testing tasks
– Environmental needs
– Responsibilities
– Staffing and training needs
– Schedule
– Risks and contingencies
– Approvals
Test Plan Structure

4. Test Analysis
Test Design Techniques
Selection
Test Design Specification
Test Case Specification
Test Plan
SRS
Mock-ups
Test Design
Specification
…
Trainings’ Content

5. Test Design Specification
 Test Design Specification
– It is a document that
describes features to be
tested and specifies list of
all test scenarios or test
cases, which should be
designed for providing the
testing of software.
– The test design does not
record the values to be
entered for a test, but
describes the requirements
for defining those values.

6. Test Design Specification Structure
According to IEEE-829 standard template structure of Test Design
Specification looks in the following way:
1. Test Design Specification Identifier
1.1 Purpose
1.2 References
1.3 Definitions, acronyms and abbreviations
2. Features to be Tested
3. Approach Refinements
4. Test Identification
4.1 <Test Item 1>
4.2 <Test Item …>
4.3 <Test Item N>
5. Feature Pass/Fail Criteria

7. Test Design Techniques
Test Design Techniques
Static: The fundamental objective
of static testing is to improve the
quality of software work products
by assisting engineers to recognize
and fix their own defects early in
the software development.
Dynamic: Testing that involves the
execution of the software of a
component or system.

8. Static Techniques
Static Techniques
Static Analysis
Control Flow
Structure
Data Flow
Structure
Informal Reviews
Walkthroughs
Technical Reviews
Inspections
Data Structure

9. Dynamic Techniques
Dynamic
Techniques
Structure – Based
Experience – Based
Specification-Based
Equivalence
Partitioning
State Transition
Decision Tables
Use Case
Testing
Boundary
Values Analysis
Error Guessing
Exploratory
Testing
Statement
Decision
Condition
Multiple
Condition
Testing, either functional or non-
functional, without reference to
the internal structure of the
component or system. These are
also called black-box techniques.

10. Equivalence Partitioning
 Equivalence partitioning (EP) – A black box test design technique in which test
cases are designed to execute representatives from equivalence partitions.
 Idea: Divide (i.e. to partition) a set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them equivalently), hence
equivalence partitioning. In principle test cases are designed to cover each partition
at least once.
 Example: Bank represents new deposit program for corporate clients. According to the
program client has ability to get different %, based on amount of deposited money.
Minimum which can be deposited in $1, maximum is – $999. If client deposits less than
$500 it will have 5% of interests. In case the amount of deposited money is $500 and
higher, then client gets on 10% of interests more.

11. Boundary Values Analysis
 Boundary value analysis (BVA): A black box test design technique in which test
cases are designed based on boundary values.
Boundary value is an input value or output value which is on the edge of an
equivalence partition or at the smallest incremental distance on either side of an
edge, for example the minimum or maximum value of a range.
 Idea: Divide test conditions into sets and test the boundaries between these sets.
Tests should be written to cover each boundary value.
 Example: Bank represents new deposit program for corporate clients. According to the
program client has ability to get different %, based on amount of deposited money.
Minimum which can be deposited in $1, maximum is – $999. If client deposits less than
$500 it will have 5% of interests. In case the amount of deposited money is $500 and
higher, then client gets on 10% of interests more.

12.  Decision table – A table showing combinations of inputs and/or stimuli (causes)
with their associated outputs and/or actions (effects), which can be used to design
test cases.
 Idea: Divide test conditions into constraints, which could get positive or negative
meanings, and rules which identify output based on values of conditions. While
analyzing each possible variant of positive and negative meanings identify output or
set of outputs for each variant based on the rules. Only combinations of these
positive and negative meanings, which uniquely identify decisions that are
made, should be covered by tests.
 Example: If you hold an 'over 60s' rail card, you get a 34% discount on whatever ticket
you buy. If you hold family rail card and you are traveling with a child (under 16), you can
get a 50% discount on any ticket. If you are traveling with a child (under 16), but do not
have family rail card, you can get a 10% discount. You can use only one type of rail card.
Decision Tables

13. - 'over 60s' rail card – 34%
- family rail card and traveling with a child – 50%
- traveling with a child, but do not have family rail card – 10%
- only one type of rail card can be used
Decision Tables

14. State Transition
 State transition testing – A black box test design technique in which test cases
are designed to execute valid and invalid state transitions.
State transition – A transition between two states of a component or system.
 Idea: Design diagram that shows the events that cause a change from one state to
another. Tests should cover each path starting from the longest state combination.
 Example: Client of the bank would like to take money from bank account using cash
machine. To get money he should enter valid Personal Identity Number (PIN). In case of 3
invalid tries, cash machine eats the card.
Start
Access to
account
Eat card
Wait for
Pin
1st try
Enter
Pin Ok
3rd try2nd try
Pin
NOT Ok
Pin
NOT Ok
Card inserted
Pin Ok
Pin Ok
Pin
NOT Ok

15. Use Case Testing
 Use Case testing - is a technique that helps us identify test cases that exercise the
whole system on a transaction by transaction basis from start to finish.
– Use cases describe the process flows through a system based on its most likely
use
– This makes the test cases derived from use cases particularly good for finding
defects in the real-world use of the system
– Each use case usually has a mainstream (or most likely) scenario and sometimes
additional alternative branches (covering, for example, special cases or
exceptional conditions).
– Each use case must specify any preconditions that need to be met for the use
case to work.
– Use cases must also specify post conditions that are observable results and a
description of the final state of the system after the use case has been executed
successfully.

16. Structure-Based Techniques
Dynamic
Techniques
Structure – Based Experience – Based Specification-Based
Equivalence
Partitioning
State Transition
Decision Tables
Use Case
Testing
Boundary
Values Analysis
Error Guessing
Exploratory
Testing
Statement
Decision
Condition
Multiple
Condition
Procedure to derive and/or
select test cases based on an
analysis of the internal structure
of a component or system.
These are also called while-box
techniques.

17. Statement Testing
 Statement – an entity in a programming language, which is typically the smallest
indivisible unit of execution.
 Example:

18. Decision Testing
 Decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-
UNTIL), or a CASE statement, where there are two or more possible exits or
outcomes from the statement.
 Example:

19. Experience-Based Techniques
Dynamic
Techniques
.
Structure – Based Experience – Based
Specification-Based
Equivalence
Partitioning
State Transition
Decision Tables
Use Case
Testing
Boundary
Values Analysis
Error Guessing
Exploratory
Testing
Statement
Decision
Condition
Multiple
Condition
Procedure to derive and/or select
test cases based
on the tester’s
experience, knowledge and
intuition.

20. Choosing A Test Design Technique
 Which technique is best? This is the wrong question!
Each technique is good for certain things, and not as good for other things. Some techniques are
more applicable to certain situations and test levels, others are applicable to all test levels.
 The internal factors that influence the decision about which technique to
use are:
– Tester knowledge and experience
– Expected defects
– Test objectives
– Documentation
– Life cycle model
 The external factors that influence the decision about which technique to
use are:
– Risks
– Customer and contractual requirements
– System type
– Regulatory requirements
– Time and budget

21. Thank You!