--- title: Record test coverage with tzTrack description: Have your AI record what a test session tried, the setup it used, and what to test next. slug: /guides/record-test-coverage order: 10 visibility: public redirects_from: [] --- # Record test coverage with tzTrack > Test the sign-in and password reset flows from our current test plan. Use tzTrack space . Record the setup and what worked, failed, was blocked, or wasn’t tried. File findings separately and give me the task and issue references. Use one ordinary tzTrack task for a test session with one setup. A successful test belongs in the task even when there is no defect to file. Use the task to see what has been tried and where to start the next session. ## What your AI tool does Your AI finds earlier coverage, records the setup and results, and files findings separately. It gives you the task reference and tells you what remains to test. ## What you need Use a signed-in [Turn Zero connection](/tztrack/getting-started/set-up/) and the test plan or scenario list. ## Before your AI starts Take the space ID from the project’s [setting file](/tztrack/reference/the-setting-file/) or from the person’s approved selection. If you only have a name, call `tztrack_list_spaces` to find its ID. Ask the person to resolve any ambiguity. Pass that ID as `space` on every issue call. - `report` access can file ordinary findings and read the issues it can see. Ask someone with `owner` access to create the task and someone with `contribute` or `owner` access to record results. - `contribute` access can update or comment on an existing coverage task. Ask someone with `owner` access to open a new coverage task or close a finished one. - `owner` access can create, update, and close coverage tasks. See [Sharing a space](/tztrack/concepts/sharing-a-space/) for the three levels. If you’re unsure of your access level in a shared space, ask its owner. If the space is inaccessible or nobody can create the task there, ask the person to choose an accessible space or arrange help from its owner. Keep the results in the session until you can save them. ## 1. Find earlier coverage Call `tztrack_find` with `space`, `kind: "task"`, and `label: "coverage"` if the team uses that label. Omit `state` to include completed tasks. If tasks lack the label, search by product or scenario with `query` and `kind`, leaving out `label`. Follow `cursor` for more results. Call `tztrack_read` on likely matches and compare their configuration blocks. Resume an open task only if it covers the same session and setup. If someone else has claimed it, coordinate before changing it. An empty result only tells you what this account could find in this space. ## 2. Record the setup and results To start a task, someone with `owner` access calls `tztrack_raise` with `space`, `kind: "task"`, `title`, and `text`. Use `labels: ["coverage"]` where the team uses that label. Put the configuration block in `text`. Keep results for a changed setup in a separate task so earlier results stay tied to their original setup. Collect the values you can observe. Ask only for relevant details you cannot determine. Mark missing values `unknown` and leave out anything irrelevant. Here is an example of a configuration block and a short result summary. ```text Configuration Test plan = Account flows v2 Product and scenarios = Example app, sign-in and password reset Computer and OS = laptop, macOS 15 AI tool, interface, version, model = Codex desktop, version unknown, model unknown Browser or shell = Safari Access method = browser sign-in Subscriptions = Turn Zero Tools Starting state = signed out, existing test account App type and plan = web app, Pro Environments and actual target = production and development, tested development Worked = sign-in Failed = reset link returned 404, project issue #42 Blocked = email delivery check needs test mailbox access Not tried = reset from a phone ``` Record what happened for each scenario as `worked`, `failed`, `blocked`, or `not tried`. Include useful evidence and any separately filed issue references. Add later observations with `tztrack_comment`. Keep credentials and personal details out of the record. ## 3. File findings separately Use `tztrack_raise` for project defects. For problems with Turn Zero itself, call [`submit_feedback`](https://turnzero.ai/cloud/guides/feedback/) with `source: "agent"` when filing as the AI. The platform feedback tool refuses customer filings of kind `task`. Keep the coverage task in the project’s tzTrack space. Include the relevant setup details and the coverage task’s space and issue number in the finding’s `text` where they are safe to share. Record the returned finding reference on the coverage task. ## 4. Finish the session When the results are recorded, someone with `owner` access calls `tztrack_close` on the coverage task with `outcome: "done"` and a `resolution` that summarizes what was tried, what remains, and where the findings are tracked. If the task is still `new`, use `tztrack_update` with `fields: {"kind":"task"}` to open it first. For other states, follow [Closing an issue](/tztrack/reference/the-tools/#closing-an-issue). If you lack `owner` access, leave the summary and give the task reference to someone who can close it. Read back the task with `tztrack_read` to confirm the results and its final state. Give the person the space, task number, and finding references. A closed coverage task means the session ended and its results are recorded. Leave each linked defect open until it is resolved. ## Refusals Common refusals are below; [Refusals](/tztrack/reference/refusals/) lists the rest. | Refusal | Status | Cause | Remedy | | --- | --- | --- | --- | | `grant_required` | 403 | The call needs a higher access level in the shared space, such as an update or comment below `contribute`, or a close below `owner`. | Ask someone with that level to make the change, or ask the space's owner. | | `invalid_request` | 400 | A coverage task was filed below `owner` access, or `label` was passed beside `query`. | Ask someone with `owner` access to create the task. When searching with `query`, leave out `label`. | | `state_conflict` | 409 | The coverage task is still `new`, which does not accept `done`. | Open it with `tztrack_update` and `fields: {"kind":"task"}`, then close it. | ## For AI tools A finding’s report text can carry a reference at any access level. To create an issue relation in the same space, call `tztrack_relate` with the finding as `issue`, the coverage task as `target`, and `type: "relates_to"`. That takes `contribute` or `owner` access. A `report` member can give both references to a contributor who can link them. With `submit_feedback`, you can also copy short setup values into `evidence.context`. Use up to 20 keys that start with a lowercase letter and contain only lowercase letters, digits, or underscores, with short values, such as `test_plan`, `scenario`, `os`, `ai_tool`, and `target`. Use the saved text to compare setups later.