Module -4

1. Test Development Process :-

Test conditions, Test case Specification, Test Procedure Specification,
Test Script, Traceability.
The test development process can be done in different ways, from
very informal with little or no documentation, to very formal (as it is
described below). The level of formality depends on the context of the
testing, including the organization, the maturity of testing and
development processes, time constraints and the people involved.
 1.1 Test Analysis:-The process of analyzing the test basis and
defining test objectives.
 Test analysis is the process of looking at something that
can be used to derive test information.
 Test basis – All the Input Documents required to create the
test case specifications.
 The test basis is the information we need in order to start
the test analysis and create our own test cases. Basically
it’s a documentation on which test cases are based, such as
requirements, design specifications, product risk analysis,
architecture and interfaces etc.
 During test analysis, the test basis documentation is
analyzed in order to determine what to test, i.e. to identify
the test conditions.
 A test condition is defined as an item or event that could
be verified by one or more test cases(for eg. - A function,
Transaction, feature, quality attribute or structural element).
 While identifying the test conditions we want to identify as
many conditions as we can and then we select about which
one to take forward and combine into test cases. We could
call them test possibilities.
 As we know that testing everything is an impractical goal,
which is known as exhaustive testing. We cannot test
everything, we have to select a subset of all possible tests.
In practice the subset we select may be a very small subset
and yet it has to have a high probability of finding most of
the defects in a system. Hence we need some intelligent
thought process to guide our selection called test
techniques. The test conditions that are chosen will
 depend on the test strategy or detailed test approach. For
example, they might be based on risk, models of the
system, etc.
 Once we have identified a list of test conditions, it is
important to prioritize them, so that the most important test
conditions are identified and tested first.
 1.2 Traceability:-
 Test conditions should be able to be linked back to their
sources in the test basis, this is known as traceability.
 A requirements traceability matrix is a document that
traces and maps user requirements with the test case ids.
Purpose is to make sure that all the requirements are
covered in test cases so that while testing no functionality
can be missed. This document is prepared to make the
clients satisfy that the coverage done is complete as end to
end.
 Now, the question may arise is that Why is traceability
important? So, let’s have a look on the following examples:-
The requirements for a given function or feature have
changed. Some of the fields now have different ranges that
can be entered. Which tests were looking at those
boundaries? They now need to be changed. How many tests
will actually be affected by this change in the requirements?
These questions can be answered easily if the requirements
can easily be traced to the tests. A set of tests that has run
OK in the past has now started creating serious problems.
What functionality do these tests actually exercise?
Traceability between the tests and the requirement being
tested enables the functions or features affected to be
identified more easily.
 Benefits of using Traceability Matrix
 Make obvious to the client that the software is being
developed as per the requirements.
 To make sure that all requirements included in the test
cases
 To make sure that developers are not creating features
that no one has requested
 Easy to identify the missing functionalities.
  If there is a change request for a requirement, then we can
easily find out which test cases need to update.
 The completed system may have “Extra” functionality that
may have not been specified in the design specification,
resulting in wastage of manpower, time and effort.

 1.3 Test Design:-

 During test design the test cases and test data are
created and specified. A test case consists of a set of input
values, execution preconditions, expected results and
execution post-conditions, developed to cover certain test
objective(s) or test condition(s).
 Test cases can be documented as described in the
IEEE 829 Standard for Test Documentation.
 Expected results should be produced as part of the
specification of a test case and include outputs, changes to
data and states, and any other consequences of the test. If
expected results have not been defined then a
plausible(seeming likely to be true, or able to be believed),
but erroneous, result may be interpreted as the correct one.
Expected results should ideally be defined prior to test
execution.
 1.4 Test Implementation :-
 During test implementation the test cases are developed,
implemented, prioritized, and organized in the test
procedure specification. The document that describes the
steps to be taken in running a set of tests and specifies the
executable order of the tests is called a test procedure in
IEEE 829 i.e. it specifies the sequence of actions for the
execution of a test. Test script is also used to describe the
instructions to a test execution tool. An automation script is
written in a programming language that the tool can
understand (This is an automated test procedure.).
 If tests are run using a test execution tool, the sequence of
