Test Specification

Issue 1
 TABLE OF CONTENTS

0 PREFACE.....................................................................................................................1
0.1 Purpose of this document............................................................................................1
0.2 Use of this document....................................................................................................1
0.3 Overview........................................................................................................................2
0.4 Testing within IDA.......................................................................................................2
1 INTRODUCTION........................................................................................................4
1.1 Purpose..........................................................................................................................4
1.2 Scope of testing.............................................................................................................5
1.3 Definitions, Acronyms and Abbreviations.................................................................6
1.4 References.....................................................................................................................6
1.5 Overview........................................................................................................................6
2 TEST PLANNING.......................................................................................................8
2.1 Test items.......................................................................................................................8
2.2 Features to be tested.....................................................................................................9
2.3 Features not to be tested..............................................................................................9
2.4 Approach.......................................................................................................................9
2.5 Item pass/fail criteria.................................................................................................10
2.6 Suspension criteria and resumption requirements.................................................10
2.7 Test deliverables.........................................................................................................11
2.8 Testing tasks................................................................................................................11
2.9 Environmental needs..................................................................................................11
2.10 Responsibilities...........................................................................................................12
2.11 Staffing and training needs.......................................................................................12
2.12 Schedule.......................................................................................................................12
2.13 Risks and contingencies.............................................................................................13
3 TEST DESIGNS.........................................................................................................14
3.1 Test Design Identifier.................................................................................................14
4 TEST CASE SPECIFICATION...............................................................................16
4.1 Test Case identifier.....................................................................................................16
5 TEST PROCEDURES...............................................................................................19
5.1 Test Procedure identifier...........................................................................................19
6 TEST REPORTS........................................................................................................21
6.1 Test Report identifier.................................................................................................21
DOCUMENT CONTROL.....................................................................................................22
DOCUMENT SIGNOFF.......................................................................................................22
DOCUMENT CHANGE RECORD.....................................................................................22
0 PREFACE

0.1 PURPOSE OF THIS DOCUMENT

#1 This document is a generic Test Specification document for use by IDA Projects. It
provides guidance and template material which is intended to assist the relevant
management or technical staff, whether client or supplier, in producing a
project- specific Test Specification document. It is also useful background reading for
anyone involved in developing or monitoring the IDA Management System
(IDA- MS).

0.2 USE OF THIS DOCUMENT

#1 This Preface is addressed to the users of this generic document and is not meant to be
retained in any project- specific Test Specification documents based on it.
#2 The remaining sections (numbered 1, 2, 3,…) constitute a template that should be
used to construct the project-specific Test Specification document.
 Text in normal case is in the most part “boilerplate” that can be retained,
amended or deleted in the document.
 Text in italics provides instructions on how to complete a section and should be
removed once the section is written.
#3 The template should be used pragmatically, that is - where a section is not relevant it
should be omitted. Conversely, the material contained in this document is not
necessarily exhaustive; if there is a subject that is relevant to the IDA Project, but is
not included in this document, it should still be included.
#4 This document has been prepared using MS  Word  97. The following variables are
currently recorded as File “Properties” under MS  Word. They may be modified by
that means or overwritten directly at each occurrence in the document, at the
discretion of the user.
a. “Summary” Properties
Title Type of document (i.e. Test Specification)
Author Author(s) of document
Keywords Document reference (i.e. IDA-MS-TS)
b. “Custom” Properties
Proj Id Short mnemonic of IDA Project (set, in this
document, to “Project Id”)
Project Full name of IDA Project (set, in this document, to
“Template for IDA Project”)
Contr Id Short identifier of contract (set, in this document, to
“Contract Id”)
Contract Full name of contract (set, in this document, to
“Template for specific development”)
Version Issue number (currently Issue 1)
Date Date of document (currently 17 January 2001)
0.3 OVERVIEW
#1 This preface is for information only.
#2 This preface will therefore not be retained in the project- specific document.
#3 The remaining sections (numbered 1, 2, 3,…) constitute a template that should be
used to construct the project-specific document.
 Text in normal case is in the most part “boilerplate” that can be retained,
