Candidate tests

What a candidate test is

A candidate test is a short, structured description of something worth testing — a name, an intent, and usually a few steps. OttoTester proposes them from your reference docs and lists them on the application’s Candidate tests tab.

A candidate carries:

A name and a one-line description.
An intent — happy-path, negative, edge-case, validation, or error-handling — same vocabulary as a real test.
Optional tags marking which broad areas of the app it covers.
Optional steps — short notes on the actions and checks involved.

That’s enough for the planner to retrieve the right candidates without dictating the exact script — the generator still writes Playwright code from page snapshots, the candidate just biases the planner toward scenarios you care about.

Candidate tests vs tests

It’s easy to confuse the two. The short version:

	Candidate test	Test
Where it comes from	Extracted from a reference doc, or typed by you	Written by the planner during a run
What it is	A suggestion of what to test	An actual test case with a script
Does it run?	No — it shapes planning	Yes — the executor runs the script
Where it lives	Application → Candidate tests tab	Variant → Tests

Candidates are application-wide (every variant benefits). Tests are variant-specific — each variant has its own.

How candidates are proposed

When you upload a reference doc, OttoTester runs a candidate-test proposer that reads the doc and emits candidates. Each proposed candidate is tagged with the doc it came from, so you can tell at a glance which suggestions came from which source.

The proposer aims for breadth over precision — you’ll often see candidates worth merging, refining, or archiving. That’s expected; curation is part of how you steer the planner.

What you do with candidates

The Candidate tests tab is the management surface. From there you can:

Edit a candidate — sharpen its name, fix its intent, refine the steps.
Archive one you don’t want — it stays in history but the planner stops retrieving it.
Add one manually — for scenarios that aren’t in any reference doc but the team wants covered.
Re-propose from a doc — re-run the proposer for one reference doc, replacing its un-edited suggestions while keeping anything you’ve edited.
Re-propose everything — re-run all proposers across the application. Same rule: edited candidates persist.
Pick one to create — in a Test Authoring Template, tick the candidates you want and each is created as its own test, linked back to the candidate.

Edits are sticky on purpose. A candidate you’ve changed is “yours,” and re-proposing won’t throw your work away.

Two ways a candidate becomes a test

You pick it. Tick a candidate in a Test Authoring Template and it’s created directly as a test, exactly as written, linked back to the candidate. Use this when you know the scenario is worth a test and want a one-to-one result you can count on.
The planner pulls it. During a run’s planning phase, the planner retrieves candidates that look relevant to the page it’s exploring — a retrieval step, not raw injection. It can quote, expand, combine, or ignore them depending on what it’s actually seeing on the page.

The planner path produces test cases that reflect both what your reference docs say should be covered AND what the app actually looks like. The pick path trades that judgment for certainty: you get exactly the tests you selected.

Concept → Reference docs, Tests, Applications
Workflow → Steer what the planner tests