actions is specified in a test script (which is an automated
test procedure).
2. Categories of Test Design Techniques :-
 The purpose of a test design technique is to identify test
conditions and test cases.
 A test design technique basically helps us to select a good set of
tests from the total number of all possible tests for a given
system. There are many different types of software testing
technique, each with its own strengths and weaknesses.
 Each individual technique is good at finding particular types of
defect and relatively poor at finding other types.
 Each testing technique falls into one of a number of different
categories. Broadly speaking there are two main categories:-
1. Static technique
2. Dynamic technique
 Dynamic techniques are subdivided into three more
categories:-
1. Specification-based Test Design Techniques (black-box
techniques, also known as behavioural techniques):-
Specification-based techniques include both functional and non-
functional techniques (i.e. quality characteristics).
 This are based on an analysis of the structure of the
component or system.
 The testers have no knowledge of how the system or
component is structured inside the box. In black-box testing
the tester is concentrating on what the software does, not how
it does it.
 It is also called as input/output driven testing techniques
because they view the software as a black-box with inputs and
outputs.
 The definition mentions both functional and non-functional
testing. Functional testing is concerned with what the system
does its features or functions. Non-functional testing is
concerned with examining how well the system does. Non-
functional testing like performance, usability, portability,
maintainability, etc.
 Specification-based techniques are appropriate at all levels of
testing (component testing through to acceptance testing)
where a specification exists. For example, when performing
system or acceptance testing, the requirements specification
or functional specification may form the basis of the tests.
 Common Characteristics/features of specification-based
techniques:-
 Models, either formal or informal, are used for the
specification of the problem to be solved, the software or its
components.
 From these models test cases can be derived systematically.
 There are four specification-based or black-box technique:-
 Equivalence partitioning :-
Equivalence partitioning (EP) is a black-box technique. It
can be applied at any level of testing like Component
(unit), integration, system, etc. and is often a good
technique to use first.
 In equivalence partitioning, inputs to the software or
system are divided into groups or sets that are
expected to exhibit similar behaviour(i.e. the
system should handle them equivalently), so they
are likely to be processed in the same way.
 Equivalence partitions (or classes) can be found for
both valid data and invalid data.
 Partitions can also be identified for outputs, internal
values, time-related values (e.g. before or after an
event) and for interface parameters.
 In equivalence-partitioning technique we need to
test only one condition from each partition. This is
because we are assuming that all the conditions in
one partition will be treated in the same way by the
software. If one condition in a partition works, we
assume all of the conditions in that partition will
work, and so there is little point in testing any of
these others. Similarly, if one of the conditions in a
partition does not work, then we assume that none
of the conditions in that partition will work so again
 there is little point in testing any more in that
partition.
 Equivalence partitioning is applicable at all levels of
testing.
 Equivalence partitioning can be used to achieve
input and output coverage goals.
 It can be applied to human input, input via
interfaces to a system, or interface parameters in
integration testing.

 Boundary value analysis :-

 Behaviour at the edge of each equivalence partition is
more likely to be incorrect than behaviour within the
partition, so boundaries are an area where testing is
likely to yield defects. Here we have both valid
boundaries (in the valid partitions) and invalid
boundaries (in the invalid partitions).
 The maximum and minimum values of a partition are
its boundary values. Tests can be designed to cover
both valid and invalid boundary values. When
designing test cases, a test for each boundary value is
chosen.
 Boundary value analysis can be applied at all test
levels. It is relatively easy to apply and its defect
finding capability is high.
 This technique is often considered as extension of
equivalence partitioning or other black box test design
techniques.

 Decision tables Testing :-

 The techniques of equivalence partitioning and
boundary value analysis are often applied to specific
situations or inputs. However, if different combinations
of inputs result in different actions being taken, this
can be more difficult to show using equivalence
 partitioning and boundary value analysis, which tend
to be more focused on the user interface.
 The other two specification-based software testing
techniques, decision tables and state transition testing
are more focused on business logic or business rules.
 A decision table is a good way to deal with
combinations of things (e.g. inputs). This technique is
sometimes also referred to as a ’cause-effect’ table.
 Decision tables provide a systematic way of stating
