Test Data

Definition

Test data is a testing work product that captures the cohesive information (e.g., data or objects) that exists in the form of a file or database that tests need to execute successfully.

Goals

The goals of a test data include:

• Enable the performance of a test case
• Help developers understand the behavior of the item under test.

Objectives

To support these goals, the objectives of test data include:

• Provide the necessary content of files used during testing
• Provide the necessary content of database used during testing

Benefits

Test data provide the following benefits:

• Automates a single test, thereby supporting regression testing.
• Failure to produce test data means that many tests will not execute successfully.
• The oracle can be incorrect, and the test data developer can make mistakes. Thus, test data needs to be evaluated for defects.

Stakeholders

• Producers:
  • The Architecture Team for software architecture test data.
  • The Software Development Team for unit test data.
  • The Integration Team for integration test data.
  • The Independent Test Team for system test data.
• Evaluator: Test Inspection Team
• Approvers: None.
• Maintainers:
  • The Architecture Team for software architecture unit test data.
  • The Software Development Team for unit test data.
  • The Integration Team for integration test data.
  • The Independent Test Team for system test data.
• Users:
  • The Architecture Team for unit testing of the software architecture prototype.
  • The Software Development Team for unit testing of the software components.
• The Integration Team for performing integration testing.
• The Independent Test Team for performing system testing.

Phases

• Initiation: Optionally Started
• Construction: Completed
• Delivery: Completed
• Usage: Maintained
• Retirement: Archived

Preconditions

Test data can be created if the following preconditions hold:

• The relevant sections of the Project Test Plan is completed.
• The relevant team is staffed.
• The relevant requirements, architecture, or design is completed.
• The relevant item under test is started.
• The relevant test suite is started.

Inputs

• Work products:
  • Project Test Plan
  • System Requirements Specification
  • System Architecture Document
  • Javadoc including responsibilities
  • Software components (e.g., method signatures, assertions, branching and looping logic)
• Stakeholders:
  • None

Guidelines

• Use a combination of testing techniques to ensure adequate test coverage.
• An infinite amount of test cases is often required to exhaustively test any nontrivial work product (e.g., class, software component, or application). Because exhaustive testing typically is impossible or at least impractical, the test data should be the minimum amount that provides adequate coverage is critical.
• Test data will be used at all levels of testing (e.g., model testing, unit testing, integration testing, and system testing).
• To support regression testing, test data will be automated rather than entered manual whenever practical.
• The oracle can be incorrect, and the test case developer can make mistakes. Thus, test cases need to be evaluated for defects.

Conventions

Test data is constrained by the following conventions:

• Inspection Checklist

Examples

• EAS Example Test Data