Running a Test Case

Running a Test Case follows the Execution Source configured for that Test Case and records results at both step and Test Case level. Server and Smart Agent execution can run API-driven steps automatically, while Manual Test Cases are progressed by updating their Step Statuses manually.

Why it matters

• Reliable execution flow – steps run in a predictable order with clear progress tracking.
• Action + validation in one run – execute APIs and validate outcomes using expected logic.
• Traceable results – every run creates a history entry you can review and compare later.

When to use it

• You want to validate a feature or regression scenario end-to-end using ordered steps.
• You need backend verification by running Action APIs and comparing against Expected logic.
• You want a recorded execution history for reporting, auditing, or debugging.

Core concepts

• Execution Source – where the test runs (Manual, Server, Smart Agent)
• Test Run – a single execution instance of a test case
• Step Order – the sequence in which steps are executed
• Action API – API executed to perform the step action
• Expected Logic – rules used to decide pass/fail (literal or expected API)

How it works

1. You start a run from the Test Case page (or from within a plan if applicable).
2. The system prepares the execution context (project, build/environment if selected, and step inputs).
3. Steps execute in order from lowest step order to highest, applying Action/Expected logic per step.
4. Results are recorded per step and aggregated into the final Test Case run status and history entry.

How to use it

Step 1: Start the appropriate execution flow

For Server or Smart Agent Test Cases that contain API-driven steps, use the Run action to start automated execution.

For Manual Test Cases, update the Step Statuses as the tester completes each step.

Step 2: Confirm execution context (if shown)

If your workflow includes selecting a build, version, or environment, choose the correct context before running. This ensures the run is associated with the right target and your results remain traceable.

Step 3: Monitor step-by-step progress

During execution, each step updates independently. API-based steps execute the Action API (if defined), then apply Expected logic (Expected API and/or expected literals). Manual steps can be updated by the tester according to the scenario.

During automated Server or Smart Agent execution, a step that has neither an Action API nor an Expected API is not automatically executable and is treated as Skipped by the automated execution flow.

Step 4: Review the results and history

After completion, review the overall Test Case status and drill into step results for details such as extracted values, comparisons, and API responses. Each run is stored in history for later review.

Best practices

• Run once after any change to steps, APIs, parameters, authentication, or body mode.
• Keep steps atomic so failures are easy to locate and diagnose.
• Prefer Expected API for dynamic systems instead of hardcoding values that change between environments.

Common mistakes

❌ Starting a run without the required inputs (e.g., missing required parameters)
✔ Confirm required parameters and step inputs are provided before running.

❌ Using fixed array indexes when response order is not guaranteed
✔ Use the API Tree and wildcard paths (e.g., [*]) when validating collections.

Security & permissions

• Execution follows project access rules and may be restricted by role.
• API credentials are not exposed during execution or in user-visible outputs.
• Smart Agent runs are controlled by the agent’s authenticated session and project permissions.

Related documentation

• Test Steps Fundamentals
• Action API vs Expected API
• API Tree (Response Tree)
• Execution Results & History