How to Write Test Cases: A Risk-Based Workflow and Examples

To write a useful test case, start with a specific requirement, identify the behavior and risk to check, define the preconditions and test data, then write one-action steps with observable expected results. A password-reset case, for example, should state that the link is valid and unused, identify the account and test data, and define what confirms the password changed.

This guide treats a test case as a reusable specification and each execution as a separate observation. It shows how to select scenarios by risk, write objective pass conditions, handle UI, API, and permission examples, and organize cases in a work-management tool without confusing workflow tracking with proof that a test ran.

How to write a test case

Use this chain: requirement → scenario → test-case specification → execution → evidence and disposition. Another tester should be able to follow the case and reach the same verdict without guessing what the author meant.

1. Identify the requirement and clarify ambiguous behavior with its owner.
2. Choose scenarios based on impact, exposure, frequency, and likelihood of failure.
3. Specify preconditions, safe test data, environment needs, and the behavior under test.
4. Write sequential steps, pairing each main action with an observable expected result.
5. Review the case, run it in a named build and environment, and record the observation and evidence as a separate execution.

A case is not proof that a test ran. The execution record supplies that context by identifying the run, its environment, its result, and the evidence required for the risk involved.

Test case, scenario, script, suite, plan, and execution

• Scenario: a high-level behavior to examine, such as resetting a password with an expired link.
• Test case: reusable preconditions, data references, steps, and expected outcomes that check one behavior.
• Test script: code or a command sequence that performs checks, often automatically.
• Test suite: a grouping of cases, such as a release smoke suite.
• Test plan: the scope, approach, resources, and schedule for testing.
• Execution: one run of one case in a particular build, environment, browser, configuration, or attempt.

If a value can change on every run, such as a build ID, timestamp, actual result, or evidence link, keep it with the execution. This prevents run-specific details from making the reusable case stale.

Start with requirements and select scenarios by risk

Review the user story and acceptance criteria alongside relevant API contracts, designs, security rules, and data requirements. If a phrase such as “valid link” or “duplicate account” has no precise definition, record the question and ask the product or engineering owner to resolve it before treating an assumption as expected behavior.

Decompose the requirement into distinct behaviors: successful use, invalid input, boundary values, permission boundaries, state changes, and relevant failure or recovery paths. Prioritize them by business impact, user exposure, usage frequency, and likelihood of failure. There is no universal positive-to-negative test ratio.

For a documented password length of 8 to 128 characters, consider 7, 8, 128, and 129 characters. These values illustrate checks immediately below, at, and above the limits. They are not values prescribed by ISO/IEC/IEEE 29119-4:2021, whose public record describes a broad scope covering software test-design techniques.

Build a reusable test-case structure

Use fields that help someone select, prepare, execute, and maintain the case. Enforce identifier uniqueness through a repository rule or schema constraint rather than assuming a generic task template provides it.

• Identity and traceability: test_case_id, requirement_id, objective, source_version, owner, and case version.
• Selection: risk_level and lifecycle_status, such as Draft, Ready for Review, Ready to Execute, or Deprecated.
• Setup: preconditions, test_data_ref, environment requirements, and required permissions.
• Procedure: ordered steps, each pairing one main action with an expected result.

A login case might use an active, unlocked account as a precondition and a reference to approved test credentials as test data. Its actions can open the login page, enter the credentials, and submit the form. Expected results should name observable behavior, such as authenticated session creation and the specified destination. Do not place real passwords or production personal data in reusable cases, fixtures, or evidence.

Bounded AI assistance for drafting

A reviewed requirement can be input to a bounded drafting workflow. The AI can suggest scenarios, boundary partitions, candidate steps, and questions. It cannot invent missing policy or decide whether the feature passes.

For example, the input may contain requirement ID REQ-AUTH-014, source version spec-3, the rule that an active user may reset a password with a valid unused link, and constraints covering expiration, one-time use, and the documented password policy. The proposed output should contain candidate case IDs, preconditions, referenced test data, ordered actions, observable expected results, assumptions, and open questions.

Before storage, validate the output against an agreed schema, confirm the requirement and source-version references, check case-ID uniqueness, verify step order, and reject any expected result that cannot be observed. The requirement owner resolves policy questions and a QA reviewer approves the draft before it enters the maintained suite. The destination may be a test-management repository or a work-management task framework, but the approval decision remains human-owned.

Write expected results that make the verdict objective

State what can be observed at the layer under test: a visible UI state, an HTTP status and response body, persisted data, an authorization decision, or an emitted event. “Works correctly” and “duplicate email is handled” do not provide a reproducible verdict.

For a hypothetical API contract, a duplicate create request might be expected to return the documented conflict response, identify the duplicate condition, and leave exactly one record. Verify the response against the contract and check the persisted-state invariant. If requests can arrive concurrently, enforce uniqueness at the transactional data-store layer. An application-level lookup followed by an insert can race.

Prefer deterministic rules for status codes, schemas, numeric limits, permissions, expiration, and persisted state. AI may draft cases or summarize logs, but it should not be the sole authority for a security, payment, compliance, or data-integrity verdict.

Apply the method to UI, API, and access-control cases