amended or deleted in the document.
 Text in italics provides instructions on how to complete a section and should be
removed once the section is written.
#4 The template should be used pragmatically, that is - where a section is not relevant it
should be omitted. Conversely, the material contained in this document is not
necessarily exhaustive; if there is a subject that is relevant to the project, but is not
included in this document, it should still be included.

0.4 TESTING WITHIN IDA

#1 This document can be used for the two levels of testing – subsystem & system
acceptance and can be used for testing systems as well as software-only projects. It
may also be useful to set up a test specification for the reviewing of the User Guides.
It should be read in conjunction with the Review & Test Management Plan document,
which sets out the way in which the overall philosophy for testing of the system
should be planned based around a characterisation of the system. This will consider
factors such as, inter alia:
 The distributed nature of the architecture – is it a Federated, Distributed or
Point-to-Point system?
 It is a thin client, fat client, multi-tier system and the implications of this for
breaking down testing into stages?
 Is it a system that has been designed to have high resilience?
 How familiar are users with this system? How resilient has it to be to users
making simple mistakes when they are using it?
 The loading on the system – for example how many parallel users might be using
the system at the same time? What throughput in messages sent across the system
might be experienced at peak times?
 Any implications from the nature of the complexity of any database that may be
at the heart of the system or distributed around project participants?
 Is the system vulnerable to attack from outside? Could people subvert the system
and disable it ability to carry out its defined task? What security measures have
been built in to the system, such as to encrypt information or to authenticate
users?
#2 Another factor that will have a significant impact on the scale and approach to
testing is the development model that is being employed.
 The traditional system development lifecycle is represented in the Waterfall
model. Each stage in development is based on the results of the previous stage,
 which is assumed to embody all the requirements and constraints of prior stages.
Systems are therefore tested against their specifications, rather than the
requirements which were considered when developing the specifications.
 The V model is a variation of the waterfall model. It recognises that systems
should be verified against source requirements. Therefore system testing is
carried out against the system requirement, and user acceptance testing is
carried against the user requirement.
 Rapid Application Development (RAD) differs considerably from the above two
models. RAD is typically carried out in a series of discrete time periods
(“timeboxes”) in close collaboration with users. Only the time period is fixed;
the functionality that is delivered in that time, and the effort expended, may vary.
Testing verifies that the agreed functionality has been developed correctly, but
there is also a strong emphasis on reviews to ensure that the discrete
developments are progressing towards delivering a system which adequately
meets the top-level business requirement.
#3 The aim here is to encourage people concerned with testing a system to pause and
reflect on the nature of the system, its purposes and the risks associated with it. Well
planned tests, that are targeted at the key issues, will have far more impact than a
series of unplanned and incoherent tests of the system.
1 INTRODUCTION

#1 This section should provide an overview of the entire document and a description of
the scope of the system. Specific attention should be paid to the nature of the system
from the IDA viewpoint. In effect what is the mission for the system? For example,
this section should address question such as:
a. is this a system that is designed to collected information from different Member
States that will go into Brussels for use in an operational sense, such as system
which may track goods across Europe? or
b. is it a system that collects statistics and moves them in a common format into
Luxembourg to Eurostat?
The way the system is to be tested will depend upon the mission defined for the
system.
#2 In describing the scope of the system it is important to recognise at this point the
implications of how distributed the system is in operation as this will have a major
impact upon the testing that is to be defined in this document. An IDA system that
collects a specific statistic monthly is not likely to be tested in the same way as a
system providing daily updates of the movement of animals across the borders of the
European Union. Security risks will also need to be considered1.
#3 One facet that should concern the author of the Test Specification is the degree to
which the system that is being described is a federated, distributed or point-to-point
architecture. Federated systems are essentially those which act as equals in providing
and consuming information to and from the architecture. Distributed systems may
have a master node, perhaps based on a star configuration, that is the single point of
failure. Point-to-point systems can operate in a closely coupled relationship where
bespoke protocols enable them to communicate with one another as their application
software is activated.
#4 Another vital point is the degree to which the system has to be resilient to failure.
Some systems may require to operate in support of law enforcement agencies and be
required to operate on a 24 by 7 basis. Others can withstand downtime of several
days before creating difficulties for their users. This aspect of the characterisation of
the system is another important facet that needs to be addressed in this part of the
document in order that the testing required can be planned, designed, specified and
reported on correctly.

