> ## Documentation Index > Fetch the complete documentation index at: https://docs.testdino.com/llms.txt > Use this file to discover all available pages before exploring further. # Test Runs > Run manual and automated test cases together, pull automated results from a CI run, and track a verdict per browser. A run tracks the test cases you are validating for a release. It holds manual test cases you work through by hand and automated test cases whose results come from a CI run, so one run answers whether the release is ready instead of two. Runs live on the **Test Execution** page, under the **Runs** tab. Runs start on the **Pro** plan. Pro allows 10 runs per project, Team allows 100, and Enterprise is custom. Deleting a run frees a slot. The Free plan does not include runs. See [Pricing](/pricing#plan-limits-at-a-glance). ## Create Or Edit Run Click **Create Run** to open the run form. To edit an existing run, open it, click **...** in the header, then **Edit**. | Field | Description | | :- | :- | | `Name` | Required run name | | `Release` | **Required.** Run must be linked to a release at creation | | `State` | Workflow state from project settings; defaults to `New` | | `Environment` | Target environment from project settings | | `Tags` | Up to 10 tags; pick existing ones or type a new one | | `Linked issues` | Jira or Linear issues, by key or URL; see [Link Work Items](#link-work-items) | | `Note` | Run-level note with inline image support | | `Test Cases` | Which cases the run starts with; see [Run Scope](#run-scope) | | `Browsers / platforms` | Optional. Gives each case a verdict per browser; see [Test One Case On Several Browsers](#test-one-case-on-several-browsers) | | `Read automated results from` | Optional. The CI run automated cases take their result from; see [Pull Automated Results From CI](#pull-automated-results-from-ci) | **Note** A release is mandatory on every run. If the one you need does not exist, pick **Create release...** in the Release dropdown. ## Run Scope **Test Cases** decides which cases the run starts with. | Option | What the run contains | | :- | :- | | `All test cases` | Every active test case in the project, manual and automated | | `Automated only` | Only cases whose automation status is `Automated` | | `Manual only` | Only cases whose automation status is `Manual` | | `Select specific cases` | Individual cases and whole test suites that you pick | Linking a case to an automated test sets its automation status to `Automated`, so link cases before you create the run or the automated scope finds nothing to include. Accuracy matters here: a run reports the result of whatever test the link points at, so a wrong or stale link reports a verdict for a case nobody validated. See [Keeping links accurate](/test-management/test-cases/list-view#keeping-links-accurate). ## Pull Automated Results From CI **Accurate links are required** A run reports whatever the link points at. A case linked to the wrong test reports a result nobody validated, and a case whose link is broken reports nothing at all. Both numbers roll straight up into the release. Check the link before you trust the result: [Keeping links accurate](/test-management/test-cases/list-view#keeping-links-accurate). Set **Read automated results from** to a CI run, and every automated case in this run takes its result from it. Cases with no automation link stay yours to test by hand. Leave it empty to use the latest CI result for each test. Pick a run when you need the release judged against one specific build. Results refresh when you open the run. Press **Refresh** in the header to pull again after a new CI run finishes. ### Why A Case Shows Not Run An automated case reads `Not run` when the CI run you are reading did not carry that test. Hover the icon beside the status for the reason; each cause needs a different fix. | Message | What to do | | :- | :- | | `CI runs this test, but the run you're reading didn't include it.` | Re-run the pipeline, or point the run at a CI run that covers it | | `No CI match in recent runs. Re-link this case to an automated test.` | [Fix the link](/test-management/test-cases/list-view#linked-automation-tests). Moving or renaming a spec file breaks the link, so re-link the case | | `CI has no result under this browser name for this test. Browser names must match your Playwright project names.` | Rename the run's browser to match your Playwright project name, or add that browser to CI | | `CI reports no browser name for this test. Name the projects in your Playwright config so results can be placed.` | Name the projects in your Playwright config | Open a case and check the **From CI** block in its Results tab to see which CI run answered it, and when the test was last seen if the current run missed it. ### How A Manual Result And A CI Result Combine When a case has both a result you recorded and a result from CI, the run shows the worse of the 2. Marking a case `Passed` by hand does not clear a CI failure. To clear a failing case, re-run the pipeline so CI reports a pass, or unlink the case from its automated test so CI stops answering for it. ## Test One Case On Several Browsers Add browsers to **Browsers / platforms** and each case in the run gets a verdict per browser instead of 1 verdict overall. A case that fails on any browser counts as failed. Browser names must match what CI reports. Chrome and Edge run as Chromium, and Safari runs as WebKit. Leave the field empty for a single-configuration run, which behaves exactly as a run with no browser list. With browsers set, the Overview tab groups cases by browser. Each section header shows how many of its cases have an answer, such as `12/40 answered`. Use the browser chips above the list to work down 1 browser at a time. Filters apply per browser. Filter **Results** to `Passed` and a case that passed on Firefox but failed on Chromium is listed under Firefox only; the count on each browser chip follows the filter, so it tells you how many cases match on that browser. `Not run` and `Flaky` are in the Results filter too, so you can list the automated cases CI did not answer. Recording a result asks which browser it is for. On a run covering several browsers, a result must name one. ## Run Detail The Run Detail page is where you work through a run. It has 3 tabs: `Overview`, `About`, and `Activity`. The header has **Refresh** and a **...** menu with **Edit**, **Print**, and **Delete**. **Print** opens a preview you can print or save as a PDF. ### Overview Tab The `Overview` tab opens by default and displays all test cases in the run, grouped by test suite. Each test case shows its ID, title, whether it is `Automated` or `Manual`, its assignee, and its result. Update statuses, assign testers, and record results directly from this tab. Run Overview tab showing run status, metrics, and grouped test cases with assignee and result controls ### Sort And Reorder **Sort** above the list orders the cases by `Case ID`, `Manual Order`, `Last Updated`, or `Title`. `Case ID` and `Title` also take a direction; `Last Updated` is always newest first and `Manual Order` always follows the suite. The choice is shared with the [Test Cases list](/test-management/test-cases/list-view#sort) and the printable report, so the 3 read in the same order. `Manual Order` is the order of the cases inside their suites on the Test Cases page. While the run is open and sorted by `Manual Order`, drag a case by its handle to move it within its suite; the Test Cases page follows, and so does every other open run of that suite. A case cannot be dropped into another suite from a run, and cases with no suite cannot be dragged. Closing the run freezes its order. ### About Tab The `About` tab provides a summary of the run, including the status breakdown, contributors, estimated and elapsed time, and the run's state, release, environment, creator, tags, and note. On a run covering several browsers, the summary offers 2 units. `Test cases` counts each case once. `Browser checks` counts each case once per browser, so a 20 case run on 2 browsers reads 40. Switch between them with the toggle above the chart. Run About tab showing run status, contributors, and metadata ### Activity Tab The `Activity` tab displays the complete run history as a timeline. It also shows aggregated test result trends and execution progress over time. Run Activity tab showing activity insights and test result history ## Add Result You can quickly update a test case status directly from the status dropdown using Untested, Passed, Failed, Blocked, Skipped, or Retest. To record more than a status, click **Add result**. In the test case panel it sits as a button beside the status dropdown; in the list it is the last item inside that dropdown. Either opens the **Add result** panel. * **Result:** Result status for the test case (the same values as the quick dropdown). * **Elapsed (seconds):** How long the test took to run. * **Note:** Rich-text observation (optional). * **Evidence:** Jira or Linear issues for this result (click **Link a work item** and paste a key or URL; see [Link Work Items](#link-work-items)), and files: up to 5 files, max 5 MB each. Supported: PNG, JPG, WebP, PDF, DOCX, XLSX, ZIP, JSON, TXT, CSV. Drop files onto the upload area or click it to browse. Files upload when you submit the result; if one fails, the result is not saved, and the file is marked so you can retry or remove it. Submit with the button named after the result you picked, for example **Add Passed result**. Add Result dialog showing STATUS, ELAPSED (SECONDS), NOTE, LINKED ISSUES, ATTACHMENTS, and the Cancel and Add Result buttons ## Link Work Items Runs and results link to Jira and Linear issues. The **Linked issues** field on the run form and in the **Add result** panel opens as a **Link a work item** row. Click it, then either paste an issue key or URL, or pick **Create new Jira issue** or **Create new Linear issue** to file one in a popup. When you close the popup, the new issue appears as a linked chip. Requires Jira or Linear connected under **Settings → Integrations** ([Jira](/integrations/issue-tracking/jira-forge-app), [Linear](/integrations/issue-tracking/linear)). With neither connected, linking shows `Connect Jira or Linear in Settings → Integrations to link work items.` | You paste | What happens | | :- | :- | | A Jira or Linear issue URL | Links that issue from that tracker | | A key that exists in 1 connected tracker | Links it; the chip shows the tracker's icon | | A key that exists in both trackers | A picker lists the Jira and Linear match with each title; choose one | | A key found in neither | `Issue not found in Jira or Linear` | Linking a Linear issue to a run, or to a result inside it, adds a `TestDino run: ` attachment on the Linear issue that opens the run page. The attachment is removed when the last link between that run and the issue is removed, or when the run is deleted. Jira issues show linked runs through the [Jira Forge app](/integrations/issue-tracking/jira-forge-app) panel instead. The printable run report lists linked issues, run-level and per result, with tracker, key, and title. ## Closing A Run Closing a run is permanent. Use **Close** in the run detail header. After close, the run stays viewable but new results, assignment changes, and field edits are blocked. ## Run Settings Run-related project settings are managed via ** Test Case Settings → `Test Execution` → `Runs`** in the header. The defaults below ship with every project and can be edited. | Setting | Default Values | | :- | :- | | `Result Status` | `untested`, `passed`, `failed`, `blocked`, `skipped`, `retest` | | `Run State` | `New`, `In Progress`, `Under Review`, `Rejected`, `Done` | | `Environment` | `Production`, `Staging`, `UAT`, `QA`, `Development` | | `Tags` | `Smoke`, `Regression`, `Sanity`, `Integration`, `E2E`, `API`, `UI` | Settings page showing the Runs section with result status, run state, environment, and tag options Group runs under releases and sub-releases Connect a test case to the automated test that covers it Use sessions for exploratory testing This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.