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

[Vinayak Wagh]

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.

[Nikola Perisic]

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.

[Balázs Szakál _BTStudio_]

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!