Jira Test Case Template: Essential Fields and Worked Manual Test Examples

A Jira issue saying “Refund test: Passed” leaves a reviewer with unanswered questions. Which refund rule was checked? What data was used? Did it pass on the current build, or did someone replace yesterday's failure with today's result? A useful Jira test case template makes those questions answerable without turning the case description into an overwritten execution log.

The reusable case specifies the starting conditions, actions, and expected behavior. A separate execution record captures what happened when someone followed that specification against a particular build. Keep those responsibilities separate even when your team stores both kinds of information in Jira issues. For the wider model, see the explanation of test cases, test suites, and test runs.

Choose the Jira Storage Model Before Adding Fields

In a Jira-only approach, a team can represent a manual test case using an ordinary work item, potentially with an administrator-configured work type named Test Case. That name is a local convention. Creating it does not install structured step execution, test cycles, or per-run result tracking. Current Atlassian documentation uses “work item” and “work type”; many teams still use “issue” and “issue type.”

For Jira Cloud company-managed projects, adding a work type requires a Jira administrator with Administer Jira permission, and its availability depends on the applicable work type scheme. Team-managed projects use their own work type configuration, with administrator access and Administer spaces permission. Check the project type before requesting changes. Authors also need access and permission to create or edit the target issues; administration rights are a separate requirement. For company-managed custom fields, field configurations, contexts, and screens affect availability; team-managed field configuration follows a different path.

You do not need a custom field for every label in the template below. Start with Summary, Description, and the relevant fields already available in your project. Add dedicated fields when you need consistent filtering, reporting, or validation. A paragraph labeled “Preconditions” inside Description is content, not automatically a separate Jira field.

Reusing that content also depends on configuration. Atlassian documents default description templates for team-managed Cloud projects, while its company-managed guidance describes a custom-field and workflow workaround. Its automation guidance describes adding a template after creation, which differs from prefilling the creation form. Have an administrator validate the approach and preserve text the author already entered. Do not assume a universal native “Save as Test Template” control or identical behavior in Data Center.

An installed Marketplace app may provide a different model. For example, Xray Cloud documents manual steps containing actions, data, and expected results, with execution recorded separately. Those are app features, not fields gained by naming a Jira work type Test Case. An issue-template utility that prefills descriptions also need not provide test runs. Check the installed product, Cloud or Data Center edition, licensing scope, configuration, and user permissions before following app-specific instructions.

Sherlock Test Management provides another relevant example: its current product description separates approved, versioned test baselines from release-specific runs and records Pass, Fail, or Blocked through its Runner or supported Jira panels. That model addresses the need to reuse a refund specification without replacing earlier results. The Sherlock product workflow describes those capabilities; AI-generated additions and edits require human approval, rather than proving autonomous execution against the application.

Copy This Reusable Case Specification

Copy these labels into a case description and replace the prompts with your team's details. Use ordinary paragraphs or native lists in Jira's editor. If your app supplies structured steps, put the actions, inputs, and expectations in those controls instead of maintaining a competing step list in Description.

• Summary: State the action, relevant condition, and expected behavior.
• Case ID: Use the Jira key or the stable identifier supplied by your test-management app.
• Requirement Reference: Identify the story, acceptance criterion, and relevant requirement revision.
• Case Revision and Review State: Identify the approved specification and whether it is ready for reuse.
• Objective and Risk: Explain the behavior checked and the consequence of getting it wrong.
• Preconditions: Specify the user role, starting business state, dependencies, and required feature configuration.
• Test Data: Name the approved fixture, necessary input values, and how a fresh instance is obtained. Do not paste secrets.
• Environment Constraints: State any configuration necessary for this behavior. Record the actual tested build and browser in the execution record.
• Steps and Expected Results: Pair each ordered action with the observable outcome that determines whether it succeeded.
• Cleanup: Describe how to release or restore the resources changed by the case.
• Maintainer and Priority: Identify who reviews specification changes and how the case ranks under the team's priority policy.

Use the Jira key as a reference rather than manually allocating a second identifier unless your process needs one. Summary, Assignee, Priority, and Labels can serve their normal Jira purposes where configured. If Assignee identifies the case maintainer, keep the person executing a release run separate. Choose a configured issue-link relationship for requirements, with linking enabled and the necessary permissions; do not assume every Jira site has a built-in “tests” relationship.

Expected results describe the agreed behavior before execution. “Works correctly” gives the tester no decision rule. “Reject the refund, create no refund transaction, and leave the refundable balance unchanged” identifies observable effects. An error message alone is insufficient when the underlying financial state could still change.

Treat review state and execution outcome separately. A case can be approved for reuse while its latest execution has failed. If you use proposed states such as Draft or Approved, configure the process deliberately rather than assuming those labels already exist in Jira.

Worked Manual Test Cases for a Refund Limit

The following cases use an illustrative application and invented Jira keys, not a customer implementation or results from a product trial. Assume the agreed policy permits Finance users to refund up to the remaining captured balance. Support users can view and submit the fictional refund form, but submission must be rejected. These interface behaviors are scenario assumptions, not Jira controls.

The synthetic fixture contains EUR 100.00 captured and EUR 40.00 already refunded, leaving EUR 60.00 available. Use an approved payment sandbox and an isolated fixture instance for each case. The tester must be able to inspect refund history and balance through an authorized view. Capture the starting refund-history references before every case so the post-action comparison can identify new transactions. If that evidence is unavailable, fix the setup rather than guessing whether the financial state changed.

Refund the Remaining Balance

Case PAY-310, revision A: “Finance user refunds the remaining captured balance.” Link the approved case to the refund-limit acceptance criterion in illustrative story PAY-200. The objective is to verify the permitted upper boundary, not merely that a success message appears.

