Skip to content
OttoTester docs

Proposed tests

What a test idea is

Section titled “What a test idea is”

A test idea 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 ideas without dictating the exact script — the generator still writes Playwright code from page snapshots. The idea just points the planner at the scenarios you care about.

An idea versus a test

Section titled “An idea versus a test”

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

Test idea 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

Test ideas 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

Section titled “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 ideas worth merging, refining, or archiving. That’s expected; curation is part of how you steer the planner.

What you do with them

Section titled “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 suggestions while keeping anything you’ve edited.
  • Suggest again from everything — same rule across the whole application: your edits persist.
  • 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 idea 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 an idea becomes a test

Section titled “Two ways an idea 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 ideas 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.

Section titled “Related”