> ## Documentation Index
> Fetch the complete documentation index at: https://docs.watchtower.systems/llms.txt
> Use this file to discover all available pages before exploring further.

# Test Center

> Browse your test inventory, track priority and status, and triage failures.

Test Center is where your test inventory lives. Tests are organized into folders that mirror your repository's structure, and each folder is its own table so you can scan one area at a time. Folders are drawn from your workspace's single active test source; see [Connecting a Repository](/v0.6.0/guides/connecting-a-repository#choosing-your-test-source).

## Test list columns

Each row in a folder's table shows:

* **Test Cases**: a short code (e.g. `0007`) and the test's description.
* **Priority**: P0 through P3, described below.
* **Tags**: badges like `MANUAL` or `AUTO` (added by hand vs. discovered by Patrol), a framework badge (`PLAYWRIGHT` or `CYPRESS`), or `QUARANTINED` and `ABANDONED` for tests that need attention (see [Triage](#triage)).
* **Actions**: status, assignee, comment count, and linked bug ticket count, plus a menu for further actions.

### Priority levels

| Priority          | Meaning                                                                                                                            |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **P0 (Critical)** | Blocker; must pass before release. Also feeds the Dashboard's [Go/No-Go verdict](/v0.6.0/dashboard-and-reports#release-readiness). |
| **P1 (High)**     | Core functionality; test every cycle. Also feeds the Go/No-Go verdict.                                                             |
| **P2 (Medium)**   | Important, but not release-blocking.                                                                                               |
| **P3 (Low)**      | Nice-to-have; edge cases.                                                                                                          |

Priority is inferred automatically for tests imported by sync, and can be adjusted from the test's detail view.

### Status

Each test shows a pass, fail, blocked, or pending status. You can click a status icon to change it by hand, unless the test is controlled by Patrol, in which case its status is set automatically by the most recent run and can't be edited manually.

## Opening a test

Click any test to open its detail view, which adds:

* **Environment, branch, and last run** metadata.
* A **10-run history** sparkline plus a list of recent runs, so you can see whether a failure is new or ongoing.
* **Dependencies**: if a test depends on another test that's currently failing, it shows as blocked with a note explaining why.
* **Bug Tickets**: paste a link to an existing ticket (Jira, Linear, GitHub Issues, wherever you track bugs) to keep it visible alongside the test. Watchtower shows the ticket's status as a colored dot but doesn't sync changes automatically; remove it here if it's resolved.
* **Comments**: a running thread for notes, attributed to whoever's signed in. Use this to explain why a test is blocked, flag something for a teammate, or leave context for the next person who looks at it.

## Filtering and search

Use the search box, the **Priority** filter, and the environment picker in the top bar to narrow the list. The **Status** filter offers **All**, **Failing**, **Quarantined**, **Abandoned**, and **Manual**.

## Bulk actions

Turn on bulk mode to select multiple tests at once and:

* **Run Selected**: send them straight to Patrol.
* **Pass / Fail / Block**: set status on several tests at once (disabled for tests that are controlled by Patrol).
* **Delete Selected**: move them to [Trash](/v0.6.0/guides/managing-trash).

## Adding a test manually

Click **Add Test Case** to create a test that isn't discovered from your repository. This is useful for manual QA checks you want tracked alongside automated coverage.

## Unlink and Relink

**Unlink** removes the connection between a test in Test Center and its matching spec file, without deleting the test itself. **Relink** reconnects it. On a hosted workspace with a connected test source, choosing either action opens a modal asking how to apply it:

* **Dashboard only**: updates tracking here. Does not edit your repository.
* **Open a pull request**: proposes the spec change for review. Nothing merges until you approve it on GitHub.
* **Commit directly**: applies the spec change straight to the target branch.

For the pull request and direct-commit options, Watchtower shows a preview first, the repository, branch, and file involved, along with a diff of the exact change, so you can review before anything is applied. Both options are disabled with an explanation if the test's spec file isn't known yet (run **Sync Codebase** first) or if no repository is connected.

<Tabs>
  <Tab title="Open a pull request">
    Watchtower creates a branch, commits the spec change, and opens a pull request. Nothing is applied to Test Center's tracking until the pull request is merged; Watchtower checks its status periodically and updates the test automatically once it merges. While a pull request is open, the test's detail view shows a status badge (pending, merged, closed, or failed) that links to it on GitHub.

    This requires the connected GitHub App installation to have **Contents: write** and **Pull requests: write** permissions.
  </Tab>

  <Tab title="Commit directly">
    Watchtower commits the spec change straight to the repository's default branch. There's no pull request to review afterward, the change is applied immediately and dashboard tracking updates as soon as the commit succeeds.

    If the target branch is protected, the commit is rejected and Watchtower suggests opening a pull request instead. This option requires only **Contents: write** permission.
  </Tab>
</Tabs>

<Note>
  Viewers can't use the pull request or direct-commit options; workspace members, admins, and owners can. See [Workspaces](/v0.6.0/guides/workspaces#roles).
</Note>

## Triage

Watchtower gives you a few tools for turning a raw failure into something actionable:

* **Quarantine**: take a flaky or known-broken test out of your release-health rollup without deleting it. A quarantined test is tagged `QUARANTINED` and shown at reduced emphasis in the list. Quarantine clears itself automatically the next time the test passes a Patrol run.
* **Abandoned tests**: if a test's title disappears from your repository during a sync (usually because it was renamed), Watchtower keeps its history and comments instead of deleting it, and tags it `ABANDONED`. Open it and use **Rebind to a renamed test** to point it at the new title. You can search within the same spec file or across the whole repository.
* **Comments and bug tickets**: see above. Use these to keep a record of why something is blocked instead of relying on tribal knowledge.

### Archived vs. deleted tests

A test can leave your active view in two different ways:

* **Archived**: happens automatically when its repository is unticked as your test source under **Configuration → CI / Repos**. The test disappears from Test Center and from health counts, but its status, history, comments, and quarantine state are all preserved. Re-ticking the repository as the test source brings it straight back.
* **Deleted**: happens when you delete a test by hand. It moves to [Trash](/v0.6.0/guides/managing-trash), where it stays recoverable for 30 days before being purged automatically.

<Tip>
  Deleting a test only removes it from Watchtower's dashboard; it never touches the actual spec file or code in your repository.
</Tip>