Record test coverage with tzTrack #

View this page as Markdown

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 and the test plan or scenario list.

Before your AI starts #

Take the space ID from the project’s 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 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.

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 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. 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 lists the rest.

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.