|The definition (usually formal) of a collection
of test input values that are consumed during the execution of a test,
and expected results referenced for comparative purposes during the execution
of a test.
||There is no UML representation for this artifact.
||Test Data should be maintained for at least
some portion of the tests, ideally in a central data store.
||One or more data storage containers. In some
cases the Test Data can be enclosed within the Test
Script or the Test Suite artifacts.
Test Data provide both a layer of indirection and a central point of modification
for the unique characteristics of a test. When managed separately from the procedural
aspects of the test, this enables the unique characteristics of the test to
be modified independently.
Each Test-Data set should consider various aspects including the following:
- The required preconditions of the Test Environment Configuration that are
assumed to exist immediately prior to the Test Data being consumed.
- The unique characteristics of the Test Data. These data may range in form;
from standard alphanumeric textual values to sensory data such as auditory
or visual information. Test Data may be specified as a valid rangerather
than a single valuethat should be used during a test.
- Any dependencies between the Test-Data elements.
- A descriptive explanation of the condition being tested, often defined in
terms of what the failure is if the condition being tested is found to be
There are no UML representations for this artifact or its properties.
||A unique name used to identify this Test-Data set as a whole.
||A unique name or identifier for each individual data record,
entry, or combination thereof.
||A short description of the contents of the Test-Data record,
typically giving some indication of scope.
||An explanation of what this Test-Data record represents
and why it is important.
|Dependent Test and Evaluation Items
||Some form of traceability or dependency mapping to specific
elements, such as individual Requirements, Test Cases or Test Scripts
that need to be referenced.
You can normally begin gathering candidate Test Data as early as Inception
phase. At this early stage, it can be useful to store the gathered data in a
unrestricted format that enforces minimal rules. This allows ill-formed Test
Data records to be partially captured. As the lifecycle progressesespecially
as more test staff become involvedit is usually necessary to lock-down
the restrictions thereby enforcing the integrity of the Test Data. By the end
of the Elaboration phase, a broad selection of Test-Data types should exist,
with a handful of representative data-record entries. A larger number of data
records for specific focus areas should also be available; for example, the few key
use cases, usage scenarios, system functions, transactions, and so on.
The Test Analyst role is primarily responsible for this
artifact. The responsibilities are split into two main areas of concern:
The primary set of responsibilities covers the following identification and
- Identifying potential data sources.
- Gathering basic candidate Test Data.
- Verifying the completeness, fitness for purpose and accuracy of the Test
The secondary set of responsibilities covers the following implementation and
- Implementing the appropriate storage of gathered Test Data.
- Implementing the backup and restoration mechanisms to enable effective use
of the Test Data.
Both the contents and format of Test Data may require modification to meet
the needs of each specific organization and project.
When Test Data are managed independently of procedural test concerns, there
are a few different styles of storage used:
- A simple form of ASCII Text file, either special character delimited or
- A basic form of spreadsheet or database system, such as Microsoft Excel
or Microsoft Access.
- Some form of program generated calculation of the Test Data.
- Some form of capture, extraction or conversion of the Test Data from an
- A complex relational (RDBMS) or object (ODBMS) database management system.
Many test teams make use of the same database to manage Test Data as that
used by the software being developed. This often proves advantageous in having
ready access to skilled Database Administrators and Designers who can provide
advice and support to the test team.
As mentioned, it is typical for multiple Test Data elements to be specified
in a single storage container, usually grouped by the general purpose or objective
of the tests.
© 1987 - 2001 Rational Software Corporation