1.1 PURPOSE

#1 This section should:

c. describe the purpose of this document, including the level of testing involved;
d. specify the intended readership of this document.
#2 It is useful to reflect in this section what the purpose is of a test specification. In the
way this document has been constructed, in effect as a template for use on a wide
range of IDA projects we have set out to take the reader through the planning, the
1
 process of designing tests, the specification of the detail of the tests and the
procedures that govern how the tests are carried out. Finally we cover the form in
which tests are reported. In laying out this form we are making an assumption that
the basic development model that will be followed in the so-called waterfall
approach. In practice that might not be the case as systems may follow the ‘V’ model
or use Rapid Applications Development (RAD) as their basis.
#3 Of course it is vital to remember that this document, like the system, is always
changing and developing. As the system moves into service so requirements will
emerge from users for further enhancements – they have to be tested and accepted as
the system is upgraded. This may mean that many sections in this specification
change, sometimes to take out tests that are unnecessary as the software in question
has not been altered in the new build of the system.
/1 This document should be read by Project Managers, team personnel engaged in
planning system testing and the EU project team to ensure that the right level of
testing has been specified depending upon the characterisation of the system.

1.2 SCOPE OF TESTING

#1 This section should summarise the system features to be tested. The scale of the
testing will depend upon many things about the characteristics of the system. For
example, in a simple thin-client configuration the scale of the testing at the front end
of the system might be quite simple and straightforward. However, the system may
need to be subjected to detailed load tests to ensure that the server component can
withstand the load placed on it.
#2 Testing may also need to vary depending upon the implementation language involved
in the systems development. For example, where Java may be used it could be
important to undertake specific tests on the run-time environment- or Java Virtual
Machine (JVM) – into which the Java software will be loaded, compiled and
executed. Some JVM have a self optimisation capability that enables the software to
learn from the first time it is run and be faster on subsequent invocations – it is
reported that it is possible to be up to 25% faster on a second run of the executable
software. In any time-sensitive systems this could prove to be important.
#3 Security might be an issue for some IDA projects. Whilst statistics may be of little
concern to criminals operating across Europe and out into the international stage,
information on the movement of goods may well attract attention and be subject to
attempts to delete for example information on a particular shipment as it contains
illegal substances. For these types of systems there should be a greater emphasis on
security and formal penetration testing looking for weaknesses in the system. This is
an aspect of testing that may require specialist assistance and should be considered
early on in the project planning stages.
#4 If the system simply supports the transmission, say once a week, of a simple
spreadsheet full of statistics into Luxembourg and this can be done via email over a
weekend then the scale of testing required will be considerably less. The scope of
testing may require, for example, tests to be carried out over several weeks to ensure
the system is reliable and operates as required.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

#1 This section should define all terms, acronyms and abbreviations used in this
document. The following is a list of definitions for this template:

Unit testing Verification that each unit, e.g. module, subroutine

meets the design. It should test every path and every line
in each module. This is not addressed within this
document as it is felt that suppliers will have their own
approach to unit level testing in accordance with their
own QA systems
Acceptance testing Validation that the system meets the user requirements
Integration testing Verification that the units can be correctly integrated
into sub-systems
Release number If the delivery is to be incremental then each delivery
needs to be uniquely identified and the tests can then be
allocated for each delivery
Security Model The way in which the system provides security from
internal or external unauthorised use
System testing Verification that the system works successfully and
meets the system/software requirements

1.4 REFERENCES

#1 This section should provide a complete list of all the applicable and reference
documents, identified by title, author and date. Each document should be marked as
applicable or reference. If appropriate, report number, journal name and publishing
organisation should be included.

1.5 OVERVIEW

