Skip to main content
System StatusContact Support
VersionOne Community

Acceptance Tests

This feature is available in all editions.



An Acceptance Test (also called simply called a "test") is a system asset (typically created during the Product Planning phase) that defines acceptance criteria and behavior of a completed workitem to ensure it works as defined.

Tests can be added to any of the following items: stories, defects, portfolio items, test sets, story templates, and defect templates.

Tests can be tracked in any of the following ways:

  • by Status to view the current status of the test.

  • by Time (or remaining effort estimates) directly against the tests themselves or against tasks.

  • by Results from test execution so a history of all test runs is built.

In Lifecycle, the "tests" and "acceptance tests" are used interchangeably to refer to "acceptance tests". "Regression tests" are called "Regression Tests".

In Agile methodologies, a user story/backlog item is not considered complete until it has passed all acceptance tests (also simply called tests). The product owner will capture acceptance criteria for a backlog item at different times. Generally, acceptance criteria should be captured as soon as it is known. When creating backlog items the product owner may create tests to provide more context for the team as it estimates the backlog item. During sprint planning, the product owner usually discovers and articulates additional acceptance criteria for the backlog item, so additional tests should be added. Finally, as the team implements the backlog item, it may encounter areas of ambiguity that should be clarified with the product owner and potentially recorded as tests.

Once a backlog item is completed and delivered, it should be evaluated to determine which (if any) tests should be added to the Regression Test inventory for use in future regression testing activities. Use the Generate Regression Test action to create a new Regression Test from any of the Acceptance Tests for the backlog item.

Some teams prefer to capture the work required to perform a test within the test instead of creating a separate task. This reduces the number of tasks and tests required for each backlog item, while still recording how much time the team expects a test to require.

Using tests solely for capturing acceptance can also be a good approach. Teams can then create tasks for the type of testing they are doing. A single acceptance test could have multiple testing tasks. A common example is a task for automating an acceptance test and a task for doing exploratory testing around the acceptance test.

Related Topics