complex business rules, which is useful for developers
as well as for testers.
 Decision tables can be used in test design whether or
not they are used in specifications, as they help
testers explore the effects of combinations of different
inputs and other software states that must correctly
implement business rules.
 Show sets of conditions and the actions.
 Logic can be easily expressed in a table format.
Condition Stub Condition Entries

Action Stub Action Entries

 State transition testing :-

 It is a black box testing technique in which the tester
analyses the behaviour 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 behaviour.
 State transition testing is used where some aspect of
the system can be described in what is called a ‘finite
state machine’. This simply means that the system
can be in a (finite) number of different states, and the
transitions from one state to another are determined
by the rules of the ‘machine’. This is the model on
which the system and the tests are based.
  Any system where you get a different output for the
same input, depending on what has happened before,
is a finite state system.
 A finite state system is often shown as a state
diagram.

Enter Url Blocked

1st
2nd
Attempt Attempt 3rd
Attempt S4
S0

Login
Login Login
Page
Page Page
S2 S3
S1

Home
Page S5

 One of the advantages of the state transition

technique is that the model can be as detailed or as
abstract as you need it to be. Where a part of the
system is more important (that is, requires more
testing) a greater depth of detail can be modeled.
Where the system is less important (requires less
testing), the model can use a single state to signify
what would otherwise be a series of different states.
 We need to focus on Four Component:
 State (Current Stage)
 Input/Output (Put Input)
 Transition(Show flow)
 Action(Outcome of input)
  Use Case Testing :-
 Tests can be derived from use cases. A use case
describes interactions between actors (users or
system), which produce a result of value to a system
user or customer.
 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. A use case usually
has a mainstream (i.e. most likely) scenario, and
sometimes alternative branches.
 Use cases describe the “process flows” through a
system based on its actual likely use, so the test cases
derived from use cases are most useful in uncovering
defects in the process flows during real-world use of
the system. Use cases, often referred to as scenarios,
are very useful for designing acceptance tests with
customer/user participation.

2. Structure-based Test Design Techniques (white-box or

structural techniques):-
 Structure-based testing technique is also known as ‘white-box’
or ‘glass-box’ testing technique because here the testers
require knowledge of how the software is implemented, how it
works.
 Test Coverage -: Test Coverage is a degree expressed in
percentage of specified coverage time examine/excersized by
test suites.
Coverage =number of coverage item exersized/examine
* 100
total number of coverage

 Coverage is calculate at each level of testing at

1)Component level ->Code coverage ->white-box technique
2)Integration level ->interaction between module
3)System/Acceptance level ->Business process &
Requirement
 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 of a software
component, i.e. statements, decisions or branches or
even distinct paths.
 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.
 In white-box testing the tester is concentrating on how the
software does it. For example, a structural technique may be
concerned with exercising loops in the software.
 Different test cases may be derived to exercise the loop once,
twice, and many times. This may be done regardless of the
functionality of the software.
 Structure-based techniques can also be used at all levels of
testing. Developers use structure-based techniques in
component testing and component integration testing,
especially where there is good tool support for code coverage.
 Structure-based techniques are also used in system and
acceptance testing, but the structures are different. For
example, the coverage of menu options or major business
transactions could be the structural element in system or
acceptance testing.
 Common Characteristics/features of structure-based
techniques:-
 Information about how the software is constructed is used
to derive the test cases, for example, code and design.
 The extent of coverage of the software can be measured for
existing test cases, and further test cases can be derived
systematically to increase coverage.
 There are four Structure-based or White-box technique:-
 Statement Coverage:-
 The statement coverage is also known as line
coverage or segment coverage. The statement
coverage covers only the true conditions. Through
statement coverage we can identify the statements
executed and where the code is not executed
because of blockage.
 It is examine each line of code and check whether it
execute at least once
 In this process each and every line of code needs to
be checked and executed
 Advantage of statement coverage:-
 It verifies what the written code is expected to do
and not to do
 It measures the quality of code written
It checks the flow of different paths in the
program and it also ensure that whether those
path are tested or not.
 Disadvantage of statement coverage:-
 It cannot test the false conditions.
 It does not report that whether the loop reaches
its termination condition.
 It does not understand the logical operators.

 Statement coverage is determined by the