The following examples are hypothetical. Each uses a different test oracle and a different failure response. The sequence is the same: prepare the input, perform the action, validate the observable result, and preserve the execution evidence.

Checkout UI

• Trigger and setup: submit an in-stock cart using a saved test payment method, valid address, and approved browser and environment.
• Expected result: confirmation appears and the recorded order and payment states match the documented contract.
• Failure handling: capture the build, browser, cart, payment-test reference, visible messages, and recorded state. Link the failed execution to a defect if the observed state contradicts the contract.

User-creation API

• Trigger and setup: submit a valid create request, then submit a duplicate normalized email, including concurrent requests when uniqueness matters.
• Expected result: responses match the contract and exactly one user exists for the normalized email within the tenant.
• Failure handling: preserve request IDs, response bodies, timestamps, tenant scope, and post-request database evidence. Report a data-integrity defect if two records are created.

Viewer permissions

• Trigger and setup: authenticate as a Viewer and attempt to create, edit, and delete a project.
• Expected result: each prohibited action is denied at the authorization boundary and the resource remains unchanged.
• Failure handling: stop further destructive actions, preserve the authorization response and before-and-after resource state, and escalate an unauthorized persistence event as a security defect.

This structure keeps the test oracle specific to the product layer: UI state for checkout, response plus persisted-state invariant for the API, and authorization decision plus unchanged state for access control.

Keep the case separate from its execution record

An execution record represents one attempt of one case in one build and environment. It can include execution_id, test_case_id, external_run_id, build_id, environment_id, attempt_no, started_at, completed_at, actual_result, execution_status, defect_id, and evidence_url. Step results are observations within that execution. Defects are separate issues that may relate to multiple executions or cases. Aggregate reports need their own scope, time window, environment, build, and retry rules.

Use Passed only when the case, build or release, environment, observed result, and required evidence are identifiable. Use Failed when observed behavior contradicts an expected result. Use Blocked when an unavailable dependency or unmet prerequisite prevents a meaningful run. Use Inconclusive when the observation cannot establish a verdict, and Needs Retest when a fix or change requires another execution.

For concurrent ingestion, a proposed implementation key is external_run_id + test_case_id + environment_id + attempt_no when attempts can repeat. Enforce it with a database uniqueness constraint or transactional upsert. A date-only key or lookup-then-create sequence is not sufficient when parallel workers can process the same event. This is an illustrative integration design, not a documented ClickUp field or execution endpoint.

Review, execute, and maintain the suite

During execution, compare each observation with its expected result, attach evidence with its run context, and link failures to defects. State postconditions so a case does not leave behind data or permissions that contaminate the next run. When requirements, interfaces, or access rules change, review affected cases and retire obsolete ones rather than leaving ambiguous instructions in the active suite.

Automate stable, frequent smoke and regression checks where repeatability is valuable. Keep exploratory testing human-led when the purpose is to investigate behavior that cannot be fully specified in advance. Define pass-rate populations and retry treatment before reporting metrics. A percentage is ambiguous if blocked runs, retries, builds, and environments are mixed.

Choose a management tool without confusing tracking and execution

Select a tool based on case structure, execution history, reporting, integrations, permissions, scale, and plan limits. A task framework can organize cases and ownership. A dedicated test-management product or verified integration may be needed when execution history, result ingestion, or test-specific reporting is a requirement.

• ClickUp: The Test Management Template is a configurable Folder-based workflow with documented views, statuses, custom fields, an automation, and an Embed View. Use it to organize case records, ownership, readiness, and results. Confirm current plan limits and supported fields for the workspace. Treat the template as a management framework, not as evidence that a test executed.
• TestRail: A dedicated test-management option with cases, suites, plans, runs, execution history, reporting, integrations, and plan-dependent API limits. Review the current TestRail pricing and plan details before selecting a tier.
• Jira with a test-management app: Jira is primarily project and issue tracking. Test-case and execution behavior depends on the selected Marketplace application. Atlassian provides the Jira pricing page and Marketplace; SmartBear positions Zephyr as a Jira-based test-management suite.

For a ClickUp workspace, configure fields for case identity, requirement reference, risk, test-data reference, environment, and lifecycle status. Use a view to review ownership and readiness, and use documented automations for workflow actions where the plan supports them. ClickUp’s official Custom Fields and Automation documentation should be checked for current permissions and limits. The public API supports selected Custom Field and view operations, but that does not establish a universal test-execution or result-ingestion endpoint.

Teams assessing their current setup can review the ClickUp setup and automation service for workflow configuration considerations or request a ClickUp audit when existing fields, statuses, and ownership rules are unclear. These pages address workspace readiness, not proof that a test has executed.

Pricing and plan conditions change. Check each vendor’s current page and verify the exact runner, API, permission, and result-storage capabilities required by the process before committing to a tool.

Make the next case reproducible

A good test case makes a requirement observable. It identifies the behavior, setup, data, steps, expected outcomes, and risk. Separate execution records preserve what happened in each build and environment, while database-enforced uniqueness protects integrations from duplicate runs. When another tester can reproduce the verdict and trace it to evidence, the case is ready to maintain and reuse.