> For the complete documentation index, see [llms.txt](https://docs.crobox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.crobox.com/how-to-guides/sagent/qa.md).

# QA

Test how Sagent answers shoppers before you publish changes.

The **QA** tab helps you check that Sagent answers shoppers the way you expect, every time you adjust Sagent configuration. You turn real shopper messages into tests, decide what a good answer looks like, and run those tests before your changes reach shoppers.

QA has two sub-tabs:

* [**Tests**](/how-to-guides/sagent/qa/tests.md) is where you create, import, export, and manage your tests.
* [**Results**](/how-to-guides/sagent/qa/results.md) is where you review each run and see how Sagent answered.

### How QA works

A **test** is a shopper message plus one or more **checks**. When you run your tests, Sagent answers each enabled test message, and each check decides whether that answer is good. A test passes only when every one of its checks passes.

Every run also includes **Crobox system checks**. These are tests Crobox maintains for every Sagent. They appear in your runs and results, but you can't edit them.

You can start two kinds of run from either sub-tab:

| Run                        | What it does                                                                                                                                              | Typical duration       |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| **Run tests**              | Sends each enabled test, plus the Crobox system checks, to the version you're editing and checks Sagent's answers.                                        | A few minutes          |
| **Run AI Generated Tests** | Creates around 180 test messages that try to push Sagent off topic, into unsafe answers, or into revealing its instructions, then checks how it responds. | About 15 to 20 minutes |

### Use QA before every release

{% stepper %}
{% step %}

#### Build your tests

Cover the shopper journeys that matter most to your business, such as vague requests, specific recommendations, and budget questions. Add tests for things Sagent should never do, like mentioning competitors or sharing discount codes.
{% endstep %}

{% step %}

#### Run your tests

Click **Run tests**. You can leave the page while the run is in progress. Results appear in **Results**.
{% endstep %}

{% step %}

#### Review and fix failures

Open the run to see each shopper message, Sagent's answer, and why each check passed or failed. Update your Setup or Data settings, or adjust the test if it no longer reflects what you want, then run your tests again.
{% endstep %}

{% step %}

#### Publish

When your results look right, publish the version from [**Versions**](/how-to-guides/sagent/versions.md).
{% endstep %}
{% endstepper %}

{% hint style="info" %}
When your setup or tests change after a run, QA shows a banner: **Your setup or tests changed since the last run. Run tests again before publishing.** The latest result is also marked **Outdated** until you run your tests again.
{% endhint %}

### The publish check

When you publish a version, Sagent reminds you if:

* this Sagent hasn't been tested yet;
* your setup or tests have changed since the last run, including tests you added, edited, switched on or off, or deleted;
* the last test run had failures.

The publish check is a warning, not a block. You can still publish, but we recommend running your tests and reviewing any failures first.

{% hint style="warning" %}
Passing an earlier run doesn't cover later changes. A change to your catalog, behavior settings, knowledge, guidance, or translations can change how Sagent answers, so run your tests again after each change you plan to publish.
{% endhint %}

### Share QA evidence with your team

QA results are a useful record for legal, security, and business reviews. You can [export your tests](/how-to-guides/sagent/qa/tests.md#import-and-export-tests) as a CSV file and [download the results of any run](/how-to-guides/sagent/qa/results.md#download-results) to share how Sagent answered each test and why each check passed or failed.

### Frequently asked questions

<details>

<summary>Who can use QA?</summary>

Anyone with access to Sagent can create, edit, import, export, and run tests, including AI Generated Tests. Crobox system checks are managed by Crobox and are read-only.

</details>

<details>

<summary>Does a failed test stop me from publishing?</summary>

No. The publish check warns you about failures and untested changes, but the decision to publish is yours.

</details>

<details>

<summary>Which version do my tests run against?</summary>

Tests run against the version you're editing. Each run shows its version in **Results**, for example **v10 (published)** or **v11 (editing)**.

</details>

<details>

<summary>What's the difference between my tests and AI Generated Tests?</summary>

Your tests check the shopper journeys and rules you define, and you can rerun them after every change. AI Generated Tests create a fresh set of challenging messages to probe Sagent's safety and boundaries. Use your tests on every release, and AI Generated Tests after larger changes.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.crobox.com/how-to-guides/sagent/qa.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