number of executable statements covered by
(designed or executed) test cases divided by
 the number of all executable statements in
the code under test.

 Decision Coverage(Branch Coverage):-

 Decision coverage is also known as Branch coverage or
all-edges coverage.
 It covers both the true and false conditions unlikely the
statement coverage.
 A branch is the outcome of a decision, so branch
coverage simply measures which decision outcomes
have been tested. This sounds great because it takes a
more in-depth view of the source code than simple
statement coverage
 A 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 outcomes
from the statement. With an IF statement, the exit can
either be TRUE or FALSE, depending on the value of
the logical condition that comes after IF.
 It is a white-box testing techniques
 Each edges are check at-least once
 Branch Coverage focus on true & false condition

 Advantages of decision coverage:-

 To validate that all the branches in the code are
reached
 To ensure that no branches lead to any abnormality
of the program’s operation
 It eliminate problems that occur with statement
coverage testing
 Disadvantages of decision coverage:-
 This metric ignores branches within boolean
expressions which occur due to short-circuit
operators.
  Decision Coverage is determined by the number
of all decision outcomes covered by (designed
or executed) test cases divided by the number
of all possible decision outcomes in the code
under test.
 Decision coverage is stronger than statement
coverage: 100% decision coverage guarantees 100%
statement coverage, but not vice versa.

 Path Coverage:-
 Path coverage is a specific kind of methodical,
sequential testing in which each individual line of code
is assessed.
 As a type of software testing, path coverage is in the
category of technical test methods, rather than being
part of an overarching strategy or "philosophy" of
code. It is labour-intensive and is often reserved for
specific vital sections of code.
 The way that path coverage testing works is that the
testers must look at each individual line of code that
plays a role in a module and, for complete coverage,
the testers must look at each possible scenario, so
that all lines of code are covered.
 In a very basic example, consider a code function that
takes in a variable "x" and returns one of two results: if
x is greater than 5, the program will return the result
"A" and if x is less than or equal to 5, the program will
return the result "B."
 The code for the program would look something like
this:
input x
if x > 5 then
 return A
else return B
 In order for path coverage testing to effectively "cover
all paths," the two test cases must be run, with x
greater than 5 and x less than or equal to 5.
 Obviously, this method becomes much more
complicated with more complex modules of code.
Experts generally consider path coverage testing to be
a type of white box testing, which actually inspects the
internal code of a program, rather just relying on
external inputs and strategies that are considered
black box testing, which do not consider internal code.

 Condition Coverage:-
This is closely related to decision coverage but has better
sensitivity to the control flow. However, full condition
coverage does not guarantee full decision coverage.
 Condition coverage reports the true or false
outcome of each condition.
 Condition coverage measures the conditions
independently of each other.
 Multiple Condition Coverage(condition combination
coverage)
[Other control-flow code-coverage measures
include linear code sequence and jump (LCSAJ)
coverage, multiple condition coverage (also known
as condition combination coverage) and condition
determination coverage (also known as multiple
condition decision coverage or modified condition
decision coverage, MCDC). This technique requires
the coverage of all conditions that can affect or
determine the decision outcome.]
3. Experience- based Test Design Techniques:-
 In experience-based techniques, people’s knowledge, skills
and background are of prime importance to the test conditions
and test cases.
 Experienced-based testing is where tests are derived from the
tester’s skill and intuition and their experience with similar
applications and technologies.
 The experience of both technical and business people is
required, as they bring different perspectives to the test
analysis and design process. Because of the previous
experience with similar systems, they may have an idea as
what could go wrong, which is very useful for testing.
 When used to augment systematic techniques (augment-to
make greater, more numerous, larger, or more intense), these
techniques can be useful in identifying special tests not easily
captured by formal techniques, especially when applied after
more formal approaches. However, this technique may yield
widely varying degrees of effectiveness, depending on the
testers’ experience.
 A commonly used experienced-based technique is error
guessing. Generally testers anticipate defects based on
experience. A structured approach to the error guessing
technique is to enumerate a list of possible errors and to
design tests that attack these errors. This systematic approach
is called fault attack. These defect and failure lists can be built
based on experience, available defect and failure data, and
from common knowledge about why software fails.
 Experience-based techniques go together with specification-
