Test Case Details

This page provides a comprehensive view of a single test case within your project's repository.

Selecting a test case in the repository opens these details in a docked, resizable panel beside the case list, with a prev/next stepper for moving through the filtered result set. The same view is available as a standalone full page — opened in a new tab from the panel's header, or via a row's Edit action.

Case Information

The main section displays key details about the test case:

• Title: The name of the test case.
• Description: Detailed steps or information about the test case. This field supports Markdown for rich text formatting.
• Repository: The repository this case belongs to.
• Folder: The specific folder within the repository where the case resides (if applicable). While editing, this becomes a searchable picker in place of the breadcrumb — type to narrow a large folder tree, or browse it with the hierarchy indented as it appears in the repository.
• Template: The template used for this test case, defining its custom fields.
• Estimate: The manually set estimated time (in seconds) required to execute the test case. See Duration Display below for formatting.
• Forecast: An automatically calculated prediction (in seconds) of how long the test case will take to execute. See Forecast Calculation below for details.
• Priority: The priority level assigned to the test case.
• Tags: Any tags associated with the test case for organization and filtering.
• Created: Timestamp indicating when the test case was created.
• Updated: Timestamp indicating the last time the test case was modified.
• Custom Fields: Any additional fields defined by the selected template will be displayed here.

Editing and Auto-Save

While editing, your changes are saved as you type. A status indicator sits on the same row as the folder picker, showing Saving…, All changes saved, or a retry notice if the server cannot be reached.

Reopening a case with unsaved edits prompts you to restore or discard them. If you land on the read-only view with unsaved work outstanding — after a crash, for example — a banner offers to resume editing where you left off. Cancelling out of edit mode discards the draft. See Auto-Save and Draft Recovery.

Duration Display

Both the Estimate and Forecast fields store time in seconds but are displayed in a human-readable format (e.g., "5 minutes, 30 seconds", "1 hour, 2 minutes"). If no time is recorded (value is 0 or null), it displays "No time recorded".

Forecast Calculation

The Forecast value provides an automated prediction of the test case's execution time. It is distinct from the manually entered Estimate.

• Calculation: The forecast is calculated by averaging the elapsed time recorded in all associated Test Run Results for this specific test case. Results with null or 0 elapsed time are excluded from the average.
• Updates: This calculation is performed automatically by a background job that runs once daily (typically overnight).
• Read-Only: The forecast value is system-generated and cannot be edited directly by users. It serves as a data-driven insight into expected execution duration based on historical performance.
• Display: It is shown on the Test Case Details page and can be added as a column in the main Repository View.

Test Result History

Below the case information, the Test Result History panel lists every result the case has ever produced across all test runs — manual results, automated (JUnit) results, and pending entries for open runs where the case hasn't been executed yet. Each row shows the run, status, tester, execution time, duration, attachments, linked issues, and the case version the result was recorded against. Expand a row to see the full result: notes, custom result fields, step results, and — for parameterized cases — the iteration's parameter values (see Parameterized Test Cases).

The panel header offers two actions:

• Elapsed time report (line-graph icon): opens the Report Builder pre-loaded with a Test Execution report for this case — Date and Test Case dimensions, the Avg. Elapsed Time metric, and the Test Case filter set to the current case — charting how the case's execution time trends over time. Shown only to users whose role grants Reporting permissions.
• Add to Test Run: adds the case to an existing open test run in the project. The picker lists open runs that don't already contain the case; composition-locked runs reject the add. Requires Test Runs Add/Edit permission and is unavailable for automated-source cases.

When the header is too narrow for labeled buttons (for example in the docked side panel), the actions collapse into a single ⋮ actions menu, with Add to Test Run as a submenu inside it.

Code Pins

When the project has Impact Analysis enabled and an application repository connected, a Code Pins panel follows the result history. It lists the code this case covers — a change inside a pinned block pulls the case into an analysis with the Pin reason. The panel header names the connected repository, and its branch when one is configured, and offers Add pin. When the project connects several repositories the header counts them instead, and each pin's row names its Repository.

Each pin is a row with its File and note, its Location (a line range such as L12–L40, a symbol name, a glob pattern, or Whole file), its Kind, and its Source — Manual, AI, Annotation, Map file, or Issue (derived from a commit that named an issue the case is linked to; the issues appear as chips under the file path). Hovering the location names the commit the pin is anchored at, and the columns can be resized by dragging their edges. A pin whose file, lines, or symbol can no longer be found at the branch tip carries a Stale badge with Re-anchor and Dismiss actions under its path. Pins added here can be edited, or removed after a confirmation, which takes effect at once; pins that come from the repository (Annotation and Map file) have both actions disabled and are edited in the repository itself.

Add pin opens the Pin this case to code dialog:

• Pin to: choose Whole file, Lines, Symbol, or Glob pattern.
• Repository: shown only when the project connects more than one repository — pick the one the file lives in.
• File: for the first three kinds, pick the file from the repository's cached file list (type to filter). If no list is cached yet, a project admin needs to refresh the repository cache; with caching turned off, files are listed live from the provider.
• Lines: the file opens with numbered lines — click a line number to start the range and shift-click another to end it, or type the Start line and End line. Files too large to display accept line numbers only.
• Symbol: pick from the declarations found in the file, or type a name the list does not offer.
• Glob pattern: type a pattern such as src/payments/**; a live count shows how many cached files match.
• Note: optional text explaining why this case covers the code.

Pins are anchored at the current tip of the configured branch. Edit pin reopens the dialog with the kind and file fixed, so a pin's range, symbol, pattern, or note can change but its target file cannot. The same panel appears read-only when the case is opened from within a test run. See Code Pins for the kinds, staleness, and repository markers in detail.

Versions

Choose a version from the Versions menu. The Versions view shows the history of changes made to this test case. Each entry represents a saved version, allowing you to track modifications over time.

• Timestamp: When the version was saved.
• Author: The user who made the change.
• Changes: A summary or link to view the specific differences between versions (details depend on implementation).

Activity

The Activity button opens the case's Activity Log — a slide-out history of every recorded change to the test case and its fields, each with the user who made it, the timestamp, and the before/after values. Unlike the Versions view, which captures saved snapshots of the case content, the Activity Log reflects the full audit trail and is available to anyone who can view the case. See Audit Logs for details.

This feature is crucial for auditing and understanding the evolution of a test case. You can often revert to or compare with previous versions if needed (depending on system capabilities).