/1 Section 1 is the introduction and includes a description of the project, applicable and
reference documents.
/2 Section 2 describes the test planning.
/3 Section 3 contains the test designs.
/4 Section 4 describes the test cases.
/5 Section 5 contains the test procedures.
/6 Section 6 describes the test reports.
2 TEST PLANNING

#1 Testing needs to be planned. The Review and Test Management Plan document
describes the global approach to testing, but this section will provide detail for the
tests themselves.
#2 In planning tests a wide range of factors have to be taken into consideration. These
may include:
 Performance requirements that emerge from the system specification, where
response times or latency (delays) in the system delivering messages matter for
example.
 Investigations of the system under low-loading conditions, such as when a single
user is logged onto the system and if appropriate where larger numbers of users
are using it in parallel.
 The architecture of the system and any security implications that may arise or
need to be addressed. For example a two tier-thin client architecture will require
a different range of testing to a fat client two-tier system or a three-tier
architecture. Moreover security testing should address firewalls, operating
system vulnerabilities and system administration controls.
 The distributed nature of the system and how test data might be made available
to simulate ‘live’ data being passed over the network.

2.1 TEST ITEMS

#1 This section should identify the test items, such as test data, test rigs (hardware &
software), test harnesses and any reporting tools looking at the results of the testing. 2
#2 Particular consideration should be given to the need to carry out tests on the Security
Model that underpins access controls to the system if they are required. This may
require obtaining external assistance to devise what are often referred to as
Penetration Tests – in effect ways of trying to enter the system illegally. This may
require obtaining specialist software tools to enable testing of passwords and system
administration and firewall controls.
#3 References to other software documents, e.g. the Technical Design document, should
be supplied to provide information about what the test items are supposed to do, how
they work, and how they are operated. It is recommended that test items should be
grouped according to release number if the delivery is to be incremental.

2.2 FEATURES TO BE TESTED

#1 This section should identify all the features and combinations of features that are to
be tested. This may be done by referencing sections of requirements or technical
design documents.

2
This is important, as it may be necessary to plan ahead in this area to give time to develop
some bespoke software to support detailed testing. This would need to be done as it may be difficult
to move the system directly from development into the live environment without what is in effect
some factory acceptance rather than in-situ acceptance testing.
#2 References should be precise yet economical, e.g.:
 'the acceptance tests will cover all requirements in the User Requirement
Document except those identified in Section 2.4';
 'the unit tests will cover all modules specified in the Technical Design Document
except those modules listed in Section 2.4'.
#3 Features should be grouped according to release number if delivery is to be
incremental.

2.3 FEATURES NOT TO BE TESTED

#1 This section should identify all the features and significant combinations of features
that are not to be tested and explain why. If it is not possible to test some features at
their most appropriate level of testing but which will be tested at a later level, this
information should be included here. An example is where volume testing cannot be
tested as part of System testing, but will be tested as part of the Acceptance testing as
only the User’s system will have sufficient data to test.

2.4 APPROACH

#1 This section should specify the major activities, methods (e.g. structured testing) and
tools that are to be used to test the designated groups of features.
#2 For example, this section will have to address whether or not a test environment
needs to be created to simulate a heavy loading on a central server when it might be
under high utilisation. This may require developing or purchasing some software that
would simulate the client side interactions3 of a user or it may require this to be
developed internally within the project.
#3 Similarly, the approach taken to testing the security features within the system should
also be considered. Experts acknowledge that people intent on attacking a system will
often try to find it weakest link, this may be through a badly configured firewall, its
underlying operating system, the lack of authentication of users or the controls for
accessing the database.
#4 Activities should be described in sufficient detail to allow identification of the major
testing tasks and estimation of the resources and time needed for the tests. The
coverage required should be specified.

2.5 ITEM PASS/FAIL CRITERIA

#1 This section should specify the criteria to be used to decide whether each test item
has passed or failed testing. Critical functions that must work in the system should be
identified. If any of these fail the system testing must be halted.
#2 It would be useful to introduce a capability to grade failures and then use these to
decide if a number of failures in each category to decide if the system is at all

