From Jira Ticket to TestRail in One Command

Everyone is talking about AI in development. Dozens, if not hundreds of articles drop every single day about how engineers use LLMs to write code faster, generate boilerplate, review PRs. Great. But what about QA? Specifically - what about the part of the team that doesn't write code?

I'm Olga Myronenko, Lead AQA Engineer at Techery. Our QA team covers both manual and automation, and this is a story about how we went from "AI sounds cool" to running one command and getting a TestRail section with ready-to-use test cases.

Where it started: Maryna's skill

Like most things in engineering, this started with someone getting tired of repetitive work.

One of our manual QA engineers, Maryna, decided to build a Claude skill for test case generation. For those unfamiliar - a "skill" in Claude is essentially a set of instructions that tell the model how to behave for a specific task: what rules to follow, what format to use, what questions to ask before generating anything. In practice, it's a markdown file with structured instructions that gets loaded into the Claude context before every generation run.

Maryna connected Claude to Jira via an MCP server so it could pull requirements directly from a ticket. Then she described the rules: how to name test cases, what goes into preconditions, how to label them, how detailed the steps should be, when to write a short focused case vs. a full end-to-end scenario.

The structure Claude follows for each test case looks like this:

Before generating anything, Claude asks clarifying questions if the ticket is ambiguous - things like "does 'disabled' mean hidden entirely or greyed out and non-clickable?" (because yes, that matters for the expected result). The questions are grouped and asked all at once, not one drip at a time, which is actually a relief.

After a few iterations of tuning the prompt, the output was solid. Test cases that actually covered the requirements, with proper structure and consistent naming. Maryna even added a copy button on each step in the output HTML page.

But - and there's always a but - the cases still had to be manually transferred to TestRail. One by one.

The gap that was too obvious to ignore

When Maryna showed me the skill, my first thought was: this is great, but why are we still doing the last step by hand?

We already had TestRail API integration in our automation codebase. The generation part was solved. The only thing missing was the bridge between Claude's output and TestRail.

Some people at this point would immediately think: "there's probably a TestRail MCP server for that." And they'd be right - that's a valid option, especially if you don't have an existing integration. But we did. And beyond that, I wanted to be deliberate about token usage: AI tokens should go toward analyzing requirements and generating test cases, not toward routine API calls that a plain script handles just fine.

So I wrote a Node.js script that handles the full pipeline: fetch the data from Jira, prepare the prompt, run Claude, and push the results straight into TestRail.

How it works now

The full flow, under the hood:

1. Jira fetch - the script calls the Jira API directly (no MCP) and pulls the ticket summary, description, type, and any image attachments.
2. Label selection - available TestRail labels are fetched, and you're prompted to choose which ones to apply to all generated cases.
3. Claude generation - the script sends the ticket data to Claude with the QA skill prompt attached. Claude may ask clarifying questions; you answer inline in the terminal (or just press Enter to skip a question and let Claude make a reasonable assumption).
4. TestRail push - a section is created (or reused if one already exists for that ticket) and all cases are added with the correct fields and labels.
5. Link - the script prints a direct URL to the TestRail section.

The command itself:

There are also two flags that turned out to be genuinely useful in practice:

--dry-run is particularly handy when you want to review what Claude generated before committing. It shows the section name, labels, and all test cases with step counts - nothing gets written to TestRail.

The terminal output during a real run looks something like this:

One detail worth mentioning: if the Jira ticket has image attachments (screenshots, mockups), they're automatically downloaded and sent to Claude as visual context. That turned out to be useful more often than expected - a screenshot of a UI state can answer half the clarifying questions before Claude even asks them.

The result

A manual QA engineer now runs one command, answers a couple of questions in the terminal (or skips them with a flag), and gets a direct link to a TestRail section with ready-to-use test cases.

No copy-pasting. No reformatting. No switching between Jira, Claude, and TestRail tabs.

What used to take 30–60 minutes now takes 5–10. That's not a small delta for something that happens multiple times a week.

The script also handles re-runs gracefully: if a section for that ticket already exists, it reuses it and appends the new cases there. Useful when requirements get updated mid-sprint.

What's next

There are plans to rewrite this using the Mastra framework to make the agent layer more structured and easier to extend. But honestly, for day-to-day use, the current script does exactly what it needs to.

The bigger takeaway isn't about the tech stack. It's that you don't need to be the person writing automation code to start using AI effectively in QA. Maryna built the skill - the core intelligence of the whole thing - without touching a single line of the script. The value was in knowing the domain well enough to describe the rules clearly.

That's probably true for a lot of roles beyond QA too.