Test Runs

Overview

The All Test Runs screen is the historical and live record of every test run executed in this installation. A test run is created whenever a user launches a selection of test cases against the configured systems, whether triggered manually from a test case or folder, replayed from a previous run, or fired on schedule. Each row represents one such session.

The list is intended both for monitoring (knowing what is currently running and whether it is going well) and for triage (finding past runs to inspect failures, compare with newer attempts, or rerun a problematic selection).

Tasks

How to find a specific test run

1. Open Test Runs -> All Test Runs.
2. Type any part of the run name in the search box (Search by name...). The list filters as you type after a short pause.
3. Narrow further with the toolbar filters:
   • The status dropdown (defaulting to Status) restricts to runs in one external status — for example Running to see only what is currently in flight.
   • The type dropdown (defaulting to Type) restricts by the run type the creator picked, such as Regression Test or User Acceptance Test.
   • Use Filter by user... to find runs started by a particular colleague.
   • Use Started after... and Started before... to limit to a time window in which the run began executing.
4. Page through the results using the pager at the bottom of the list. The list pages forward and backward against the server, so very large histories are practical to walk.
5. To start over, click Clear filters — it resets every filter and returns you to the first page in one click.

Everything you set here — search text, dropdowns, dates, and the current page — is reflected in the page address. Copy the address to share the exact filtered view with a colleague, or bookmark it to return to the same slice of history later. Opening a run and navigating back also brings you to the same filters and page.

How to open a test run

Click anywhere on a row (outside the checkbox and outside the name link) or click the run name in the Name column. The detail page for that run opens, where you can inspect each individual test case execution, view results, comparisons, and structured logs. Executions are listed in hierarchy order — a parent test case appears directly above its dependent children — so chained scenarios read top to bottom. Each comparison can be opened in several presentations (raw, formatted, flat-file text diff, or a table where supported), and any custom validation checks configured on the automation object appear alongside the regular comparisons with their own pass/fail result.

How to monitor an in-flight run

Runs that are still executing show Running in the Status column and a partially filled bar in the Progress column. Status changes stream in live — you do not need to refresh.

Hover the progress bar to see a tooltip listing how many executions are currently in each detailed execution status (Pending, Preparing, Executing, Retrieving Results, Comparing, Completed, Passed, Failed, Skipped). The green segment counts passed, red counts failed, the neutral segment groups the in-progress and skipped states, and the empty tail represents executions that have not started yet.

How to rerun one or more past runs

1. Tick the checkbox at the start of each row you want to rerun. The header checkbox ticks every row on the current page at once.
2. Click Rerun in the toolbar. The button is enabled only when at least one row is selected.
3. A new run is started for each selected entry, named Re: <original-name>. The button changes to Rerunning... while the requests are being placed.
4. A dialog summarises the result. On full success it shows Test run started successfully or count test runs started successfully with the count, and lists each newly started run under Started test runs. Each entry is a link that opens the new run's detail page. On any failure the dialog shows Failed to rerun selected test runs with the specific reasons listed per source run; runs that did start successfully in the same batch are still listed below.
5. Close the dialog with Close. The list refreshes so the new runs appear at the top.

Each rerun re-resolves the original selection against the current state of the project. Test cases that have since been added to the originally selected folders are picked up, and test cases removed from those folders are no longer included. Test cases that were selected individually behave differently: if any of them has been deleted or archived in the meantime, the rerun is rejected with an error naming the missing test cases rather than silently running without them. The license and permission checks that applied to the original run are evaluated again at this moment, so a rerun can succeed where the original ran fine, or fail if a needed permission has been revoked.

How to export the current list

1. Apply filters so the list shows the rows you want to capture.
2. Click the export button in the toolbar.
3. Choose Export to Excel or Export to PDF. The file is named after test-runs and contains the rows currently visible on the page.

The export reflects only the page you are looking at — paging filters and the active toolbar filters define the scope. Export is disabled when no rows are visible.

Field reference

