Test Steps Fundamentals

Test Steps define the actual logic of a Test Case. Each step represents a single action or validation and is executed in a specific order. Steps can be manual, API-driven, or a combination of both.

Why it matters

• Clear execution flow: Steps enforce a structured sequence.
• Granular validation: Each step has its own status and result.
• Flexible logic: Steps can trigger APIs, validate responses, or document manual actions.

When to use it

• A scenario requires multiple ordered actions.
• You need to validate intermediate states, not just final outcomes.
• Backend and validation logic must be separated clearly.

Core concepts

• Step Order – defines execution sequence.
• Action – describes what the step performs.
• API (Action API) – optional API executed by the step.
• Expected Logic – defines how the result is validated.
• Status – tracks execution result per step.

How it works

1. Steps are added dynamically within the Test Case form.
2. Each step is assigned an automatic order value.
3. Steps execute sequentially from lowest order to highest.
4. Each step produces an independent execution result.

How to use it

Step 1: Add a new step

• Inside the Test Case form, click to add a new step.
• Steps can be added, removed, and reordered before saving the Test Case.

Step 2: Define the step action (optional)

• Fill in the Action field to describe what this step performs.
• This field is important even when an API is attached, as it makes reports readable.

Step 3: Attach an API (optional)

Select an API from the project’s available API Definitions.
If selected, this API becomes the Action API for the step.

If no API is selected, the step may function as:

• A manual validation step
• A documentation-only step
• A pure comparison step (Expected API only)

Step 4: Provide input payload (optional)

• You may define a JSON payload override for this specific step.
• This allows test-level variation without modifying the API Definition.

Step 5: Define expected behavior

You can validate results using:

• Direct expected text/JSON
• JSON path extraction
• Literal comparison
• Expected API comparison

Step 6: Understand step status

Each step has a lifecycle status:

• Not Run
• Passed
• Failed
• Error
• Skipped

Best practices

• Keep one logical action per step.
• Use descriptive action text even when APIs are attached.
• Avoid combining multiple validations into one step.
• Maintain clean step order for readability.

Common mistakes

❌ Mistake 1: Creating one large step with multiple actions
✔ Fix: Split complex flows into smaller ordered steps.

❌ Mistake 2: Leaving action text empty when using an API
✔ Fix: Always describe what the step is doing for reporting clarity.

Security & permissions

• Steps inherit project-level access rules.
• Only authorized users can modify step structure.
• Execution behavior depends on the selected Execution Source.

Related documentation

• Creating a Test Case
• Using APIs in Test Steps
• Action API vs Expected API
• API Tree (Response Tree)