Gist
Hash Agile built a proof of concept combining LLMs, the Jira MCP Server, and Cline (in VS Code) to auto-generate structured manual test cases from Jira acceptance criteria. This cut test case creation time from ~30 minutes to under 2 minutes while keeping engineers in control through review and approval. Output quality depended heavily on how clear the acceptance criteria were, not just the AI model. The key insight: seamless workflow integration—not automation alone—was what made the tool genuinely useful, freeing QA engineers to focus on deeper testing rather than documentation.
Every QA engineer has experienced this at some point.
A user story is finally ready for testing. The acceptance criteria are clear, the feature is well understood, and you're eager to begin validation. But before testing starts, there's another task waiting which is creating manual test cases.
It's an important step, but it's also one of the most repetitive parts of the testing lifecycle. Every story demands the same discipline: read the requirements, identify scenarios, organize them into a standard format, and document everything before executing a single test.
At Hash Agile, we started asking a simple question.
Could we remove this repetitive effort without changing the way QA engineers work?
That question led us to build a proof of concept that combines Large Language Models (LLMs), Jira MCP Server, and Cline to generate structured manual test cases directly from Jira acceptance criteria. The outcome wasn't just faster documentation. It demonstrated how AI can strengthen an existing engineering workflow while leaving engineering judgment exactly where it belongs—with the QA team.
Solving the Right Problem
The goal was never to automate testing.
It was to automate the documentation that comes before testing.
Most engineering teams already have everything needed to create quality test cases. The acceptance criteria live in Jira, teams follow a standard template, and experienced QA engineers know how to interpret business requirements. The challenge is the manual effort required to convert those requirements into structured test cases for every story.
As projects grow, that repetitive work consumes valuable engineering time that could be spent on exploratory testing, edge-case validation, or improving product quality.
We believed there was a better way.
Designing Around the Engineer
Rather than introducing another standalone tool, we wanted AI to fit naturally into the workflow our engineers already used.
The proof of concept connected three capabilities into a single experience.
The Jira MCP Server provided a secure bridge to Jira, allowing AI to access ticket details without bypassing existing controls. Cline, running inside Visual Studio Code, became the interaction layer where engineers could simply describe what they wanted. The language model interpreted the acceptance criteria and generated structured manual test cases using our predefined template before posting them back to the Jira ticket.
The workflow remained familiar. Engineers didn't have to copy requirements between applications or learn another platform. More importantly, they remained in control throughout the process by reviewing and approving actions before they were executed.
That design decision mattered more than the technology itself.
What We Learned
One of the biggest observations from this exercise was that the quality of the output depended far more on the quality of the acceptance criteria than on the AI model.
When requirements clearly described business rules, expected behaviour, and edge cases, the generated test cases were comprehensive and consistent. Ambiguous requirements, on the other hand, produced equally ambiguous outputs.
The proof of concept reinforced something every experienced QA engineer already knows: AI can accelerate documentation, but it cannot replace clear thinking.
Another interesting takeaway was that workflow integration mattered more than automation itself. Because the generated test cases were created and added directly within Jira, engineers didn't have to switch between multiple tools or spend time formatting documentation. The technology blended into the development process instead of disrupting it.
The Results
The impact was immediate.
Tasks that previously took around 30 minutes were completed in under two minutes. Test cases followed a consistent structure, reducing formatting effort and improving documentation quality across stories.
The same approach also showed potential beyond functional testing. Depending on the acceptance criteria, the workflow could be extended to generate performance scenarios, security-focused test cases, and other forms of validation, opening new possibilities for AI-assisted quality engineering.
More importantly, our QA engineers spent less time documenting what they already understood and more time focusing on what actually improves software quality.
Looking Ahead
This proof of concept wasn't about proving that AI can write test cases.
It was about proving that repetitive engineering tasks can be simplified without compromising engineering judgment.
As AI becomes a practical part of software delivery, the opportunity isn't to replace experienced engineers. It's to remove the repetitive work that slows them down and give them more time to solve meaningful problems.
At Hash Agile, we see this as one example of a broader shift. The most valuable AI solutions won't be the ones that introduce entirely new ways of working—they'll be the ones that quietly improve the workflows engineering teams already trust.
That's the kind of engineering challenge we're excited to keep solving
