Test Cases Cockpit
LicenseInt4 Shield Lite (1 of 5) · Custom add-on (4)Details
| Feature or limit | Int4 Shield Lite |
|---|---|
| Test case management | Included |
| Manual test case creation | Add-on |
| Test case payload editing | Add-on |
| Virtual folders | Add-on |
| Test case analysis | Add-on |
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
The Test Cases Cockpit is the main workspace for test cases. A folder tree on the left sits beside the test case list on the right; when you open a test case, its detail page takes the place of the list. You browse, create, edit, copy, delete and run test cases here without leaving the page, and you build and run process tests here too.
Folders decide scope and systems. Every test case lives in exactly one folder. The folder decides two things you do not set on the test case itself: the project scope (who may see and work on it) and the default Group of connected systems (where payloads are fetched from and runs go). A folder either sets these itself or inherits them from the folder above it, so you set a landscape or an access boundary once, high in the tree, and everything beneath picks it up.
A test case is the data; the automation object is the configuration. The automation object describes how a flow is sent, read back and compared, and many test cases share one. Each test case adds only its own data: the document number of the captured document on the source system and the messages used in the test — the source payload and the expected result. Supplying the document number is what lets Int4 Suite fetch those messages for you instead of you attaching them by hand. The expected payload is the reference, the "before" captured when the test case was made; every run produces a fresh "after" that is compared against it. That one comparison serves regression testing, migration testing (capture on the old platform, run on the new one) and checking a change before it ships.
Test cases are versioned. Every save writes a new version and keeps the previous one, so you can look at an earlier version, restore it, and see who changed what and when.
Processes chain test cases into one business flow. A process — for example sales order, delivery, goods issue, invoice — lists test cases as ordered steps, lives in a folder, and runs and reports as one thing. A folder that holds processes lists them above its other test cases. See Process tests.
Saved searches work like virtual folders: stored criteria that collect test cases from anywhere in the tree, which you can open, run and export like a folder.
Tasks
How to find test cases by folder
- Open Test Cases → Cockpit.
- Click a folder in the tree. The list on the right shows the test cases filed directly in it. To jump to a folder you know by name or number, type into Search folder... above the tree and pick it.
- Narrow the list with Search test cases... (matches the test case number, document number, description and legacy ID), the type filter, and Filter by tags.... Clear filters resets them.
The list keeps a parent test case directly above its children. More rows load as you scroll; the count above the list is the total. Your filters live in the page address, so a filtered view survives a refresh and can be shared as a link; picking another folder clears them.
The list has no header row. Columns size themselves and give way as the panel narrows; use Columns above the list to show, move or remove columns — see How to choose and arrange columns.
In the tree, the badge beside a folder counts the test cases in it and all its subfolders, and the column on the right shows its group of connected systems — an arrow marks a group inherited from the folder above. Point at a folder's name to see its number. With the keyboard, the arrow keys move through folders, Right and Left open and close one, and Enter selects it. The divider between tree and list can be dragged, and the tree can be collapsed; both are remembered.
How to view test cases from several folders at once
- In the tree toolbar, click Multiselection. Checkboxes appear beside the folders.
- Tick the folders you want. Ticking a folder also ticks its open subfolders. The list combines the test cases of all ticked folders including their subfolders.
- The count on the button shows how many folders are ticked; the × beside the count above the tree clears them.
- Click the button again to return to single-folder browsing.
New test cases and process commands are not available while several folders are ticked. The ticked folders are kept in the page address.
How to use saved searches
A saved search is shared with everyone allowed to see saved searches. Each person still sees only the test cases their own project scopes allow.
Open one. Pick it in the Saved searches list in the list toolbar. The tree selection clears, the page title names the saved search, and the list shows every matching test case with a folder column. You can run, export and migrate from it as from a folder.
Create one.
- Set up the view you want to keep — a folder or several ticked folders, search text, type and tags — and click Save filters as saved search beside the saved search list. With nothing set, the same button reads New saved search and opens an empty editor.
- The editor replaces the list, with the tree still beside it. Under Identification, enter a unique name and an optional description.
- Under Folder criteria, add Folder patterns — Include or Exclude, matched against the folder Name or Path, with
*matching anything — and pick Folders directly, each with or without Include subfolders. You can drag a folder's name from the tree onto either. A preview lists the folders the criteria select right now. - Under Test case criteria, set search text, a type and tags. Under Business dimensions, require values of business dimensions found in the test cases' payloads.
- Click Create. The saved search opens straight away.
Change or delete one. Use Edit beside its name in the list, change the criteria and click Save, or click Delete in the editor.
A saved search is evaluated every time it is opened or run, so it picks up test cases and folders added since.
How to create, change or delete a folder
- Create: select the folder the new one goes under (or none for a top-level folder) and click New folder in the tree toolbar. Enter Name, and for Group and Project scope choose Inherit from parent or Set directly. Click Create.
- Everything else: open the folder's Folder actions menu (the three dots on its row, or right-click the row). Entries you may not use there stay disabled.
- Edit Details — change the name, the parent folder, the group or the project scope.
- Add subfolder — create a folder under this one.
- Analyze — start a test case analysis of the folder (shown when your licence and role include analysis).
- Audit Log — see who changed the folder and when.
- Delete — remove the folder. It must hold no subfolders, test cases, processes or other objects; the dialog says what blocks it.
Moving a folder under another parent re-scopes everything beneath it, which can change who sees those test cases and which systems they use.
How to create a test case
You create a test case either by pulling test data — picking real messages on a connected platform — or manually. Which paths you have depends on your licence (see Tips & edge cases).
Pull test data
- Select the target folder.
- Open the dropdown of New Test Case and choose Pull test data. The Message Selector dialog opens.
- Under Basic, pick the Automation Object. The dialog adapts to its test type — see How message selection differs by test type.
- Optionally narrow the search under Filters, then click Query.
- Tick the messages you want. Preview Payload shows a message's payload first.
- Optionally enter a Description for the new test cases and click Confirm Selection. Each message becomes a pending row at the top of the list, marked Unsaved. Click a pending row to adjust it.
- Click Save (
count) to save them, or Cancel to drop them.
Saved rows stay pinned at the top with their payload status until the payloads arrive. A row whose fetch failed offers Retry fetch and Dismiss.
Create manually
- Select the target folder and click New Test Case. The detail page opens empty.
- Fill in Description and Automation Object, and usually the Document Number — the button beside it opens Select from Messages so you can pick it from live messages. Optionally set a Parent test case, tags and the fields under System Environments.
- Click Save. The test case is created as version 1. With a document number (or for types that fetch without one) its payloads are fetched in the background.
How to open and read a test case
Click a test case's row, or press Enter on the focused row. Ctrl-click (Cmd-click on a Mac) the description to open it in a new tab. The detail page is divided into sections you can jump between in the panel on the right:
- General — Identification (number, version, folder, description, tags), Configuration (automation object, parent, document number, type) and System Environments (source and execution groups, system line, origin system, legacy ID).
- Messages — the source and expected messages of this version.
- Business Dimensions — two cards, shown when the automation object uses either: Values you supply holds values you enter for the run; Extracted from payloads lists the values found in this version's messages, read-only and recalculated when the test case or its payloads change.
- Test Executions — every execution of this test case across test runs, latest first.
- Admin — who created and last changed it, and the change history.
- Versions — every saved version.
When the test case is a step of a process, a strip under the top bar names the process and step and links to the steps before and after it. Back returns to the list with your folder still selected.
How to edit a test case
- Open the test case and click Edit. A Editing mode banner appears.
- Change fields under General, the messages under Messages, or the values under Values you supply.
- Click Save Changes — a new version is written and shown — or Cancel.
If you change the Document Number without touching the messages, the new version starts without messages and fetches the payloads of the new document. Changing the folder moves the test case, which needs edit rights in both folders' project scopes. Editing messages is a separately licensed capability.
If your role only lets you change dimension values, the page says so (You have permission to change dimension values only. All other fields are read-only.) and keeps every other field read-only.
How to fetch payloads again
A status strip above the form shows the latest payload fetch — waiting, running, completed, failed or not found — and updates live. Refresh status reloads it.
- Retry a failed fetch: click Retry fetch in the strip. The same version tries again.
- Replace the payloads: click Fetch payloads in the top bar and confirm with Fetch. A new version is created whose messages are replaced entirely by freshly fetched payloads; the old messages stay on earlier versions. The button needs a document number for types that fetch by one, and is disabled while a fetch is running.
How to copy a test case
Open it and click Copy. The detail page opens as a new test case pre-filled from the original: folder, description with _COPY added, document number, automation object, parent, groups and system line. Adjust it and click Save. The copy takes over neither the messages nor the tags; with a document number it fetches its own payloads.
How to delete or archive a test case
Open it, click Delete, and confirm in Delete Test Case.
- Never run — the test case and all its versions are removed (Test case deleted successfully).
- Has run before — it is archived instead, so past results stay intact (Test case has execution history and was archived instead of deleted). It disappears from the cockpit but still opens from old test runs, read-only. It cannot be un-archived.
Deleting is refused while other test cases name this one as their Parent test case, and while it is a step of a process — remove it from the process first. A test case's number is never reused.
How to view and restore a previous version
- Open the test case and go to Versions. The current version is marked Current.
- Click another version's number to open it read-only.
- Click Restore This Version and confirm. A new version with that content is written; history is kept. Back to Current Version returns without restoring.
How to group test cases under a parent test case
Set Parent test case while editing a test case to place it under another one; clear the field to detach it. In the list, children appear directly beneath their parent, and the Parent column links to it. A test case cannot become its own ancestor, chains stop at 50 levels, and an archived test case cannot be a parent.
A parent tree runs parent first. For a flow you want to name, version, read as a map and run as one thing, turn the tree into a process — see Process tests.
How to work with processes in the cockpit
When the open folder holds processes, they are listed first, each as a row with its steps beneath, followed by the folder's other test cases. The count above the list reads, for example, "2 processes · 7 steps · 12 other test cases". Two buttons choose how processes are drawn: Map (each process as a line of stations) or Steps (its steps as list rows). The toolbar's Process menu and the right-click menu of each row hold the process commands.
Processes appear only when exactly one folder is open. Creating, extending and running processes is described in Process tests.
How to run test cases
From the detail page: click Execute to run the test case now, or choose Execute w/ Parameters from its dropdown to set the run name, group, iterations, scheduling and other options first.
From the list:
- Tick the rows to run, or tick nothing to run everything in the open folder, ticked folders or saved search.
- Click the main button — Execute All, or Execute (
countselected) with rows ticked — or pick Execute All w/ Parameters / Execute Selected w/ Parameters from its dropdown.
A message links to the new test run. Ticking a process runs all its steps; running a folder also runs the processes that live in it. A step ticked on its own needs the steps before it ticked as well, as a child needs its parent.
How to migrate test cases to another platform type
- Tick the test cases to migrate (all of the same type).
- Open the three-dots menu in the list toolbar and choose Migrate Selected (
count). - Choose the target Folder, Test Type and Automation Object, then click Migrate (
count). The result says how many succeeded and failed.
How to export the list
Use the export button at the right of the list toolbar: Export to Excel or Export to PDF. The export holds the listed test cases, including the steps of the folder's processes, with the columns currently shown.
How message selection differs by test type
The Message Selector adapts to the test type of the automation object you pick:
- SAP platform types (SAP Integration Suite inbound, outbound and micro unit tests; SAP PO unit, outbound and synchronous tests) search the message monitor of one connected system. Pick the System under test and a From Date/Time / To Date/Time window, and refine under Filters with platform fields — integration flow, status, correlation or application ID on SAP Integration Suite; interface, namespace, sender, receiver and status on SAP PO. When the system sits in more than one landscape column, a System Line field asks which one.
- Business Filters (SAP Integration Suite inbound, outbound and micro unit tests) follow the other filters. Each row is a dimension of the automation object and each column a group: a message matches when every filled cell of one group matches; empty cells add no condition. + in the header adds a group of alternatives; + beside a dimension adds a row for another value required in the same payload. The newest 1000 messages of the time window are checked; the search stops after about 50 seconds and then asks you to narrow the window. A dimension that cannot be matched stops the search with the reason. Matching follows the same rules as the crawler's business filters.
- Business-object types query a list action of the business object instead. There is no time window: pick the SUT Group (active environment) to run the lookup against, and fill in the business object's own parameters under Filters (their labels come from the business object). Results are document numbers with timestamps; the payload preview works here too.
- Types without message selection (file and database comparators) do not offer Pull test data — create their test cases manually.
Field reference
Fields of a test case
| Field | Description |
|---|---|
| Number | Sequential number assigned by the system. Never reused, even after deletion. |
| Version | The version shown. Each save increments it; earlier versions are kept. |
| Folder | Where the test case lives. Decides its project scope and default group of systems. Changing it moves the test case. |
| Description | Short name, 1–100 characters. Required. |
| Tags | Free labels for filtering and saved searches. |
| Automation Object | The automation object that describes the flow: which messages it has, which kind of system it talks to, how payloads are fetched and compared. Test cases always follow the automation object's current version. |
| Parent test case | Optional test case this one sits under; the parent runs first. Ignored at run time for a process step, whose process decides what runs before it. |
| Document Number | The document on the source system the payloads are fetched for, up to 100 characters. Changing it fetches the new document's payloads. |
| Type | The test type, taken from the automation object. Read-only. |
| Source Group | Optional group of systems to fetch payloads from, instead of the folder's. |
| Execution Group | Optional group of systems to run against, instead of the folder's. |
| System Line | Which landscape column to use when the group holds several different systems of the type the automation object needs. Filled in automatically when the origin system sits in only one column. |
| Origin System | The system the payloads were originally fetched from. Set once when the test case is created; not recalculated when you later change folder or groups. |
| Legacy ID | The test case's identifier in the previous product, for imported test cases. |
Columns of the list
| Column | Description |
|---|---|
| Number | The test case number, or P and the number for a process row. |
| Payload | Payload fetch status of new and pending rows; shown while there are any. |
| Legacy ID | Identifier in the previous product; shown when imported test cases are listed. |
| Description | The description, or the process name and description for a process row. A step of a process kept in another folder carries a label with its step key and process name. |
| Folder | The folder path; shown by default in a saved search. |
| Parent | The parent test case, linked. |
| Type | The test type, or Process / Process (branching) for a process. |
| Document # | The document number. |
| Automation Object | The automation object. |
| Tags | The tags. |
| Created By / Created At | Who created the test case and when. |
Tips & edge cases
- Change the automation object with care. It is shared configuration: changing it affects every test case that uses it.
- The expected payload is your baseline. Re-capturing it — by fetching payloads again or editing messages — changes what "passing" means for every later run.
- Scope and systems come from the folder. Moving a test case can change who sees it and which systems it uses; only the source and execution group fields override the folder.
- Saving always writes a version, even with nothing changed, and restoring writes a new version rather than going back.
- Delete may archive. A test case that has run is archived, not deleted; archived test cases cannot be un-archived.
- Pulled rows live in your browser until saved. Closing the page before Save (
count) loses them. - Pull test data may be your only way to create. Without the manual creation licence, New Test Case opens the message selector directly, and its tooltip reads Manual test case creation is not available with your license. Test cases must be created from platform messages..
- A test case needs one clear target system. When its automation object needs a system, Int4 Suite looks at the execution group, then the folder's group, then — if there is exactly one system of that type — that system. If none or several remain, the save fails and names the candidates; set a group or a system line.
- Several folders always include subfolders; a single folder shows only its own test cases.
- The tree catches up after structural changes. After moving or re-scoping a folder, counts and inherited values can take a few seconds; the tree refreshes itself.
- Search, type and tag filters apply to test cases, not to processes. A folder's processes stay listed while you filter its other test cases.
- Migration needs a migration path. Mixed types, or a type without a defined path, show No migration paths available for the selected test case type.
Related features
- Process tests
- All Test Cases list
- Test Runs
- Automation Objects
- Crawlers and Test Case Loader — other ways to create test cases in bulk
Prerequisites & permissions
- Browsing needs Test Case: Read in the project scope of the folders you open; folders outside your scopes stay empty.
- Creating or changing folders needs Folder: Write; deleting one needs Folder: Delete.
- Creating a test case needs Test Case: Write in the folder's scope, Folder: Write on that folder and Automation Object: Read on the automation object.
- Editing, restoring and fetching payloads need Test Case: Write; moving to another folder needs it in both scopes. Test Case Dimension Value: Write alone allows changing only the dimension values you supply. Deleting needs Test Case: Delete.
- Running needs Test Case: Execute plus execute rights on the systems and the automation object involved.
- Saved searches need Saved Search: Read to open, Write to create and change, Delete to delete, and a licence that includes them.
- Process commands need the Process permissions — see Process tests.
Buttons you lack the permission for are disabled rather than hidden.
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.