3
These are often expensive pieces of software that require specialised skills to set them up. It
is recommended that projects consider developing their own relatively simple test harness, but that
they keep in touch with any Horizontal Actions & Measures (HAM) that might see a united approach
being developed to creating test harnesses.
 acceptable. These categories and criteria should be consistent with any agreed
contractual specifications and other higher level documents such as the Review and
Test Management Plan. For example,
 Serious system failures would be deemed a ‘A’ failure. These might also include
the inability of the system to fail in a controlled way – perhaps requiring a re-
boot if a communications line failed etc. Security problems or failure under load
testing might also be considered category ‘A’ failures. A defined number of ‘A’
failures would halt testing.
 ‘B’ failures would be seen to be failures of the system to represent the
functionality requested in the specification.
 Category ‘C’ failures would be those which showed inconsistencies in the
operation of the system in areas such as the GUI displays.
 Category ‘D’ failures might be areas where minor problems exist with the
system.
 Category ‘E’ failures would be ones where the specification might seem to be in
variance with the requirements specification.
#3 It may be that the pass fail criteria would use a set number of these failures. An
example might be:
 5 category ‘A’ failures
 10 category ‘B’ failures
 20 category ‘C’ failures
 40 category ‘D’ failures
 50 category ‘E’ failures
#4 This might be an acceptance profile that would allow a system to be partially
accepted through a first round of testing. This section should address the implications
of load tests etc. If the system has to have security features then this section should
also address what constitutes failure in this area.

2.6 SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS

#1 This section should specify the criteria used to suspend all, or a part of, the testing
activities on the test items associated with the plan. The typical profile outlined in the
last section could be used to decide if the system is acceptable or not. This section
should specify the testing activities that must be repeated when testing is resumed.

2.7 TEST DELIVERABLES

#1 This section should identify the items that must be delivered before testing begins,
which should include:
 test plan;
 test designs;
 test cases;
 test procedures;
  test input data & test environment;
 test tools, both proprietary and test reference tools.
#2 The use of tools from other IDA and OSN projects should be considered here,
including Horizontal Actions and Measures and similar projects in other sectors; for
instance, Test Reference Tools that simulate the other end of an information
exchange in a specified-manner.
#3 This section should identify the items that must be delivered when testing is finished,
which should include:
 test reports;
 test output data;
 problem reports.

2.8 TESTING TASKS

#1 This section should identify the set of tasks necessary to prepare for and perform
testing. This will include getting test data and setting up any communications links
and preparing any systems that will be linked up for the testing activities. This will
have to take account of the approach being taken to building the system, such as
waterfall etc. This section should also identify all inter-task dependencies and any
special skills required. It is recommended that testing tasks should be grouped
according to release number if delivery is to be incremental.

2.9 ENVIRONMENTAL NEEDS

#1 The test environment will have to reflect the approach being taken to building the
system. The environment will be different depending upon whether or not the
development is being carried out under waterfall, ‘V’ model or RAD. This section
should specify both the necessary and desired properties of the test environment,
including:
 physical characteristics of the facilities including hardware;
 communications software;
 system software, such as operating system;
 browser & server software where this is appropriate;
 any special software such as a Java Virtual Machine (JVM)
 mode of use (i.e. standalone, networked);
 security software, such as PKI;
 test tools;
 geographic distribution where appropriate.
#2 Environmental needs should be grouped according to release number if delivery is to
be incremental.
2.10 RESPONSIBILITIES

#1 This section should identify the groups responsible for managing, designing,
preparing, executing, witnessing, and checking tests. Groups may include developers,
operations staff, user representatives, technical support staff, data administration
staff, independent verification and validation personnel and quality assurance staff.
#2 The involvement of different “players” should be considered:
 Commission Services and EU Agencies, including the output of related
programmes
 Member State Administrations
 Contractors

2.11 STAFFING AND TRAINING NEEDS

#1 This section should specify staffing and staff training requirements.

#2 Identify training options for providing necessary skills to be able to perform the tests
at the level required for the project. This may mean, for example, providing
 some basic end-user training in the operation of the system, or
 an operating system, Systems Administrators course to enable the test team to
configure the operating system correctly for the test to be carried out, or
 if testing of security features is required, some form of penetration testing course.

