Skip to content

Applications

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.

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.
  • Test ideas — 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 test ideas 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.

An application can be connected to an issue tracker — GitHub, GitLab, Bitbucket, or Jira. Once it’s connected, a failing test can open a defect automatically. See Connect to CI/CD for setup.