Jira Test Runs: What's the Way to Manage Manual Test Execution?

Question

Selecting the right way to manage Jira test runs can make a huge difference to how effectively teams plan, execute and track manual testing.

We've been using Tuskr alongside Jira for our manual testing workflows, and it's been a good experience. It lets us organize test runs, assign testers, record pass/fail results, and link defects back to Jira without making the process overly complicated.

How are you managing Jira test runs? Are you using Xray, Zephyr, or another test management solution?

I’d be interested to know what you’re using, what features you like best, and what challenges you’ve encountered. Your experience would be really useful for teams looking at options.

Olga Cheban _TitanApps_ · Answer

Hi @Vinayak Wagh !

Manual test execution in Jira is one of those areas where the right setup makes a real difference. Especially when you're tracking which steps passed, which failed, and who ran what.

Dedicated test management apps like Xray, Zephyr, and QMetry give you full test planning and reporting capabilities. But you might not need a full testing platform. A lighter approach can cover most manual execution needs directly inside your existing work items.

One option worth considering is our solution, Smart Checklist for Jira. You can build a test case as a checklist inside a Jira work item. Each check corresponds to a step in the test. You can also set up custom statuses like Passed, Failed, Blocked, or Skipped for each item.

A few things this makes easier:

Assigning specific steps to responsible teammates

Tracking progress from the agile board and via JQL

Saving test cases as full work item templates and reusing them across runs

You can also convert a failed checklist item into a Jira sub-task with one click. This turns a failing step directly into a logged bug.

For a broader view, you might find my article "How to optimize Jira for QA needs" useful. It walks through work types, custom fields, and workflows in more detail.

You might also be interested in my step-by-step guide on How to build a Jira test case template like this one:

This template was created with our solution Smart Templates for Jira, which integrates seamlessly with Smart Checklists.

I hope this helps!

Balázs Szakál _BTStudio_ · Answer

Hi @Vinayak Wagh ,

as the developer of BesTest - Requirement and Test management app, we are using BesTest for test management - obviously! :D

Previously

* I created requirements in it, so that we have a focused state what we want to deliver
* developed the app, updated tickets in Jira
* created test cases, and connected them to cover requirements* checked the reports if any coverage is off

* executed the tests in the test player* reported bugs, if found any

Later, as they were aded

we built dashboards to track release progress.

Now

we use MCP all day.

It helped us find tons of bugs, gaps in the coverage, and in general, moved our complete requirements and e2e testing results into the app, ai-driven way. So i would say this is an evolutional jump, compared to manual testing. If you have manual + automated testing, this can still work out pretty well, you can create manual test cycles and let the agent post the automated test results via MCP or REST.

The biggest win was that we discovered tons of coverage gaps and to visually see our req-test traceability.

Cheers and good luck with testing!

Nikola Perisic · Answer

Hi @Vinayak Wagh

In my experience for test management, I was using Xray, but manual testing doesn't require that much of custom development like the Xray. Xray creates new work item types, which can be done natively. For test cases, you can create a new rich text field and add a default context for that test case covering. For test planning, I would rather be using Confluence, because it has a more documentation and planning approach.

For having the tests being executed, the status should be reflected with workflow statuses (Passed/Failed -> Development Ready). From here, when the work item gets in the Dev ready status, an automation rule can be created with the placeholder [DEVELOPMENT] or something similar which will create that work item in the space that is being used by developers. Rarely you would see this, but if this is strong QA focused, I find that two Jira spaces would be created one for devs other for QAs.