Jinn for QA engineers

This page sets Jinn up for QA work: you’ll know what changed in every meeting, including the ones you weren’t on, and what needs testing because of it. Once it’s set up, you get:

• A retest list after every planning call, including the calls you weren’t on — what changed, what it touches, what to test again (step 3)
• Expected behaviour in one question, with a link to the spec or the meeting where it was decided, instead of reading three docs and a transcript (step 5)
• The earlier report in seconds, when you’re sure someone raised this bug before (step 6)

Steps 1–2 you do once. Steps 3–6 are what you do every week.

1. Get into your team’s project

Everything below happens inside a project: the one where your team’s planning calls and specs land.

1. Ask whoever has Full access on that project to add you.
2. Ask for Can edit access rights. Can view is enough to read, but adding an agent to a meeting, tagging a passage and creating a doc all need edit rights.

2. Put the spec in the project

The chat answers from what’s in the project, so the spec has to be there too.

1. Click Add in the left sidebar, then New doc in project, and pick the project.
2. Write the spec, or bring in one you already have: open the doc’s ⋯ menu and choose Import from Markdown or Import from HTML. The file can be up to 1 MB.
3. Type @ to link the docs the spec depends on.

See writing a doc.

3. Get the retest list after a meeting

Every recorded meeting gets a write-up from AI agents — each one reads the meeting through a particular role. One of them, Default, is built into every project and writes a summary and the action items on its own, without anyone asking. For the retest list you need a different agent, QA Engineer. It reads the same meeting the way a tester would: risks, edge cases, claims nobody has checked. Unlike Default, it starts only when you ask, so after any call that changes scope:

1. Open the project and go to Recordings.
2. Open the meeting.
3. Click Add agent at the end of the row of agents, and pick QA Engineer.
4. Read its write-up: what changed, what it touches, and what to test again.

The write-up stays on the meeting, so the developer who opens it tomorrow sees your list too. If QA Engineer isn’t in the list, it isn’t on this project yet. Ask the person with Full access on the project to add it; if the workspace doesn’t have it at all, a workspace admin creates it first. If a point is wrong, fix it in place — what you write is what everyone reads from then on. To move the list into your tracker, click Copy above the write-up and paste. There’s no automatic hand-off to a tracker. See reviewing a meeting.

4. Mark the passages you’ll test against

A tag on a passage marks the moment the acceptance conditions were agreed, so you don’t hunt for it before the next regression run.

1. In the recording, open the transcript and select the passage.
2. Choose Add tag.
3. Type a tag in Find or create a tag… — checkout, release 2.4 — or pick one that exists.

Everything tagged in a recording is on its Tags tab, and the tag works as a filter in search.

5. Check how a feature should behave

Instead of reading three specs and an hour of transcript:

1. Open the project and click Chat. The chat starts on that project.
2. Optional: in the menu that adds sources, pick QA Engineer. It shows as a chip, Agent: and its name, and answers come back with the risks next to the rule.
3. Ask in plain words.
   For example: What should happen when a refund is smaller than the original payment? Show me where it was decided.
4. Before you write the test case, open the link under the answer. If it came from an old draft, you’ll see it in a click.

See asking a question.

6. Find an earlier report

When you’re sure someone reported this before:

1. Press ⌘K from anywhere.
2. Type what the problem looks like, in your own words. Search finds a passage by what was said, not only by the exact words.
3. If your team tags passages, narrow the search to the tag.

Results come back grouped into docs, recordings, agents, projects and tags. See search.

Where to go next