Criteria

Criteria define the specific conditions that must be met for a Task Item to be considered complete. They provide clear, measurable, and unambiguous definitions of "done" that all stakeholders can agree upon.

Overview

Criteria in Test & Accept always belong to specific Task Items and define precisely when those items are considered complete. They serve as the contractual definition of "done" for each task item.

Criteria:

• Provide binary pass/fail conditions for task items
• Eliminate subjective interpretation of completeness
• Form the foundation for test development
• Create clear contractual definitions of "done"
• Facilitate alignment between all stakeholders

Well-crafted criteria are essential for successful project delivery as they provide absolute clarity on expectations and are the basis for verification through testing.

The Criterion Model

Creating Criteria

Via the UI

1. Navigate to a Task Item
2. Click "Add Criterion"
3. Write a clear criterion statement using the recommended format
4. Click "Save Criterion"

Via the API

// Create a new criterion
const newCriterion = await apiClient.criteria.create({
  taskItemId: "task_item_id",
  description: "Given a user with valid credentials, when they attempt to log in, then they are successfully authenticated and redirected to the dashboard.",
  status: "pending"
});

Writing Effective Criteria

Criteria should be:

1. Binary: Each criterion must have only two possible outcomes — pass or fail
2. Specific: Clearly define the exact condition to be met
3. Measurable: Include concrete details that can be objectively verified
4. Unambiguous: Leave no room for interpretation or subjective judgment

Recommended Formats

Test & Accept supports two primary formats for criteria:

1. Given-When-Then Format

This format follows the Behavior-Driven Development (BDD) approach:

Given [context]
When [action]
Then [expected result]

Example:

Given a user with admin privileges
When they access the user management page
Then they can view, edit, and delete all user accounts

2. "It can be confirmed that" Format

This format is more direct and suitable for simpler conditions:

It can be confirmed that [expected condition]

Example:

It can be confirmed that the system automatically locks a user account after 5 failed login attempts

Managing Criteria Status

Criteria have three possible statuses:

• Pending: The criterion has been defined but not yet tested
• Pass: The criterion has been tested and satisfied
• Fail: The criterion has been tested and not satisfied

To update a criterion's status:

// Update criterion status
await apiClient.criteria.updateStatus(
  "criterion_id",
  "pass"
);

Relationship to Tests

Each criterion has a one-to-one relationship with a test. This means:

• Every criterion must have exactly one test that verifies it
• Every test verifies exactly one criterion
• The test provides the procedure to prove the criterion is met

Viewing Tests for a Criterion

Tests associated with each criterion are displayed directly in the SOW structured view, showing:

• Test name and status
• Quick links to view or edit test details
• Overall verification status for the criterion

Creating Tests for Criteria

Tests can be created through:

1. The UI by clicking "Add Test" on any criterion
2. The API using the /api/v2/tests endpoint

See the Tests documentation for complete details on managing tests.

Best Practices

• One Condition Per Criterion: Each criterion should test exactly one condition
• Complete Coverage: Ensure all aspects of a task item have criteria
• No Implementation Details: Focus on outcomes, not how they're achieved
• Concise Language: Be direct and specific in your wording
• Collaboration: Develop criteria with stakeholders to ensure alignment
• Early Definition: Define criteria before development begins
• Consistent Format: Use a consistent format across all criteria

Common Pitfalls to Avoid

❌ Ambiguous Criteria

Bad: "The system should be fast" Good: "It can be confirmed that the login page loads in under 2 seconds on a standard broadband connection"

❌ Multiple Conditions

Bad: "The user can log in and view their profile and update their settings" Good: Split into three separate criteria:

• "Given valid credentials, when a user logs in, then they are authenticated"
• "It can be confirmed that authenticated users can view their profile"
• "It can be confirmed that authenticated users can update their settings"

❌ Implementation-Specific

Bad: "The system uses PostgreSQL to store user data" Good: "It can be confirmed that user data persists between sessions"

API Reference

For complete API details, refer to the API Reference.