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.

Create an application

Section titled “Create an application”

On the Apps page, click New App. It takes two steps:

  1. Your app. Give it a name and, if you like, a short description.
  2. Where it runs. Add its first variant: a name, the environment, and the base URL to test against.

Create & Scan saves both and starts a scan of the URL. Create without scanning saves both and skips the scan. Nothing is saved until you press one of them, so closing the dialog earlier leaves nothing behind.

If the variant can’t be saved, the dialog keeps your details so you can fix them and try again. The application is already saved at that point, and trying again adds the variant to it.

What an application holds

Section titled “What an application holds”

Several things belong to the application, not to any single variant. The application’s card on the Apps page shows them in order, with its variants underneath:

  • About this app — the application’s 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. Until then, the section says so and offers to scan your first variant. Click Edit to change them.
  • Integrations — one line for each connection: the issue tracker, the GitHub repository, Pipeline Integration and the Slack channel. You connect GitHub, Slack and your issue tracker on the workspace. Click Manage to pick which of the connected repos, channels and trackers this application uses, plus a couple of app-level defaults (which Slack events go to the channel by default, for example).
  • Variants — every deployment of this product, listed under the application. Each variant’s row also holds that variant’s own settings: its Trigger rules, its Slack overrides and its Pipeline setup. See Variants.

Two more things belong to the application but are managed under Tests → Proposed: Reference docs, the files you upload to give the agents richer context (product specs, lists of test scenarios, .feature files, help articles), and Proposed tests, short descriptions of what is worth testing, which the planner draws on.

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 access on the repositories you want (read and write if failed tests should open issues), 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 with read access can read issues, and one with read and write can also open them. Neither can 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: click Manage in its Integrations section on the Apps page.

The issue tracker card there has an Issues in this app list, showing the issues the application reads, 25 at a time. To find one, type its number (3079 or #3079) or words from its title in the search box. The search covers every issue the app reads, not just the ones on screen. Select the issues you want, search again for more if you like, then click Import selected. Your selections stay while you search. Each issue’s status changes from Queued to Imported as it finishes, without refreshing. The same list is under Import issues on the Tests page’s Proposed tab.

Section titled “Related”