Proposed tests

What a proposed test is

A proposed test is a short description of something worth testing — a name, an intent, and usually a few steps. OttoTester suggests them from your reference docs and lists them under Tests → Proposed.

Each one carries:

A name and a one-line description.
An intent — happy-path, negative, or edge-case — 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 find the right proposed tests without dictating the exact script — the generator still writes Playwright code from page snapshots. The proposed test just points the planner at the scenarios you care about.

A proposed test versus a test

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

	Proposed test	Test
Where it comes from	Suggested from a reference doc, or typed by you	Written by the planner during a run
What it is	A description of what to test	A test case with a script
Does it run?	No — it shapes planning	Yes — the executor runs the script
Where it lives	Tests → Proposed	Tests → Active

Proposed tests belong to the application, so every variant benefits. The tests written from them belong to one variant — each variant has its own.

How they are suggested

When you upload a reference doc, OttoTester reads it and suggests tests from it. Each one is tagged with the doc it came from, so you can tell at a glance which came from which source.

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

What you do with them

The Proposed tab is where you manage them. From there you can:

Edit one — sharpen its name, fix its intent, refine the steps.
Archive one you don’t want — it stays in history but the planner stops using it.
Add one manually — for scenarios that aren’t in any reference doc but the team wants covered.
Suggest again from one document — replaces that document’s untouched proposed tests while keeping anything you’ve edited, and anything a test was built from.
Suggest again from everything — same rule for every document in the application. Proposed tests from Jira aren’t affected; they update when their issue changes.

A proposed test that a test was built from is never deleted by suggesting again, because the test would lose track of what it covers. If the document no longer contains that scenario, the proposed test stays and shows No longer in the document (or No longer in the issue). It still counts toward Scripted, but a part no longer in its document no longer counts toward Requirements covered. Archive the proposed test if it no longer applies. For the same reason, Delete is refused for a proposed test that has tests; archive it instead.

Pick one to write — in a Test Authoring Template, tick the ones you want and each is written as its own test, linked back to the proposed test it came from.

Edits are sticky on purpose. Anything you’ve changed is “yours,” and suggesting again won’t throw your work away.

Two ways a proposed test becomes a test

You pick it. Tick it in a Test Authoring Template and it’s created directly as a test, exactly as written, linked back. 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 looks for proposed tests relevant to the page it’s exploring. It can quote, expand, combine, or ignore them depending on what it’s actually seeing on the page.

The planner path produces tests 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.

When a test can’t be written

While writing a test, OttoTester tries each step in the app. If it can’t see a step working, for example because a control the document describes isn’t on the page, it doesn’t save a test with guessed checks. The proposed test stays in Proposed, labeled Couldn’t be written, and its detail says what OttoTester saw instead for each step. Change the steps with Edit steps to match what the app does, then click Create test to try again. The label goes away once you edit the proposed test or a test is written from it.

How coverage is counted

The Proposed tab counts per proposed test, for the variant you have selected. Each active proposed test has one status there:

Proposed: no test is linked to it yet.
Planned: a test is linked, but it has no test script yet.
Scripted: a test script exists, but none has passed its last run.
Ready: a linked test script passed its last run.

Scripted on the Proposed tab is scripted plus ready, out of all active proposed tests. A plan with no script isn’t counted yet. Sign-in helpers never count, because they set up a session rather than check something. The Proposed tab and the dashboard read the same numbers: on the dashboard, scripted plus ready is the second line of the Requirements covered card, “N of M proposed tests scripted”. How many requirements have a passing test is the Requirements covered card itself.

Requirements and defects

The Requirements covered card counts requirements, not proposed tests. A requirement is either:

a part of a document marked Requirements (see Reference docs), or
a story from your issue tracker whose type you mapped to requirements.

A part of a document counts as a requirement only after a person confirms the document’s parts, and only while the parts were found in the document’s current text. A part you unticked does not count. A requirement is covered when at least one of its proposed tests is ready. One with no proposed test at all still counts, as not covered. Defects covered works the same way for parts of documents marked Defects and bugs from your issue tracker. A document marked Reference adds to neither card; its proposed tests still count in “proposed tests scripted”.

OttoTester saves every document’s parts when it reads the document, whatever it counts as. So changing a document from Reference to Requirements needs no new read, but its parts count only once a person confirms them. If reading a document again no longer finds a part, but one of its proposed tests is still kept (a test was built from it, or you edited it), the part is kept. It no longer counts as a requirement.

The small trend line on each card is counted using today’s document settings. Every finished run saves whether each part and each imported issue was covered, so when you change what a document counts as, or which issue types count as requirements or defects, the whole line is counted again the new way. Relabeling alone never makes the line jump. A deleted document, a part removed from its document, or an issue from a tracker connection you no longer use drops out of every point. Runs from before this was added are not shown.

Below the cards, a list shows each requirement (and each defect) without a passing test, with where it came from and how many of its proposed tests are scripted. Click a row to open the Proposed tab showing just that requirement’s proposed tests.

Archived proposed tests don’t count, and neither do their tests. Open an archived proposed test and press Restore to count it again.

A test that isn’t linked to any active proposed test still runs, but it counts toward nothing. The Proposed tab says how many there are; Show them lists them on the Active tab. Open one and press Add as a proposed test to make a proposed test from it, so it counts. If a proposed test with exactly the same text already exists, the test is linked to that one instead.

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