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
- Steps are added dynamically within the Test Case form.
- Each step is assigned an automatic order value.
- Steps execute sequentially from lowest order to highest.
- 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
- Enter a clear description of what the step performs.
- The Action field is required for every Test Step, including steps that also use an Action API or Expected API.
- Clear action text also makes execution history and reports easier to understand.
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
AXQA uses five system status types:
- Not Run
- Passed
- Failed
- Error
- Skipped
Projects can also define custom Step Statuses with their own names and colors.
Every custom status maps to one of the five system status types so AXQA can calculate Test Case progress, execution results, and reporting consistently.
Note
Step status contributes to overall Test Case progress.
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)