> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jinn.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Jinn for QA engineers

> Know what changed in every meeting, even the ones you missed, and what to retest because of it.

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](#3-get-the-retest-list-after-a-meeting))
* 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](#5-check-how-a-feature-should-behave))
* The earlier report in seconds, when you're sure someone raised this bug before
  ([step 6](#6-find-an-earlier-report))

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](https://docs.jinn.so/projects/manage-projects.md): 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](https://docs.jinn.so/docs/write-a-doc.md).

## 3. Get the retest list after a meeting

Every recorded meeting gets a write-up from AI [agents](https://docs.jinn.so/agents/add-an-agent.md) — 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.

![The agent row under the player on a recording in Jinn: Default, QA Engineer, Product Manager and Add agent](https://mintcdn.com/jinn/48W-8QqP6SyFhGB7/images/meetings/review-a-meeting-agents.png?fit=max\&auto=format\&n=48W-8QqP6SyFhGB7\&q=85\&s=449010bfcc74f71029b1f0930ffad0ab)

One meeting, read by Default, a QA engineer and a product manager

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](https://docs.jinn.so/meetings/review-a-meeting.md).

## 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.

   > [!TIP]
   >
   > 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](https://docs.jinn.so/find/ask-a-question.md).

## 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](https://docs.jinn.so/find/search.md).

## Where to go next

> [card] [Jinn for recruiters](https://docs.jinn.so/for/recruiters.md)
>
> Keep every interview on record and compare candidates on the same terms.

> [card] [Jinn for developers](https://docs.jinn.so/for/developers.md)
>
> Get the decisions from calls you skipped, and the why behind the code.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.