Field	Description
Name	The run's display name. Defaults to Test Run YYYY-MM-DD HH:MM:SS when the launcher did not pick one. Reruns are prefixed Re:. Clicking the name opens the run detail page.
Status	The user-facing status. Pending before orchestration picks the run up, Running while executions are in flight, Passed when every execution finished and every comparison — including any custom validation checks configured on the automation object — passed, Completed when every execution finished but some were skipped or did not pass comparison, and Failed when at least one execution failed.
Run Type	The intent label the launcher picked: Regression Test, Test Build/Development, Technical Check, Undefined, User Acceptance Test, or Unit Test. Carries no behavioural meaning — it is metadata for reporting and filtering.
Progress	A coloured bar showing the share of executions in each high-level state. Green is passed, red is failed, the neutral middle groups in-progress phases plus the skipped count, and the empty tail is executions not yet started. Hover for the per-status breakdown.
Created By	The user who launched the run. Reruns inherit the user who pressed the rerun button, not the user who launched the original.
Started	When the run actually began executing on the server. Shown as a relative time (for example "2 hours ago"). Empty until orchestration picks the run up.
Completed	When the run reached a final state (passed, completed, or failed). Empty while the run is still in flight. Shown as a relative time.
Duration	Wall-clock duration of the execution, from start to completion. Formatted as m:ss for runs under an hour, and H:mm:ss for longer runs. Empty for runs that have not finished or never started.

Tips & edge cases

• Selection lives per filter set. The rows you tick are remembered across pages, but only as long as the toolbar filters do not change. Changing any filter (including Clear filters) clears the current selection so you do not accidentally rerun rows you can no longer see.
• Filtered views are shareable. Because the filters and the current page are part of the page address, you can paste the address into a chat or ticket and the recipient opens exactly the same view (subject to their own permissions — they see only the runs their scopes allow).
• Rerun re-resolves the selection. A rerun is not a literal replay — it executes the current contents of the folders that were originally selected. If a test case has been added to one of those folders since the original run, the rerun will include it; if a test case has been removed from the folder, the rerun proceeds without it. To replay exactly the same set, rerun only when you are sure the underlying folders have not changed.
• Deleted individually-selected test cases block the rerun. When the original run named specific test cases (rather than folders) and any of them has since been deleted or archived, the rerun is rejected with an error listing the missing test cases. Nothing is started.
• A rerun needs every dependent test case's parent. Test cases that depend on a parent test case can only run when the parent is part of the same selection. If the parent has since been removed from the originally selected folders (or was never selected), the rerun is rejected with an error naming each test case and the parent it requires — older runs created before this rule may therefore no longer be rerunnable as-is.
• Empty selections finalise immediately. If the original selection has been emptied (for example, all test cases deleted), the rerun creates a run that finalises straight away with Completed and no executions. The same happens when a run was originally configured to "execute new test cases only" and nothing new is available — the run is created and immediately closes as completed.
• Test cases you do not have permission to execute are skipped, not failed. When you rerun against a folder that contains a mix of test cases you can and cannot execute, the run starts. The test cases you lack execute permission on appear as Skipped in the run detail. The run as a whole still reports its overall status based on the others.
• There is no "stop running" action. Once a run is Running it must reach a terminal state on its own. Closing the browser or navigating away does not affect the server-side execution.

Related features

• Test Cases cockpit
• Scheduled test runs

Prerequisites & permissions

To see this page you need the Test Case: Read permission. The list is filtered to runs whose test cases sit in scopes you can read — runs that include test cases entirely outside your scopes do not appear at all.

To use the rerun action you also need the Test Case: Execute permission, plus the same read and execute permission on every test case, system under test, and automation object referenced by the run you are rerunning. Without Test Case: Execute the rerun button is still visible but the rerun call will be rejected; without read or execute permission on a specific included test case, that case will be skipped inside the new run rather than failing the whole rerun.

Live updates from runs outside your specific scopes require the global (unscoped) Test Case: Read permission. Users restricted to specific scopes will still see their own scopes update live but will not see runs created elsewhere appear in real time.

About permissions. Int4 Suite controls what you can see and do through roles and permission groups assigned to your user. Each role grants permissions on a specific resource (for example, Test Case, Automation Object, System Under Test) at one of four levels: Read, Write, Delete, or Execute. Some permissions are further narrowed by project scope, so you may have access to one part of the system but not another.

If a button is disabled or a list comes back empty, missing permissions are the most likely cause. Ask an administrator to review your role assignments, or check IAM → Users if you have the User: Read permission.

Was this page helpful?Send a quick note to the documentation team.

0 / 2000 characters