ISEB For-rndation Certificate in Software Testing 4 Test design techniques

based on the ISTQB syllabus

Practice exercise
A mortgage system will provide a discoilnted mortgage to those applicants
with a salary of between t20,000 and fso,000 (inclusive) per annum.
t '
;4:
'r
Create test cases for both valiO biiO invaticJ partitions

.p\

Partition

Classification

Expected

t
result

Value

@ SQS Group Ltd v1.3 Page 14 of 54.

ISEB Foundation Certiflcate in Software Testing 4 Test design techniques
based on lhe ISTQB syllabus

Using the technique

We are testing the age input field for a life assurance system. The rules are as
follows:

. 447 Too yourtg

. 18-65 Acceptable
. 66-99 Too old

The steps for using equivalence partitioning are

1. ldentify the boundaries.

2. ldentify the valid and invalid equivalence partitions
3. Create a test case for each partition.

0 99

Partition

Classification

Expected
result

Value

@ SQS Group Ltd v1 .3 Page 13 of 54.

 +-*:te-ai-- . --n

ISEB Foundation Certificate in Software Testing 4 Test design techniques

based on the ISTQB syllabus

Partitions can also be identified for outputs, internal values, time-related

values (e.9. before or after an event) and for interface parameters (e g during
integration testing).

Equivalence partitioning as a technique can be used to achieve input and

output coverage. lt can be applied to human input, input via interfaces to a
system, or intertace parameters in integration testing

For the purpose of this course we are focusing on inputs. ln fact, we are
simply skimming the surface of the technique - it can be a lot more involved
that the examples covered by this course.

o
Equivalence partitioning is suitaUe for@)test levels from component through
to acceptance testing.

@ SQS Group Ltd. v1 .3 Page 12 of 54

ISEB Foundation Certificate in Softvvare'[estrng 4 Test design techniques
based on the ISTQB syllabus

From this example code, we can see that it is not necessary to test every age
for the first requirement. Only one value is necessary to test the 0-17 range.

The question then becomes "which value?"

The system will treat each value from 0-17 the same, therefore each value is
as good as each other.

This is the same for the two other ranqes

An equivalence partition (also called an equivalence class) is a range of

values that are treated the same by the system (or component) or will produce
the same result.

Any value within a partition is, in terms of testing, the same as any other value
in that partition.

Therefore;

a lf one value in a partition finds a defect any other value in that

partition will likely do the same.

a Similarly, if one value does not find a defect no other value in

that partition is likely to find a defect.

Partitions can be classified as valid or invalid

a A valid partition is one that the system or component will accept

all values within that partition.

a An invalid partition is one that the system or component will

reject all values within that partition.

O SQS Group Ltd. v1 .3 Paqe 11 of54

ISEB Fourxlation Certificate in Software Testing 4 Test design technrques
based on the lSl OB syllabus

4.3 Specification-based or black-box techniques