2.12 SCHEDULE

#1 This section should include test milestones identified in the software project schedule
and all item delivery events, for example:
 delivery of the test harness and any test data required to create the test
environment
 programmer delivers software for integration testing;
 developers deliver system for independent verification.
#2 This section should specify:
 any additional test milestones and state the time required for each testing task;
 the schedule for each testing task and test milestone;
 the period of use for all test resources (e.g. facilities, tools, staff).
#3 This section should also address the implications of failing to meet the schedule as
resources may have been redeployed or vital test equipment may no longer be
available. Contingencies should also be planned into the timetable where it is
appropriate.
2.13 RISKS AND CONTINGENCIES

#1 This section should identify the high-risk assumptions of the test plan. It should
specify contingency plans for each. Risks may include technological, geographical or
political issues. This section will also describe what should take place if one of the
risks occurs; in other words what is the contingency and what impact would it have
on the testing etc.?
3 TEST DESIGNS

#1 A test design shows how a requirement or subsystem is to be tested. Each design will
result in one or more test cases. The ‘design’ of a test is a vital aspect of getting tests
set out correctly to verify the system4.
#2 A particular input to test design will be to look at which approach to the development
of the system was taken c.f. waterfall, the so-called ‘V’ approach and RAD or any
other accepted approach. In a classic waterfall design the test designs will be
different from those involved in a RAD development. Systems test designs should
specify the test approach for each requirement in the System/Software Requirement
document. In the case where the ‘V’ approach is used it is important to calibrate the
test designs at each stage in the process. System Acceptance test designs should
specify the test approach for each requirement in the User Requirement document.

3.1 TEST DESIGN IDENTIFIER

#1 The title of this section should specify the test design uniquely. The content of this
section should briefly describe the test design and its intended purpose. Key inputs
should also be identified, as should external dependencies.

3.1.1 Features to be tested

#1 This section should identify the test items and describe the features, and combinations
of features, that are to be tested. For each feature or feature combination, a reference
to its associated requirements in the user requirement or system/software requirement
or technical design documents should be included.
#2 Whilst it is essential to test what is often referred to as the required operation of the
system, it is also vital to ensure that the system is also tested under what can be
thought of as non-nominal situations, such as when the communications line fails or
when there is a problem with the database etc. This is often when a systems
performance can become erratic and create difficulties for users, who may not all be
highly IT literate. In this case the operation of the system in explaining what
problems have arisen and how the user should respond are crucial to the operational
use of the system.
#3 If the testing that is to be carried out is ‘under loaded’ conditions it will be vital to
specify a design that truly simulates a loaded system. It will be vital to have a
representative set of queries being executed on the system in parallel. For example,
the test design team may have the option to write a single, repeating test that looks at
the most difficult search on the system, such as trying to find an item in a database,
or they might write a test script that sees this query being one of many that are input
to the system in parallel.

4
One facet of this would be to look at areas of the testing where a specific aspect of the
overall performance needs to be tested. In client-server systems it may be that solutions may be based
upon a range of technologies, such as Java. It may be that test designs have to reflect this by also
addressing testing the performance of any Java Virtual Machine as this may impact the response time
of the system from the user aspect. Moreover there may be other areas of the system that may require
equal testing to ensure that no unnecessary overheads are being added in that might be reducing the
possible performance of the system.
3.1.2 Approach refinements
#1 This section should describe the results of the application of the methods described in
the approach section of the test plan. It will need to take account of whether or not
the testing will be carried out under a waterfall, ‘V’ or RAD development approach.
#2 Specifically it may define the:
 component integration sequence (for integration testing);
 paths through the control flow (for integration testing);
 types of test (e.g. white-box, black-box, performance, stress etc).
#3 The description should provide the rationale for test-case selection and the packaging
of test cases into procedures. The method for analysing test results should be
identified e.g. compare with expected output, compare with old results, proof of
consistency etc. The tools required to support testing should also be identified.

3.1.3 Test case identification

#1 This section should list the test cases associated with the design and summarise what
is intended to be derived from these test cases.

