How to Automate Manual Test Case Writing from Jira Acceptance Criteria

For QA Leads who turn sprint tickets into test suites and want a repeatable team workflow for it.

The Ticket Already Holds Your Test Spec

By the time a story reaches Ready for QA, its acceptance criteria describe exactly what has to be true when the work is done. Writing test cases by hand from those criteria means re-typing the same rules as steps and expected results, ticket after ticket.

Evaficy Smart Test has a custom field built for this: Requirement. Text you paste there becomes a mandatory spec for generation. Every generated test case must respect it, and the full set must cover it. This guide maps a Jira ticket onto that field and the inputs around it, so your team gets the same quality of suite from every ticket.

Step 1: Clean the Ticket Before You Paste It

The generator reads everything you paste as part of the spec, so a focused Requirement produces focused cases. Spend a minute separating the testable content from the conversation around it.

If the criteria themselves are vague ("checkout should be fast"), fix them with the Product Owner before generating. The Acceptance Criteria guide covers how to make them testable.

Step 2: Map Jira Fields to Evaficy Inputs

Each part of the ticket has a natural home in the generator. Using the same mapping on every ticket is what makes the output consistent across your team.

Step 3: Pick the Test Type from the Ticket

The test type decides the angle of the cases. Functional checks that the ticket's criteria are met. Regression checks that existing behaviour around the change still holds. The ticket's issue type and workflow stage usually tell you which one you need.

Step 4: Generate the Cases

With the cleaned ticket and the mapping in hand, the generation itself takes a few clicks in the Test Case Selector:

Custom fields, including Requirement, are available on every plan. For how each input shapes the output in general, see Writing Effective Inputs for AI Generation.

Step 5: Build the Full Suite in Passes

One generation focuses on one test type and returns up to 10 cases, which is a deliberate size for careful review. A full suite for a ticket comes from running one pass per type you need, with the same Requirement text each time.

Saving one scenario per type keeps each suite labelled with the type it was generated for, which is how a scenario records it. Each pass uses one AI generation from your plan: the Basic plan includes 5 in total, Advanced 200 per month, and Enterprise 500 per month. A typical Functional plus Regression suite for one ticket uses two.

When the ticket's criteria change later, open the saved scenario: its Requirement field is restored, so you can update the text and generate the changed cases without rebuilding the inputs.

Worked Example: One Story, Two Passes

Here is a typical story as it appears in Jira, then the version that goes into the Requirement field.

PAY-412  Reuse a saved card at checkout
Status: Ready for QA   Component: Payments   Epic: Checkout v2

As a returning customer, I want to pay with a card I saved earlier,
so that I can complete checkout faster.

Acceptance criteria
- Saved cards are listed on the payment step, showing brand and last 4 digits.
- Selecting a saved card asks only for the CVC.
- Expired saved cards are shown as disabled with the label "Expired".
- A customer can remove a saved card; it disappears from the list immediately.

Dev notes: uses /api/v2/wallet, see PR #1881
Comments (6)  @dana can we reuse the old modal?  ...

PAY-412 Reuse a saved card at checkout.
As a returning customer, I want to pay with a card I saved earlier, so that I can complete checkout faster.
- Saved cards are listed on the payment step, showing brand and last 4 digits.
- Selecting a saved card asks only for the CVC.
- Expired saved cards are shown as disabled with the label "Expired".
- A customer can remove a saved card; it disappears from the list immediately.

The status line, dev notes, and comments stayed in Jira. Epic and component went to their own fields. The two passes then use these inputs:

The Functional pass targets the four criteria directly: listing, CVC-only payment, the expired state, and removal. The Regression pass looks at what the story touches: paying with a new card, the payment step for a customer with no saved cards, and the rest of checkout around it.

Step 6: Close the Loop Back to Jira

Run the saved scenario as a test run (see the Test Run Execution guide). When a case fails, log a defect and set its Linked Scenario. If your project has the Jira integration configured, push the defect to Jira from the defect view.

Team Conventions for QA Leads

• Generate when a ticket enters Ready for QA, so criteria are final and the suite is ready when the build lands.
• Name every scenario with the Jira key first, then a short description, then the type in brackets.
• Keep one shared cleaning checklist (copy / leave behind) so every tester pastes the same shape of Requirement.
• Have a second person review generated cases against the ticket before the scenario is used in a run.
• Treat a ticket that produces vague cases as a signal to sharpen its acceptance criteria, then regenerate.

Common Questions

Key Takeaways

• Clean the ticket first: keep the key, story, criteria, and rules; leave comments and dev notes in Jira.
• Paste the cleaned text into the Requirement custom field, which generation treats as mandatory.
• Map the rest of the ticket consistently: page to Affected Page, epic to Feature, component to Component.
• Pick the type from the ticket: Functional for new stories, Regression for fixes and changed flows.
• Build the full suite in passes, one scenario per type, each named with the Jira key.
• Defects pushed back to Jira carry the linked scenario name, so the key leads straight back to the story.