Skip to content
OttoTester docs

Applications

What an application is

Section titled “What an application is”

An application is a product you want to test — your web app, as a whole. It sits in the middle of the hierarchy:

Organization → Workspace → Application → Variant

You create an application inside a workspace. The application is the product; its variants are the specific deployments OttoTester actually tests — dev, staging, prod.

What an application holds

Section titled “What an application holds”

Several things belong to the application, not to any single variant. They’re organized on the application page as five tabs:

  • Overview — the application’s editable description: a summary (what the app does), a domain label (for example, “trademark search”), and a short usage context (who uses it, what matters, what’s risky). OttoTester fills these in automatically the first time it scans a variant; your edits always win.
  • Reference docs — files you upload to give the agents richer context than the Agent Prompt can carry on its own: product specs, lists of test scenarios, .feature files, help articles. See Reference docs.
  • Proposed tests — short descriptions of what is worth testing, which the planner draws on. Most are suggested from your reference docs; you can also edit, archive, or add your own. They belong to the application, but you manage them under Tests → Proposed. See Proposed tests.
  • Variants — every deployment of this product. See Variants.
  • Integrations — which GitHub repository and which Slack channel this application uses. You connect GitHub and Slack on the workspace; here you pick which of the connected repos and channels this particular application is bound to, plus a couple of app-level defaults (which Slack events go to the channel by default, for example). Each variant can override the Slack channel.

The application’s description, reference docs, and proposed tests are all steering inputs — OttoTester feeds them to the agents on every run so the planner and the rest test your app with an understanding of what it actually is. The Test Authoring Templates used to launch runs also live on the application.

Connecting an issue tracker

Section titled “Connecting an issue tracker”

An application can be connected to GitHub Issues. Once it’s connected, a failing test can open a defect automatically. See Connect to CI/CD for setup.

OttoTester can also read issues from GitHub so your tests can cover them. A workspace admin connects GitHub once, in the GitHub card in Workspace Settings → Integrations, and picks how OttoTester signs in. The same connection covers checks on pull requests and reading and opening issues:

  • GitHub App (recommended). Works for the whole team and isn’t tied to one person. Your organization’s owner approves the install and picks which repositories it can see.
  • Personal token. Use this when you can’t get the App approved. Make a fine-grained token with Issues: read and write access on the repositories you want, or a classic token with the repo scope. The token belongs to the person who made it, so it stops working if they leave or it expires. A token can read and open issues but can’t post checks on pull requests. You can switch to the App later without setting anything up again.

Each application then picks which repositories to read from on its Integrations tab.

Section titled “Related”