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
Informal Review – a review not based on a formal (documented) procedure.Walkthrough – a step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content.Technical Review – a peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.Inspection – a type of peer review that relies on visual examination of documents to detect defects. The most formal review technique and therefore always based on a documented procedure.Control Flow Structure– a form of static analysis based on a representation of unique paths (sequences of events) in the execution through a component or system. Control flow analysis evaluates the integrity of control flow structures, looking for possible control flow anomalies such as closed loops or logically unreachable process steps.Data Flow Structure–aform of static analysis based on the definition and usage of variables.Data Structure- aform of static analysis based on the organization of the data itself, independent of the program.
Statement -A testing aimed at exercising programming statements. If we aim to test every executable statement we call this full or 100% statement coverage.Decision -A white box test design technique in which test cases are designed to execute decision outcomes.Condition -A white box test design technique in which test cases are designed to execute condition outcomes – the evaluation of a condition to True or False.Multiply Condition -A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement.