License availabilityTest Case Management: Int4 Shield Lite

Test Cases

Overview

The Test Cases list is the cross-folder view of every test case you can see in Int4 Suite.

Use this page when you want to find, execute, migrate, or export test cases across several folders at once — for example to launch a regression run that spans multiple projects, or to copy a batch of test cases onto a new automation object after an interface change.

The list shows only test cases whose effective project scope you are permitted to read, and never shows archived test cases — test cases that were deleted while execution history still referenced them (see Tips & edge cases). Folder-by-folder browsing (and creation of new test cases) is done from the folder tree page; this page is the filterable cross-folder inventory.

Tasks

How to find a test case

1. Open Test Cases → All Test Cases from the main navigation.
2. In the toolbar, type into the Search test cases... box. The search matches the test case number, document number, description, and the linked automation object name. Results update automatically a short moment after you stop typing.
3. Optionally narrow the list further by picking a value in the type drop-down next to the search box (unlocalised: type filter has no dedicated label key — options come from the generated AutomationObjectType enum).
4. To start over, click Clear filters — it resets the search, the type filter, and the pager in one go.
5. Use the pager at the bottom of the grid to move between pages, or change the page size to load more rows at once.

Your search, type filter, and page position are kept in the page's web address. Refreshing the browser keeps your view, and copying the address from the browser bar gives a colleague the exact same filtered list (what they actually see still depends on their own permissions).

Rows are ordered hierarchically: a parent test case is listed immediately before its children, and siblings are ordered by their number.

How to execute test cases

You need the Test Case: Execute permission on the project scope of every test case you select.

1. Tick the checkboxes of the test cases you want to run. To execute everything that matches the current search and type filter, leave all rows unticked — the action then applies to the whole filtered set.
2. Click Execute (count selected) when you have a selection, or Execute All when nothing is ticked. The run starts immediately with default options and you can follow its progress from the Test Runs area.
3. To open the parameters dialog instead — for example to set a custom run name, switch on debug mode, choose a different system-under-test group, or schedule the run — open the split-button menu and pick Execute Selected w/ Parameters (or Execute All w/ Parameters with no selection). Fill in the Execute Test Run form and confirm with Execute.
4. After the run starts, follow the link in the toast notification (View Test Run) to jump to the Test Runs page for live status.

Two selection rules are checked when the run starts:

• Children need their parents. If you tick a test case that belongs to a parent, you must tick the parent too — otherwise the run is rejected with a message listing each child and the parent it requires. The parent always runs first; its children run afterwards and are skipped automatically if the parent fails.
• The selection must still exist. If a ticked test case was deleted or archived by someone else since you loaded the page, the run is rejected as a whole rather than silently running a partial selection. Refresh the list and select again.

How to migrate test cases to another automation object

Migration creates new test cases on a different automation object (and optionally a different folder), reusing the source messages where the target type supports it. Use it when an interface changes shape and you want to keep the existing payloads.

1. Tick the test cases you want to migrate. Migration only works on a non-empty selection.
2. Open the more-actions menu (the three-dots button at the right of the action group) and click Migrate Selected (count).
3. In the Migrate Test Cases dialog, choose the Folder, the Test Type, and finally the Automation Object. If you selected test cases of different types, only target types reachable from all of them appear; if none are reachable you see No migration paths available for the selected test case type.
4. Click Migrate (count). A toast confirms how many test cases were migrated; partial failures are reported as succeeded of total migrated, failed failed.

How to export the list

1. (Optional) Adjust the search and type filter so the grid shows exactly the rows you want to export.
2. Click the export button at the right of the toolbar (unlocalised: export trigger has no testCase key — uses common export icon button) and pick Export to Excel or Export to PDF.
3. The file is saved with the name test-cases plus an automatic timestamp.

The export covers only the test cases currently loaded into the grid (the visible page), not the full filtered set on the server.

Field reference

Column	Description
Number	Sequential, gap-free identifier allocated by the system on creation. Stable across all versions of the test case and never reused after deletion.
Description	Short label entered by the author. Click it to open the test case. A lock-and-clock badge marks SAP PO test cases that are past their execution window.
Parent	The parent test case this row is grouped under, shown as "#number - description". Empty for top-level test cases. Click the link to open the parent. Parents are set on the test case detail page (the Parent test case field).
Type	The automation object type that defines the shape of the test (for example, an SAP PO interface or an SAP Integration Suite iFlow).
Document #	Identifier of the target message or document on the source platform. Set when the test case is fed from a real platform message; blank for purely manual test cases.
Automation Object	The automation object the test case is bound to. The test case always follows the automation object's current version — there is no per-test-case pin.
Created By	The user who created the latest version visible to you.
Created At	When that version was created, shown as a relative time (hover for the exact timestamp).

Tips & edge cases

• What you see is scoped by permissions. The list only shows test cases whose effective project scope (inherited from the folder hierarchy) grants you read access. If a colleague's test cases are missing, check folder-level permissions, not the test case itself.
• Execution requires more than read access. Even if a test case is visible, the Execute action stays disabled unless you also have execute rights on the test case, the resolved system under test, and its automation object.
• Type filter values come from the system catalogue. The drop-down lists every automation object type known to the platform, even ones you do not currently use; this is expected.
• Deleted test cases with run history are archived, not removed. When a test case has been executed at least once, deleting it (from its detail page) keeps the record so past run results stay complete — you see the message Test case has execution history and was archived instead of deleted. Archived test cases disappear from this list and become read-only; links from old run results still open them. There is currently no way to restore an archived test case yourself.
• Creation is not available here. To create a new test case, open the folder tree (the standard Test Cases page), pick a folder, and use the create action there. This page intentionally shows the cross-folder inventory only.
• Migrating mixed types. When your selection spans more than one automation object type, the dialog restricts the Test Type list to types reachable from every source type. If the resulting list is empty, split your selection by type first.
• Versioning is preserved by migration and execution. Migrations create new test cases on the target side — the originals are untouched. Executions always read the test case's current version unless you select a specific version from the test case detail page.

Related features

• Test Cases Cockpit — folder browsing, test case creation, detail and versions, and migration
• Test Runs

Prerequisites & permissions

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.

To use this page you need at minimum the Test Case: Read permission on the project scopes that contain the test cases you want to see. Additional permissions unlock specific actions:

• Test Case: Execute — required to run test cases from this page. Also required on the resolved system under test and on the automation object.
• Test Case: Write — required to migrate test cases. The target folder must also grant Folder: Write, and the chosen automation object must grant Automation Object: Read.

If an action button is disabled and you believe your role should allow it, hover over the button — the tooltip explains the specific reason (missing permission, missing licence feature, or an expired execution window).

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

0 / 2000 characters