based and structure-based techniques, and are also used
when there is no specification, or if the specification is
inadequate or out of date.
 This may be the only type of technique used for low-risk
systems, but this approach may be particularly useful under
extreme time pressure – in fact this is one of the factors
leading to exploratory testing.
 Common Characteristics/features of experience-based
techniques:-
 The knowledge and experience of people are used to derive
the test cases.
 Knowledge of testers, developers, users and other
stakeholders about the software, its usage and its
environment is one source of information.
 Knowledge about likely defects and their distribution is
another source of information.
3.1 Error guessing :-
 The Error guessing is a technique where the experienced and
good testers are encouraged to think of situations in which the
software may not be able to cope. Some people seem to be
naturally good at testing and others are good testers because
they have a lot of experience either as a tester or working with
a particular system and so are able to find out its weaknesses.
 This is why an error guessing approach, used after more
formal techniques have been applied to some extent, can be
very effective. In using more formal techniques, the tester is
likely to gain a better understanding of the system, what it
does and how it works. With this better understanding, he or
she is likely to be better at guessing ways in which the system
may not work properly.
 It also saves a lot of time because of the assumptions and
guessing made by the experienced testers to find out the
defects which otherwise won’t be able to find.
 The success of error guessing is very much dependent on the
skill of the tester, as good testers know where the defects are
most likely to be.
 Typical conditions to try include division by zero, blank (or no)
input, empty files and the wrong kind of data (e.g. alphabetic
characters where numeric are required).
3.2 Exploratory testing :-
 As its name implies, exploratory testing is about exploring,
finding out about the software, what it does, what it doesn’t
do, what works and what doesn’t work. The tester is
constantly making decisions about what to test next and
where to spend the (limited) time. This is an approach that is
most useful when there are no or poor specifications and when
time is severely limited.
 Exploratory testing is a hands-on approach in which testers
are involved in minimum planning and maximum test
execution.
 The planning involves the creation of a test charter, a short
declaration of the scope of a short (1 to 2 hour) time-boxed
test effort, the objectives and possible approaches to be used.
 The test design and test execution activities are performed in
parallel typically without formally documenting the test
conditions, test cases or test scripts. This does not mean that
other, more formal testing techniques will not be used. For
example, the tester may decide to us boundary value analysis
but will think through and test the most important boundary
values without necessarily writing them down. Some notes will
be written during the exploratory-testing session, so that a
report can be produced afterwards.
 Test logging is undertaken as test execution is performed,
documenting the key aspects of what is tested, any defects
found and any thoughts about possible further testing.
 It can also serve to complement other, more formal testing,
helping to establish greater confidence in the software. In this
way, exploratory testing can be used as a check on the formal
test process by helping to ensure that the most serious
defects have been found.
3. Choosing Test Techniques :-
 It can also serve to complement other, more formal testing,
helping to establish greater confidence in the software. In this
way, exploratory testing can be used as a check on the formal
test process by helping to ensure that the most serious defects
have been found.
 How to choose that which technique is best? This is the wrong
question!
Each technique is good in its own way in finding out the certain
kind of defect, and not as good for finding out the other kind of
defects. For example, one of the benefits of structure-based
techniques is that they can find out the defects or things in the
code that aren’t supposed to be there, such as ‘Trojan horses’ or
other malicious code.
 However, if there are parts of the specification that are
missing from the code, only specification-based techniques will
find that, structure-based techniques can only test what is there.
 If there are things missing from the specification and from the
code, then only experience based techniques would find them.
Hence, each individual technique is aimed at particular types of
defect. For example, state transition testing is unlikely to find
boundary defects. So, how to choose which testing technique is
best, decision will be based on a number of factors, both internal
and external.
 The internal factors that influence the decisions about
which technique to use are:
 Models used in developing the system–
 Testers knowledge and their experience –
 Similar type of defects – Test objective –
 Documentation –
 Life cycle model used –
 The external factors that influence the decisions about
which technique to use are:
 Risk assessment –
 Customer and contractual requirements –
 Type of system used –
 Regulatory requirements –
 Time and budget of the project –