Testing

Test cases

Structured steps, expected outcomes, and review workflows.

Overview

Test cases are the executable unit of validation in Zof Console, structured steps, expected outcomes, priority, platform context, and review status. Cases inherit traceability from parent scenarios and ultimately from requirement IDs.

Case quality determines operational cost: flaky steps waste agent minutes, vague expectations produce debate during failures, and missing environment context causes false positives. Invest in case editing during review, not only after repeated failures.

Cases are referenced by runs, schedules, CI jobs, and APIs via stable case IDs. Treat external references like API contracts when renaming or deprecating.

Who should read this

  • QA engineers, SREs, platform teams, and developers operating Zof Console and APIs.

Prerequisites

  • Scenarios defined with requirement mapping
  • Familiarity with priority model and review states

When to use this workflow

  • Onboarding new team members to Zof terminology and workflows
  • Authoring internal runbooks aligned with Console labels
  • Designing CI/CD or webhook integrations against documented behavior

Step-by-step procedure

Open case detail from the test library

Navigate Quality → Test library, filter by project, and open the target case.

Copy case ID from header for pipeline configuration or defect linking.

Confirm parent scenario requirement ID matches current PRD baseline.

Author clear steps

Write imperative steps ("Navigate to Orders", "Submit cancellation form") with explicit test data.

Separate setup steps from assertion steps when long flows complicate failure diagnosis.

Include API request templates or UI selectors as stable as your UI framework allows.

Define observable expected outcomes

Replace subjective language with checks: status codes, visible text, database flags, events emitted.

Document timing bounds when asynchronous behavior matters (for example within 60 seconds).

Add negative expected outcomes for denial paths (error codes, validation messages).

Set priority and platform context

Mark P0 cases for smoke suites gating deployments; P3 for edge cases run on schedules.

Tag platform web, api, or desktop so Agent Console routes jobs correctly.

Align priority with business risk, not team convenience.

Complete human review

Set review status to approved only after domain validation.

For regulated environments, store reviewer identity via process evidence outside Console if required.

Revert approval when linked requirements change materially.

Maintain case lifecycle

Deprecate superseded cases instead of deleting when historical runs must remain interpretable.

Split bloated cases into smaller units when failure messages become ambiguous.

Sync edits with suites and schedules referencing the case ID.

Key concepts

Organization scope
All Zof Console and API operations are isolated to your authenticated tenant.
Governed execution
Agent output and remediation follow policy packs with human approval when configured.

Best practices

  • Keep cases independent, shared setup belongs in fixtures or explicit setup steps documented in runbooks
  • One primary assertion theme per case for clearer failure clustering in Test Health
  • Avoid embedding production secrets; use Console-approved secret references or staging data
  • Link defects to case IDs, not only scenario titles

Common issues

Case flaky in cloud but stable locally
Timing, locale, or data dependencies differ. Harden waits; align environment test data.
Cannot approve case, permission denied
Role lacks review permission. Request QA lead or admin role update.

Sample test case structure (illustrative)

Case: TC-REQ-ORD-008-cancel-happy-path (P0, web)
Step 1: Given order ORD-4421 in Processing (<15 min)
Step 2: When customer submits cancel with CUST_INIT
Expect: Status Cancelled; inventory released <60s; event ORD-CANCEL-OK

Was this page helpful?

Test cases | Zof AI Documentation