4.3.L Equivatence partitioning ( t io, ,-,'\

Overview
Equivalence partitioning is a technique that is used to reduce the number of
test cases required. As exhaustive testing is not possible, equivalence
partitioning gives us a manageable subset of test cases with minimal loss of
coverage.

Equivalence partitioning is not the complete solution in itself. lt is frequently

used in conjunction with other techniques, especially bojlg1-ry value analysis
(the next technique covered in this course).
o

How it works
lmagine you are testing a life assurance system. There is an input field where
the user enters the age of the applicant.

The system has the following rules:

,,1
. o-17 Too young 1 n v.-L cn
, ' 18-65 Acceptable '' V,:\L'(\ -L\r'")
. 66-99 Too old j,,r. t.,lr L lr'

o
To validate the age entered, the developer will use code such as

if (applicantAge => 0 && applicantAge a=17)

applicationStatus = "No - [/inor"

if (applicantAge => 1B && applicantAge <=65)

applicationStatus = "Yes"

if (applicantAge => 66 && applicantAge <=99)

applicationStatus = "No - Retired"

@ SQS Group Ltd v1.3 Page 10 of 54.

ISEB Foundation Certiflcate in Software Testi|tg 4 Test design techniques
based on the ISTQB syllabus

Common features of experience-based techniques

a The knowledge and experience of people are used to derive the test
CASCS

o knowledge of testers, developers, users and other stakeholders

about the software, its usage and its environment,

o knowledge about likely defects and their distribution

@ SQS Group Ltd v1 .3 Page I of 54.

 ISEB Foundation Certiflcate in Software Testing 4 Test clesign technlclLtes
based on the lS fOB syllabus

Categories of fesf design techniques

,x 4.2
The purpose of a test design technique is to identify test conditions and test
cases.

It is a classic distinction to denote test techniques as black box or white box

Black-box techniques (which include specification-based and experience-

based techniques) are a way to derive and select test conditions or 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
component or system without reference to its internal structure.

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

are based on an analysis of the structure of the component or
techniques)
system.
o
Some techniques fall clearly into a single category; others have elements of
more than one category.

3 This syllabus refers to specification-based or experience-based approaches

as black-box techniques and structure-based as white-box techniques.

Common features of specification-based techniques:

a Models, either formal or informal, are used for the specification of the
problem to be solved, the software or its components.

a From these models test cases can be derived systematically

o
Common featu.res of structure-based techniques

a lnformation about how the software is constructed is used to derive the

test cases, for example, code and design.

a 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.

O SQS Group Ltd. v1.3 Page B of 54

ISEB Foundation Certificate in Software Testing 4 Test design techniques
based on the ISTQB syllabus

Test execution schedule

ID Unique id

Date / time of execution:

Order Test procedure lD Tester

@ SQS Group Ltd. v1.3 Page 7 of g.

ISEB Foundation Certificate in Software Testing 4 Test design techniques
based on the ISTOB syllabus

Test procedure specification

ID: Unique id

Pu
Describe the purpose of this procedure. lf this procedure execufes any test
cases, provide a reference for each of them.

ln addition, provide references to relevant sec/ions of the tesf item

documentation (e.9., references to usage procedures). :

S cial uirements:
ldentify any special requirements that are necessary for the execution of this
o
procedure. These may include prerequisite procedures, special skil/s
requirements, and special environmental requirements.

Procedure ste
lnclude following fhe sfeps as applicable

Log: Describe any special methods or formats for logging the results of fest
execution, the incidents observed, and any other events pertinent to the test).

Set up; Describe the sequence of actions necessary to prepare for execution of the
procedure.

Start: Describe the actions necessa4/ to begin execution of the procedure.

