Test Cases Overview

A Test Case represents a complete testing scenario composed of ordered steps. Each step can be manual or API-driven, allowing teams to validate workflows, backend behavior, and system logic in a structured and repeatable way.

Why it matters

• Structured validation: Test Cases turn complex flows into clear, repeatable steps.
• API-first testing: Backend behavior can be validated directly without relying on UI.
• Execution visibility: Progress, results, and history are tracked at both step and case level.

When to use it

• You want to validate a feature end-to-end using APIs.
• Multiple API calls must be executed and verified in a specific order.
• Manual and automated checks need to live in the same testing flow.

Core concepts

• Test Case – a container that defines a full testing scenario.
• Test Step – an individual action or validation inside a test case.
• Action API – the API executed as part of the step action.
• Expected API / Expected Result – the reference used to validate correctness.
• Execution Source – where the test is executed (Manual, Server, Smart Agent).

How it works

1. A Test Case is created inside a project.
2. One or more Test Steps are added and ordered.
3. Each step may execute an API, validate a response, or both.
4. The Test Case is executed, and results are recorded step by step.

How to use it

Step 1: Create a Test Case

Start by defining the Test Case metadata such as title, category, priority, and execution source. This information helps organize and assign work across the team.

Step 2: Add Test Steps

Each Test Step represents a single action or validation. Steps are executed sequentially based on their order.

Step 3: Link APIs to steps (optional)

Steps can reference APIs to perform backend actions or validations. This allows API logic to be reused across multiple test cases.

Step 4: Execute and review

Run the Test Case and review:

• Step status
• Execution progress
• Result data

Best practices

• Keep Test Cases focused on one scenario or flow.
• Use multiple steps instead of one complex step.
• Prefer API-based steps for stable, repeatable validation.
• Name steps clearly so results are easy to read.

Common mistakes

❌ Mistake 1: Putting too many unrelated checks in one Test Case
✔ Fix: Split scenarios into multiple focused Test Cases.

❌ Mistake 2: Mixing action and validation logic without clarity
✔ Fix: Clearly separate what a step does (action) from what it validates (expected).

Security & permissions

• Test Cases follow project-level access rules.
• Only authorized users can create, edit, or execute Test Cases.
• API credentials are never exposed at the Test Case level.

Related documentation

• Creating a Test Case
• Test Steps Fundamentals
• Action API vs Expected API
• API Tree (Response Tree)