Understand the test data model

The same test case can appear in several plans and be executed many times. Each layer has a different ID and purpose.

Object	What it represents	When you need its ID
Project	A workspace for a team’s test assets	Scope case, plan, member and result requests
Suite	A folder in the case repository	Organize and create repository cases
Test case	The reusable definition of a test	Select a case to include in a plan
Revision	A version of that definition	Read the historical definition used by an execution
Test plan	The set of work prepared for a test cycle	Add cases, configure execution and assign testers
Plan case	A repository case included in a plan	Relate an execution to the case’s place in that plan
Run	A particular execution cycle of a plan	Distinguish a rerun from an earlier cycle
Executed test case	A concrete execution record	Record status, comments and evidence
Build	The software version under test	Connect results to the version that produced them
Release	A planned delivery grouping builds and plans	Inspect readiness and release-level evidence

Follow a case through a workflow

Create a repository case, include its ID in a plan, assign the plan’s cases, and record results against the execution records created for the run.

Do not send a repository case ID where a method expects an execution ID. For example, updateExecutedTestCase updates an existing execution record; it does not create a repository case or add one to a plan.

Revisions preserve history

Update a case through the case methods. Read its revisions when you need to understand what was tested previously. A later edit to the repository case should not be treated as the definition of an older execution.

BDD-managed cases

Cases and suites created by BDD sync expose ownership markers such as is_bdd_managed. Their feature files own the definitions. Update the files and sync again instead of editing those definitions through ordinary case writes.