Proceed: Describe any actions necessa{y during execution of the procedure. o

Measure: Describe how the test measurements will be made (e.9., describe how
remote terminal response time is to be measured using a network simulator).

Shut down: Describe the actions necessa4/ fo suspend lestrng, when unscheduled
events dictate.'

Restart: ldentify any procedural restart points and describe the actions necessary to
restaft the procedure at each of these points.

Stop: Describe the actions necessa4f to bring execution to an orderly halt.

Wrap up: Describe the actions necessary to restore the environment.

Contingencies: Describe the actions necessa4y to deal with anomalous events that
may occur during execution.

@ SQS Group Ltd. v1 .3 Page 6 of 54.

 ISEB For-rndation Cerlificate in Software Testing 4 Test design techniques
based on the ISTOB syllabus

Test case specification

ID: Unique id

Test items:
ldentify and briefly describe the items & features to be exercised by thls tesf
case-

ln uts ifications:
Specify each input required to execute the test case. Some of the inputs will
be specified by value (with tolerances where appropriate), while others, such
as constant tables or transaction files, will be specified by name. ldentify all
appropriate databases, files, terminalmessages, memory resident areas, and
o values passed by the operating sysfem.

Out uts cifications

Specify all of the outputs and features (e.9., response time) required of the
test ifems. Provide the exact value (with tolerances where appropriate) for
each required output or feature.

Environmental needs:
Hardware: Specify the characferisfics and configurations of the hardware
required to execute lhis fesf case.

Software: Specify the system and application software required to execute

fhis fesf case.

o Other: Specify any other requiremenfs such as unique facility needs or

specially trained personnel.

S uirements:
ural
Describe any special constraints on the test procedures that execute fhis fesf
case. These constraints may involve special set up, operalor intervention,
output determination procedures, and specialwrap up.

lntercase de encies
List the identifiers of fesf cases that must be executed prior to this tesf case
Summarise the nature of the dependencies.

O SQS Group Ltd v1.3 Page 5 of 54.

ISEB Founclation Cerlificate in Software Testing 4 Test tlesign techniqr,res
base(l on the lS IQB syllabus

Test design specification

ID: Unique id

Features to be tested:
ldentify the test ifems and describe the features and combinations of features
that are the object of this fesf specifrcation.

For each feature or feature combination, a reference to ifs associaled

requirements in the item requirement specification or design specification
should be included.

roach refinements:
o
Specify the refinements to the approach described in the fesf plan. lnclude
test techniques to be used. The method of analysing results should be
identified (comparator program or visual inspection).

Specify the results of any analysis that provides a rationale for fesf case
selection. For example, one might specify conditions that permit a
determination of error tolerance (e.9. lhose conditions that distinguish valid
inputs from invalid inputs).

Summarise the common attributes of any fesf cases. This may include input
constraints that must be true for every input in the set of associafed /est
cases, any shared environment needs, any special procedural requirements
and any shared case dependencies.

Test identification o
List the identifier and a brief description of each test case associated with this
design. A pafticular fest case may be identified in more than one fest design
specification. List the identifier and a brief description of each procedure
associafed with this fesf. design specification.

Pass / fail criteria:

Specify the criteria to be used to determine whether the feature or feature
combination has passed or failed.

O SQS Group Ltd v'1 .3 Page 4 of 54

ISEB Foundation Certificate in Software lesting 4 Test design techniques
based on the ISTQB syllabus

Test condition
An item or event that could be verified by one or more test cases

Test case
A set of inputs, execution preconditions, and expected outcomes developed
for a particular objective

Test procedure
Detailed instructions for the execution of one or more test cases

Test design specification

A document specifying the details of the test approach for a software feature
or combination of software features and identifying the associated tests

Test case specification

A document specifying inputs, predicted results, and a set of execution
conditions for a test item

Test procedure specification

A document specifying a sequence of actions for the execution of a test

Test execution schedule

A document defining the order in which the various test procedures are
executed, when they are to be carried out and by whom

Examples of the above forms based on lEEEB29 Standard for software test
documentation can be found on the next 4 pages.

@ SQS Group Ltd. v1 .3 Page 3 of 54.

ISEB Foundation Certificate in Software Testing 4 Test design techniques
based on the ISTQB syllabus

The various test procedures and automated test scripts are subsequently
formed into a test execution schedule that defines the order in which the
various test procedures, and possibly automated test scripts, are executed,
when they are to be carried out and by whom. The test execution schedule
will take into account such factors as regression tests, prioritisation, and
technical and logical dependencies.

qr'

.;$
:6t

:r.

(
o

O SQS Group Lld v1.3 Page 2 ot 54

 ISEB Foundation Certificate in Soltware Testrng 4 Test design techniques
based on the ISTQB syllabus

4 Test design techniques

4.1 The fesf development process

The process described in this sections can be done in different ways, from
very iqfg4nal with little or no documentation, to very formal (as it is described ft--' ''*r0't
L\
b-etow). The level of formality depends on the context of the testing, including
the organisation, the maturity of testing and development processes, time
constraints, and the people involved.

14 During lggljlglygls, the tes/ basis documentation is analysed in order to

determine what to test, i.e. to identify the test conditions.

A fesf condition is defined as an item or event that could be verified by one or

more test cases (e g a function, transaction, quality characteristic or structural
element).

Establishing traceability from test conditions back to the specifications and

requirements enables both impact analysis, when requirements change, and
requirements coverage to be determined for a set of tests. During test
analysis the detailed test approach is implemented to select the test design
techniques to use, based on, among other considerations, the risks identified
(see chapter 5 for more on risk analysis).

)) Durino test desion the test cases and test data are clealed i.nd 9p ecified. A
test case consists of a set of inpg! l1flgeq, execution preconditions, expe cted
results and execution post-conditions, developed to cover ce rtain tebf
condition(s). The 'Sta ard for re test documentation' (IEEE 829)
describes the content of test design specifications (containing test conditions)
and test case specifications.

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. lf expected results have not been defined then a
plausible, but erroneous, result may be interpreted as the correct one.
Expected results should ideally be defined prior to test execution.

c) During test implementation the test cases are developed, implemented,

prioritised and organised in the test procedure specification. The test
procedure (or manual test script) specifies the sequenge of action for the
execution of a test. lf tests are run using a test execution tool, the sequence of
affilfspecitied in a test script (which is an automated test procedure).

@ SQS Group Ltd. v1 .3 Page 1 of 54