Artifact: Test-Ideas List

	An enumerated list of ideas, often partially formed, that identify potentially useful tests to conduct.
Role:	Test Analyst
Optionality/Occurrence:	Recommended, usually defined as multiple artifacts. When used informally; the artifact is treated as transitory-it has no persistence.
Templates and Reports:
Examples:
UML Representation:	Not applicable.
More Information:	Guideline: Equivalence Class Analysis Concept: Test-Ideas Catalog Guideline: Test Ideas for Booleans and Boundaries Guideline: Test Ideas for Method Calls Guideline: Test Ideas for Statechart and Flow Diagrams Concept: Test-Ideas List

Purpose Brief Outline Properties Timing Responsibility Tailoring

Input to Activities:  Define Test Details Determine Test Results Identify Test Ideas Implement Test

Output from Activities:  Identify Test Ideas

Purpose

The Test-Ideas List provides a layer of abstraction between the conceptual Test Plan and the more detailed Test Case or the concrete Test Script. It is used to capture initial ideas for potential tests-often ill-formed or partial ideas-so that the tests can be reasoned about. This artifact is particularly useful earlier in the development cycle or when supporting project artifacts are unavailable or incomplete.

Brief Outline

Each Test-Ideas List should be identified by considering as many different perspectives as possible, including many of the following:

• Have all relevant test-idea catalogs been reviewed?
• Are there any quality risks not represented on the list?
• Are there any relevant fault models not represented on the list?
• Have you considered the use of all possible attacks?
• Have you considered one or more relevant soap operas?
• Are there any other ideas that strike you as worth considering?
• What is the relative importance of each idea in the list?

One you have an initial list of ideas, consider whether there any related ideas on the list that could be combined or consolidated. As a general heuristic, most lists should contain seven entries, plus or minus two. For more detail on the contents of a Test-Ideas List, see the guidelines listed under the More Information section of the header table.

Properties

There are no UML representations for these properties.

Timing

You should begin identifying lists of Test Ideas as soon as the Evaluation Mission for the current iteration is determined. Although you may want to record some of your Test Ideas earlier, be careful not to invest too much time before you have agreement on the Evaluation Mission. In most cases, this activity will start in the first iteration in the Elaboration phase, and will continue until the end of the project. Don't become complacent about the need to identify new Test Ideas; the potential for new defects and unexpected quality gaps to exist is present as long as the software is undergoing change.

Responsibility

The Test Analyst role is primarily responsible for this artifact. Those responsibilities include:

• Identifying each Test Idea, and approving subsequent changes to it.
• Ensuring that changes are communicated to affected downstream roles.
• Ensuring that sufficient Test Ideas have been identified to provide satisfactory evaluation of the Target Test Items.
• Managing and maintaining appropriate traceability relationships.
• Managing the appropriate scope of the Test Ideas in a given iteration.

Tailoring

In certain domains and testing cultures, Test Ideas are either not recognized, or are considered informal artifacts. As such, both the contents and format of Test-Ideas List may require modification to meet the needs of each specific organization and project.

When they are recorded (either formally or informally), two main styles are commonly used:

• The first is a standard text document structure using a format similar to that outlined above. Usually multiple Test Ideas are to be presented together, whereas a single Test Idea by itself is usually not considered to represent a sufficient list.
  
• The second uses some form of table or database. Test Ideas are specified, one per row with columns provided to facilitate sorting and filtering by different criteria. Test matrices or cause and effect tables can be considered alternative forms of Test-Ideas List.

Some consideration should also be given to ongoing measurement of the Test Ideas for progress, effectiveness, change management and so forth. Consider using specification-based test coverage, in which each Test Idea or Test-Ideas List traces back to at least one specification entry to be tested. For example, trace to the requirements specification elements to be tested which will typically reflect some subset of the total product requirements (see Concepts: Key Measures of Testing).

Optionally the Test-Ideas can be retained as part of a Test Case or Test Script. The list may also be referenced from-or in smaller test efforts, included within-the Iteration Test Plan.

Rational Unified Process