Test Results Are Not Appearing in QaaS

Almost every case of “my results are not in QaaS” is settled by one thing: what the reporter printed when your test run finished. It writes a line for every outcome, including the ones where it deliberately does nothing, so start there.

Search your test output for [QaaS]. Then find your line below.

Tip

Run your suite from a terminal the first time you set this up. Some CI systems and IDE test panels collapse or hide standard output, and the reporter’s line is the fastest diagnosis you have.

Nothing at all from [QaaS]

If the reporter printed nothing whatsoever, it never ran. Two causes:

1. The reporter package is not referenced by the test project that actually executed. Confirm gdio.qaas.Reporter is a dependency of the assembly your runner loaded, not of a sibling project.
2. Your runner suppressed standard output. Re-run from a terminal to rule this out before changing anything else.

Before 1.3.0 these diagnostics went only to standard error, which many test runners and CI log views hide or route to a separate pane. If you are on an older build, check your runner’s error output as well – the message may be there and simply not shown alongside your test results. From 1.3.0 the reporter writes them to both streams so whichever one your tooling surfaces, you see it.

NOT CONFIGURED - no results were uploaded

[QaaS] NOT CONFIGURED - no results were uploaded. QAAS_API_KEY is not set in this
process's environment.

The reporter is fail-safe by design: with no QAAS_API_KEY it does nothing at all, so it can be left wired into a project permanently without affecting developers who are not uploading. That is the correct behaviour, and it is also the most common reason a run never arrives.

Set QAAS_API_KEY, then re-run. The full instructions for every environment – Windows, macOS, Visual Studio, Rider and VS Code – are in Configuring QaaS Reporter Environment Variables.

Caution

A process inherits its environment when it starts. If you set the variable after opening your IDE, the IDE and every test host it spawns still cannot see it. Restart the IDE, not just the test run. On macOS, an IDE launched from the Dock never reads your shell profile at all, so a variable exported in .zshrc will not reach it.

Configured, but no test results were collected

[QaaS] No captured results to upload - nothing was collected.

Your key is fine and the reporter ran, but the per-test hook never fired, so there was nothing to send. Add the capture attribute at the top level of your test assembly, for example in AssemblyInfo.cs:

[assembly: gdio.qaas.Reporter.Capture]

NUnit only runs hooks declared in the test assembly itself, which is why the package cannot add this for you. See Uploading GameDriver Test Results to QaaS for the full two-line integration.

Upload rejected (401)

[QaaS] Upload rejected (401); saving payload locally.

The key was sent and rejected. It is revoked, mistyped, or from a different environment.

1. Issue a fresh key in QaaS under Settings → API keys.
2. Copy it into your CI secret store, replacing the old value.
3. Re-run.

Your results were not lost. The reporter writes the payload to its fallback directory and prints the path:

[QaaS] Payload saved to '...'; retry later with `qaas upload`.

Note

GameDriver sees rejected keys on our side too, so if a key stops working we may contact you before you notice. That signal only tells us a key was refused – it never reveals the key itself.

Upload rejected (404)

[QaaS] Upload rejected (404); saving payload locally.

Your key worked, but the project you named does not match one in your company. Usually QAAS_PROJECT has a typo, or the project was renamed after you set it up.

Check the slug against the project in QaaS and correct QAAS_PROJECT. If your key is scoped to a single project, you do not need QAAS_PROJECT at all – remove it and let the key decide.

Tip

Your upload was kept. QaaS stores the raw payload before it resolves the project, so a run rejected for a bad slug is recoverable. Fix the slug and re-run, or contact support to have the stored run replayed – you do not need to re-execute the suite.

The upload succeeded but nothing is on the dashboard

The run reached QaaS. Check, in this order:

1. The right company and project are selected. Use the company switcher in the top bar, then confirm the project. A run uploaded under a different project slug lands in that project, not the one you are looking at.
2. The dashboard’s date window. Home and Overview read the most recent snapshot; a run uploaded moments ago appears in Test Results immediately, while the rolled up figures follow the next snapshot.
3. The run id. Search for it in Test Results to confirm which project received it.

Results arrive, but every test is uncategorised

Domain grouping comes from the [Category] attribute on your tests or fixtures. Tests with no category still upload and still count, they simply cannot be grouped into a domain, so per-domain views stay empty.

[Category("Combat")]
public class CombatTests { }

Still stuck

Collect these three things before you contact us, because together they identify the run without any guesswork:

• the full [QaaS] line from your test output
• the run id, if one was printed
• the project slug you expected the results to land in

Then open a ticket at support.gamedriver.io.

Related articles

• Configuring QaaS Reporter Environment Variables
• Uploading GameDriver Test Results to QaaS