3.1.4 Feature pass/fail criteria

#1 This section should specify the criteria to be used to decide whether the feature or
feature combination has passed or failed. This should be based upon the failure
category model suggested earlier in this document.
4 TEST CASE SPECIFICATION

#1 Test cases specify the inputs, predicted results and execution conditions. Each test
case should aim to evaluate the operation of a key element or function of the system.
#2 Failure of a test case, depending upon the severity of the failure, would be
catalogued as part of the overall evaluation of the suitability of the system as a whole
for its intended use.
#3 Test cases can start with a specific ‘form’ that allows operator entry of data into the
system. This needs to be mapped, if the architecture is based upon an n-tier solution,
through the business logic and rules into the server systems with transactions being
evaluated both in a ‘nominal’ mode where the transaction is a success and for those
occasions when the transaction or ‘thread’ fails. Test design may also require one
or more test cases and one or more test cases may be executed by a test procedure.

4.1 TEST CASE IDENTIFIER

#1 The title of this section should specify the test case uniquely. The content of this
section should briefly describe the test case and the objectives of the test case. It
should also identify the functions within the system that the test case will evaluate –
both in terms of a successful operation and where errors occur.

4.1.1 Test items

#1 This section should identify the test items. References to other documents should be
supplied to help understand the purpose of the test items, how they work and how
they are operated. The test items may be:
 input data & information that is suitable for the test
 the execution environment
 the software ‘build’ of the component or subsystem under test
 configuration of the operating system
 configuration of any hardware, such as communications systems, that would be
evaluated in the test.

4.1.2 Input specifications

#1 This section should specify the inputs required to execute the test case. File names,
parameter values and user responses are possible types of input specification. This
section should not duplicate information held elsewhere (e.g. in test data files). This
can be a very important area of the test specification if the system is to be tested
‘under load’. In this instance the input specifications may have to describe how the
software that will mimic the human operator will be set up.
#2 For example, if the test case is to simulate the system working with 20 users
operating in parallel then the transactions for each of the twenty operators will need
to be defined. Moreover some form of randomisation of the transactions being started
and completed will be required. So it may be necessary to specify the range of what is
often referred to as ‘thinking time’ that may be used by an operator. Typically this
 may range from 2 to 20 seconds. Using contemporary testing software it is possible to
create a synthetic environment in which 20 apparent users are using the system in
parallel and to use the randomisation algorithm to vary the rate at which each user
appears to initiate a search or action on the system.

4.1.3 Output specifications

#1 This section should specify the outputs expected from executing the test case relevant
to deciding upon pass or failure. For example, in testing ‘under load’ it will be
important to measure the response time of the system to a specific query or range of
queries that are felt to provide a representative load on the system. If the issue is to
measure the length of time it takes for a message to be transmitted from source to
destination then other measurements of the system performance will have to be taken
into consideration.
#2 File names and system messages are possible types of output specification.
#3 This section should not duplicate information held elsewhere (e.g. in log files).

4.1.4 Environmental needs

#1 These are the pre-conditions for the testing. It can cover how the test environment is
set up, what configuration is required for the system etc.

Hardware
#1 This should specify the characteristics and configurations of the hardware required to
execute this test case. If the system will be required to run on several platforms, there
should be test cases for each one, until it can be shown that the results will be the
same whatever the platform. An example would be where a standard-compliant Java
Virtual Machine is to be used on all platforms.

Software
#1 This should specify the system and application software required to execute this test
case. This should be defined in terms of a build file that contains the subsystem or
system that is to be tested under configuration control.

Other
#1 This should specify any other requirements such as special equipment or specially
trained personnel in an area such as testing security related to the integrity of the
system.

4.1.5 Special procedural requirements

#1 This section should describe any special constraints on the test procedures that
execute this test case. For example, these may include organisational arrangements
where multi-national or multi-organisational testing may involve special
arrangements such as interchange agreements between project participants.

4.1.6 Inter-case dependencies

#1 This section should list the identifiers of test cases that must be executed before this
test case. The nature of the dependencies should be summarised. This will ensure
that testing does not get out of sync and start to test features of the system that are
downstream of key functions.
5 TEST PROCEDURES