Preconditions: a Finance user is signed in; the fixture's captured amount, prior refunds, and remaining balance are verified; no refund is pending. Input: EUR 60.00. Maintainer: the payments QA owner. Priority: the team's high-risk payment category. These are proposed case values, not mandatory Jira fields.

Step	Action	Expected Result
1	Open the fixture order's refund form and inspect its starting state.	The displayed refundable balance is EUR 60.00 and the selected order matches the isolated fixture.
2	Enter EUR 60.00 and submit the refund once.	The application accepts the request and confirms a refund for EUR 60.00.
3	Refresh the authorized refund-history and balance view after the sandbox reports completion.	One new completed refund for EUR 60.00 exists, and the remaining refundable balance is EUR 0.00.

Cleanup: dispose of or restore this fixture through the approved QA procedure. Do not attempt to create the next case's starting condition by refunding this already exhausted order again. If the sandbox processes asynchronously, document the approved completion signal and waiting limit in the case before execution.

Reject an Amount Above the Balance

Case PAY-311, revision A: “Reject a refund above the remaining balance.” Reference the same refund-limit requirement. The objective is to verify rejection without a financial side effect.

Preconditions: a Finance user is signed in with a fresh fixture showing EUR 60.00 remaining and no pending refund. Input: EUR 60.01, exceeding the available balance by EUR 0.01. The fixture definition is reusable; the order instance must be independent of PAY-310's modified order.

Step	Action	Expected Result
1	Open the fresh fixture's refund form and verify its order and balance.	The correct order is selected and EUR 60.00 remains refundable.
2	Enter EUR 60.01 and submit the refund.	The application rejects the request and explains that the amount exceeds the remaining refundable balance.
3	Refresh the authorized refund-history and balance view.	No new refund transaction exists and the refundable balance remains EUR 60.00.

Cleanup: release the fixture reservation or reset it according to the approved procedure. The financial state should be unchanged, but temporary records or reservations may still need cleanup. Use the requirement's approved message wording if exact text is part of acceptance; otherwise specify its required meaning without inventing a mandatory sentence.

Reject a Refund Without the Finance Role

Case PAY-312, revision A: “Support user cannot create a refund.” Reference the authorization criterion in PAY-200. The objective is to establish that a user without the Finance role cannot cause the financial operation.

Preconditions: a Support user is signed in; this illustrative application exposes the refund form to that role; a fresh fixture has EUR 60.00 remaining. Input: EUR 60.00. Keep the account credentials in the approved secret store and record only a safe account reference.

Step	Action	Expected Result
1	Open the fresh fixture order as the Support user and inspect the active role.	The intended order is visible and the active identity has no Finance role.
2	Enter EUR 60.00 in the refund form and submit.	The application denies the refund because the user lacks authorization.
3	Inspect the authorized refund-history and balance view using the approved verification access.	No new refund transaction exists and the refundable balance remains EUR 60.00.

Cleanup: sign out and release or reset the fixture. If your application hides the form instead, rewrite the case for its approved interface and verification path. A hidden button alone does not establish that every refund entry point enforces authorization; additional interface or API checks need their own authorized scope and specification.

Record Actual Results in a Separate Execution Record

Create an execution record when selecting the case for a release or build. Use the installed app's documented run model, or an explicitly maintained linked record in an issue-only process. Copy the following execution labels without adding them as mutable outcome fields to the reusable specification:

• Case Reference: Case ID and the approved revision actually followed.
• Run and Attempt: A unique execution reference, with a separate attempt when a check is repeated.
• Release and Build: The deployed application identity, not only the intended release name.
• Actual Configuration: Environment, browser or device versions, relevant flags, and dependencies used.
• Fixture Instance: The dataset definition and the particular isolated order and account references used.
• Executor and Time: Who performed the check and when.
• Actual Results: Observations against the steps, including the first discrepancy and any checks not completed.
• Outcome and Follow-Up: The agreed result status, redacted evidence, and related defect or setup issue.

For an illustrative failure, PAY-311 on qa-build-a might display a rejection while still creating a refund transaction. Record the contradictory observations and mark that attempt failed under the agreed policy. Link the defect to the case revision and execution evidence. Do not change the expected result to match the faulty behavior.

After a fix, execute PAY-311 on qa-build-b with fresh starting data. If the request is rejected and no transaction appears, retain that new passing attempt alongside the original failure. These are hypothetical observations showing recordkeeping, not claims that testing was performed. If the required fixture cannot be prepared, record the setup problem and use your agreed blocked or setup-error status instead of treating missing evidence as a pass.

Check what your storage preserves. A link to a Jira issue whose Description changes later is not a frozen specification. Retain a controlled approved copy or a tool-supported version reference that lets a reviewer reconstruct what was executed. Verify your app's snapshot and reset behavior before relying on it; avoid overwriting an earlier attempt when recording a retest.

Review the Template Before Reusing It

Try the template on an existing case before creating a large library. The reviewer should be able to follow the specification without private explanations from its author.

1. Verify that the case identifies an approved requirement and a specific behavior, rather than combining unrelated branches into one ambiguous result.
2. Prepare the stated role and fixture from the instructions, checking that cleanup can restore a repeatable starting condition.
3. Follow each action and confirm that its expected result can be observed with the tester's authorized access.
4. Save an execution record with the actual build, case revision, data instance, observations, and outcome. Ask another reviewer to reconstruct what happened from that record.

When a requirement changes, review the affected preconditions, inputs, and expectations before approving the next case revision. Keep earlier runs interpretable against the specification they used. Start with a storage model your team can maintain, then add structured app capabilities where repeated execution and reporting justify them. The immediate test of the template is whether another tester can run the case and leave evidence that remains understandable after the next release.