Scheduled Test Runs
LicenseIncluded in Int4 Shield LiteDetails
| Feature or limit | Int4 Shield Lite |
|---|---|
| Test execution | Included |
Anything a license model does not include can be added through a custom license. The license installed for you is shown in the app under Profile → License. All features by license
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).
Select a schedule to see how it is set up and every time it has fired, with a link to each test run it started. From there the owner can also cancel it.
Tasks
How to create a scheduled run
Schedules are not created on this page — you set them up in the Cockpit, in the same dialog you use to start a run with parameters.
- Open the Cockpit and select the test cases you want to schedule, or a whole folder.
- Open the menu next to Execute and choose Execute w/ Parameters. The Execute Test Run dialog opens.
- Under Basic Options, enter a Test Run Name — every run the schedule starts is named
[Scheduled] <name>— and set the run options you need, such as Test Run Type or Group. Under Performance Testing you can set Iterations and a Performance Report. - Under Scheduling Options, switch on Scheduling.
- Choose the Schedule Type, the Timezone that all times are read in, and when it should Start: Immediately or At Specific Time (then pick the Start Date/Time).
- Single runs once.
- Recurring repeats. Under Recurrence, set Repeat every (a number and a unit from minutes to months). For days, weeks and months also set the Time of Day; for weeks pick the Days of Week; for months choose the Monthly Mode — First Day, Last Day or Specific Day with its Day of Month. Under End Condition, choose whether it ends Never, on an Until Date, or after a number of Max Occurrences.
- Click Preview Schedule to list the Next scheduled runs and check that they are what you expect.
- Click Schedule. The dialog confirms Scheduled test run created successfully, and the schedule appears on this page. You become its owner.
How to check what a schedule has done
- Select the schedule in the list. Its page shows how often it runs at the top, then Details (owner, status, occurrences, last and next run), the Execution Configuration the runs use, and how many test cases and folders it selected.
- Look at Run History (
count): one row per time the schedule fired, newest first. Select a row with a test run to open that run's results. - A Failed row carries the reason in Error — for example that the owner no longer has the permissions the run needs.
How to cancel a schedule
- Open the schedule. Only the owner can cancel it, and only while it is Active or Paused.
- Click Cancel Schedule and confirm in the Cancel Scheduled Test Run dialog.
- The schedule becomes Disabled and never fires again. Test runs it already started are kept. To run the tests on a schedule again, create a new one.
Field reference
Each row in the list summarises one schedule. Filter the list with Search by name... and the status filter; Clear filters resets both.
| Column | Description |
|---|---|
| Name | The name given to the schedule. Select the row to open it. |
| Status | Active (will fire at the next due time), Paused (temporarily off), Completed (has fired as often as planned and will not fire again) or Disabled (cancelled). |
| Schedule Type | Single Run or Recurring. |
| Owner | The user the schedule runs as. Every run it starts uses this person's permissions at that moment; if the owner may no longer start the tests, that occurrence is recorded as failed instead. |
| Next Run | When the schedule is next due. Empty once it is completed or disabled. |
| Last Run | When the schedule last fired. |
| Occurrences | How many times the schedule has fired so far. A schedule that ends after a number of occurrences stops when it reaches it. |
| Created | When the schedule was created. |
In Run History (count), each row has a Status:
| Status | Meaning |
|---|---|
| Submitted | The schedule fired. When a test run was started, Test Run links to it; when it is empty, there was nothing that could be started (see the tips below). |
| Failed | The schedule fired but could not start a run, for example because the owner no longer has a permission the run needs. The reason is shown. |
| Skipped | The schedule's run definition no longer existed when it was due. |
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.
- The selection is worked out again each time. Every time the schedule fires, the selected folders are read again, so test cases added to them since are included and removed ones are left out.
- A fire can start nothing. If the selection no longer contains any test case, if a system under test cannot be determined, if test cases picked one by one have been deleted or archived, or if a test case now needs a parent or an earlier process step that is not selected, no test run is started. The history then shows the occurrence as Submitted without a test run and without a reason, and the schedule moves on to its next time. If you see such rows, start the same selection by hand from the Cockpit to see the reason.
- Schedules cannot be changed. To change the time, the settings or the test cases, cancel the schedule and create a new one.
- Times follow the chosen timezone. Start time, time of day and end date are read in the schedule's timezone, so a daily 06:00 run stays at 06:00 local time across daylight-saving changes.
- Short intervals keep to the clock. "Every 15 minutes" fires at :00, :15, :30 and :45, whatever the start time. Schedules are checked once a minute, so a run can start up to a minute after its due time.
- Monthly runs on short months. A run set for day 31 fires on the last day of shorter months.
- Missed runs are not replayed. If the system was down across one or more due times, a single catch-up run starts when it comes back — the missed times in between are not run one by one.
- Completed schedules stay in the list. A schedule that has reached its end shows as Completed and stops firing, but remains visible for reference.
- The history shows the latest 100 fires. Older entries are kept but not listed.
- The owner hears about every run. Each finished scheduled run is reported to the owner under Notifications, and counts as the owner's run on the dashboard.
Related features
Prerequisites & permissions
To see this page and open a schedule you need the Test Run Template: Read permission. Creating a schedule needs Test Run Template: Write, Test Case: Execute on every selected test case (with read access to the systems under test and automation objects it uses) and a licence that includes test execution. Cancelling needs Test Run Template: Delete, the same licence, and you must be the schedule's owner. Because each run re-checks the owner's permissions at the moment it fires, the owner keeps needing Test Case: Execute for the runs to start.
About permissions. What you can see and do is decided by the roles assigned to your user. Each role bundles permission groups, and each permission group allows activities — Read, Write, Delete, Execute and, for schedules, Change owner — on a kind of record (for example Test Case, Automation Object, System Under Test). A role grants its groups per project scope, so you may be allowed to change records in one project but only view, or not see, those of another.
If a button is disabled, a page says you don't have access, or a list comes back empty, missing permissions are the most likely cause — or, for whole product areas, the installed licence. You can review your own access under Profile → My access; an administrator can change your roles under IAM → Users.