Scheduled Test Runs
Overview
This page lists every scheduled test run in the system (for example, a regression suite that runs overnight or before a release). It runs under a named owner whose permissions are re-checked on every fire, so it can never execute work the owner is no longer entitled to perform.
Use this read-only page to keep an eye on your automated testing — which schedules are active, when each will run next, and when it last ran. Schedules are created from the Cockpit (Execute w/ Parameters).
Tasks
How to create a scheduled run
Schedules are not created on this page — you set them up in the Cockpit, on the same dialog you use to start a run manually.
- Open the Cockpit and select the test cases you want to schedule. You can tick test cases across one or more folders, or select a whole folder.
- Open the dropdown next to the Execute button and choose Execute w/ Parameters. The Execute Test Run dialog opens.
- Enter a Test Run Name, and set any run options you need — for example the Test Run Type, Group, or Iterations.
- Switch on Scheduling to reveal the schedule options.
- Choose a Schedule Type:
- Single — one run at a chosen Start Date/Time.
- Recurring — a repeating run. Set the Recurrence (the Repeat every interval, Time of Day, and Days of Week or Day of Month), and an End Condition — run Until Date a date or stop after a number of Max Occurrences.
- Click Preview Schedule to confirm the next run times look right.
- Click Schedule to save. The new schedule then appears on this page, where you can monitor and open it.
Field reference
Each row in the list summarises one scheduled run:
| Column | Description |
|---|---|
| Name | The name given to the schedule. Select it to open the schedule's detail view. |
| Status | The schedule's current state: Active (still eligible to fire), Paused (temporarily off), Completed (the schedule has run as many times as planned and will not fire again), or Disabled (cancelled). |
| Schedule Type | Whether the schedule runs once or repeats. |
| Owner | The user who owns the schedule. Each automatic run uses this person's permissions; if the owner loses the right to start the tests, that run is recorded as a failure rather than executed. |
| Next Run | When the schedule is next due to start. Empty once a schedule is completed or disabled. |
| Last Run | When the schedule last started a test run. |
| Occurrences | How many times the schedule has fired so far. Used to enforce "stop after N runs" schedules. |
| Created | When the schedule was created. |
Tips & edge cases
- A scheduled run is a normal run on a timer. Nothing about how the tests execute changes when they are scheduled — the schedule only decides when they start. A run that fires on schedule lands in the Test Runs list, shows progress and an overall verdict, and can be opened, inspected, and rerun exactly like one you started yourself. Think of scheduling as moving the trigger from a person to a clock, not as a different kind of testing.
- A schedule runs as its owner. Every automatic run uses the owner's permissions at the moment it fires. If the owner can no longer start one of the test cases — for example because a role was removed or a folder was moved out of their reach — that run is recorded as failed and the schedule moves on to its next due time.
- Deleted targets are skipped, not run. If the test cases a schedule points at have been removed or archived since the schedule was set up, the due run is recorded as skipped instead of started, and the schedule continues to its next time.
- Missed runs are not replayed. If the system was down across one or more due times, only a single catch-up run starts when it comes back — the individual missed times in between are not run retroactively.
- Completed schedules stay in the list. A schedule that has reached its end (a single run that has fired, or a recurring schedule that hit its end date or run count) shows as Completed and stops firing, but remains visible for reference.
- Recurring schedules build up history over time. Each time a schedule fires it adds an entry to that schedule's run history (visible in the detail view); for long-lived recurring schedules this history grows steadily.
Related features
Prerequisites & permissions
To work with scheduled test runs you need the Test Run Template: Read permission to see the list and open a schedule's detail. Creating or cancelling a schedule requires additional permissions (Test Run Template: Write to create, Test Run Template: Delete to cancel), and only the owner of a schedule can cancel it. Because each automatic run also re-checks the owner's permissions on the underlying test cases at the moment it fires, the owner additionally needs Test Case: Execute (and read access on the related systems and automation objects) for the run to actually start.
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.