#1 A test procedure describes how to carry out the test cases.

#2 Each test case will have a corresponding test procedure, though a single test
procedure may execute one or more test cases.

5.1 TEST PROCEDURE IDENTIFIER

#1 The title of this section should specify the test procedure uniquely.

5.1.1 Purpose
#1 This section should describe the purpose of this procedure. A reference for each test
case the test procedure uses should be given.

5.1.2 Special requirements

#1 This section should identify any special requirements for the execution of this
procedure. This may include other procedures that have to be performed before this
one, e.g. setting up data, and ones that have to performed after, e.g. producing a
report.
#2 Relevant test data files should be stated.

5.1.3 Procedure steps

#3 This section should include the steps described in the subsections below as
applicable.

Log
#4 This should describe any special methods or formats for logging the results of test
execution, the incidents observed, and any other events pertinent to the test.

Set up
#5 This should describe the sequence of actions necessary to prepare for execution of the
procedure. This may include the setting up of the test reference tool, although where
an identical set-up is used by more than one test procedure, it may be more useful to
create a separate procedure, which would be run before this procedure and be listed
in the Special Requirements section above.

Start
#6 This should describe the actions necessary to begin execution of the procedure.

Actions
#7 This should describe the actions necessary during the execution of the procedure. It
should also include the specific data to be input and the expected results.
#8 This is especially important where the user interface is being testing, e.g. for HTML
and web-based applications, where data must be entered on the screen and the result
cannot be seen in a log file. Consideration should be given to the use of screen prints.
#9 It may be useful to use a table like this:

Step Action (including input data) Expected results

No
1 On Login screen, input user name and password. Click Succesful login
on OK

Shut down
#10 This should describe the actions necessary to suspend testing when interruption is
forced by unscheduled events.

Restart
#11 This should identify any procedural restart points and describe the actions necessary
to restart the procedure at each of these points.

Stop
#12 This should describe the actions necessary to bring execution to an orderly halt.

Wrap up
#13 This should describe the actions necessary to terminate testing.

Contingencies
#14 This should describe the actions necessary to deal with anomalous events that may
occur during execution. These may include where the expected results do not occur
and a problem report has to be raised. This section should describe whether the test
can simply be repeated or whether data would have to reset before the test can be re-
run.
6 TEST REPORTS

#1 This section may be extracted and produced as a separate document, to allow the
descriptions of the testing to be finalised and the test specification document issued
before the testing begins.
#2 The detail in each test report will depend upon the level of testing - e.g. subsystem,
system, and acceptance. For example, for unit testing, each test report may cover a
whole day’s testing; for acceptance testing each test procedure may have its own test
report section.

6.1 TEST REPORT IDENTIFIER

#1 The title of this section should specify the test report uniquely.

6.1.1 Description
#1 This section should identify the items being tested including their version numbers.
The attributes of the environment in which testing was conducted should be
identified.

6.1.2 Activity and event entries

#1 This section should define the start and end time of each activity or event.
#2 One or more of the descriptions in the following subsections should be included.

Execution description
#3 This section should identify the test procedure(s) being executed. All the people
involved and their roles should be identified, including those who witnessed each
event.

Procedure results
#4 For each execution, this should record the visually observable results (e.g. error
messages generated, aborts and requests for operator action). The location of any
output, and the result of the test, should be recorded.
#5 It may prove easiest to use the table as described in the test procedure section above
with an extra column showing if the expected results were achieved. It may also be
better to include the actual sheets used during the test as part of the test report, either
scanned in or physically included although the latter would mean that the report
would have to be in hardcopy.

Environmental information
#6 This should record any environmental conditions specific for this entry, particularly
deviations from the nominal.
DOCUMENT CONTROL
Title: Test Specification
Issue: Issue 1
Date:
Author:
Distribution:
Reference:
Filename:
Control: Reissue as complete document only

DOCUMENT SIGNOFF
Nature of Signoff Person Signature Date Role

Authors

Reviewers

DOCUMENT CHANGE RECORD

Date Version Author Change Details