Vanilla Set-up for Test Management in Jira

Test management is an essential part of delivering reliable software. It connects requirements with verification, provides a systematic way to check functionality and ensures traceability when defects occur. Many teams want to manage their testing inside Jira, since it already serves as the central platform for requirements, bugs and release planning.

The biggest challenge, however, is the implementation of executions. There are two main approaches:

• Test Execution represented as a sub-task of a Test Case.
• Test Execution represented as a separate work type.

This article focuses on the second approach. Using sub-tasks can quickly become problematic, since they do not scale well and lack flexibility for reporting. Instead, we will use Jira Automation to create new Test Execution work items from Test Cases.

Jira Configuration

To build a workable test management setup in Jira, without any additional tools, follow these steps:

• Create a Software, company-managed project This project type gives you maximum flexibility with workflows, work types and fields.

• Add new work types: Test Case – it will be used to define the scenario, steps and expected outcome and Test Execution – this will be used to capture the actual result of running the case. Remember to also include standard Jira work types such as Epic, Story and Bug to ensure traceability.

• Add new workflows Suggested workflows might look like this (available to preview also here)

Test Case: Draft → In Review → Approved →Archived

Test Execution: To Do → In Progress → Passed/Failed.

• Add a selected custom field for the testing environment Jira includes a system Environment field, but it is free text. By creating a selected field (e.g., Staging, UAT, Production), you gain consistency and avoid typos.

• Add a custom link type Define a relationship like tests / is tested by in order to connect Epics or Stories with Test Cases. This creates a simple form of traceability.

• Define versions Under Project Settings, create versions such as 1.0, 1.1, or 2.0 to indicate release targets for Test Executions.

Automation to Create Test Execution

Automation is the key to reducing manual work and ensuring consistency, so it can become incredibly handy while managing the testing process in Jira While the possibilities when it comes to rule automation are endless, we suggest the following rule:

• It clones the Test Case into a new Test Execution work type.
  
  
• It copies the description along with the Test Steps.
  
  
• When the rule is triggered, Jira prompts the user to provide values for Environment and Version (using the “Prompt for input” option).
  
  
• The newly created Test Execution is linked back to its parent Test Case.
  
  
• The rule can only run from Test Case issues to keep the process controlled.
  
  

The result is a lightweight mechanism that generates a reusable execution entity with minimal manual setup.

Automation Rule for cloning a Test Case to create a new Test Execution.

Running the Process

1. Open any Test Case work item.
   
   
2. Trigger the automation rule.
   
   
3. Enter the requested values for Environment and Version.
   
   
4. Jira creates a new Test Execution with all the Test Steps and fields from the original case, plus the chosen environment and version.
   
   

This allows the same test to be executed multiple times in different contexts, while maintaining a clear history of what was tested, when and where.

Test Execution work item created and updated with the help of Jira Automation.

Pros and Cons of This Approach

Pros

• No additional apps are required, which means lower costs.
  
  
• Uses only Jira’s built-in configuration, making it easy to start.
  
  
• Keeps all work items (Epics, Stories, Bugs and Tests) in one system.
  
  

Cons

• Lacks advanced test management functionality such as test cycles, reusable runs and structured traceability.
  
  
• No built-in reporting on coverage or release readiness.
  
  
• Manual effort increases significantly as the number of test cases grows.
  
  
• Limited support for automation and scaling in enterprise environments.
  
  

Beyond Vanilla Jira

While this vanilla version of Jira can handle the basics, it is not designed as a full test management solution. Teams that need structured test entities, clear traceability and meaningful reporting will eventually run into its limits.

This is where ATM (Appsvio Test Management) comes in. ATM is a Jira add-on built on Atlassian’s Forge platform, which means it runs natively within Jira Cloud and follows Atlassian’s latest standards for performance and security. Unlike the vanilla setup, ATM introduces dedicated concepts such as Test Cases, Test Executions and Test Cycles. It also provides reporting features that help track coverage and release readiness.

With ATM, teams can:

• Define and manage test cases in a structured way.
  
  
• Create executions across multiple environments and versions without workarounds.
  
  
• Maintain traceability between requirements, tests and defects.
  
  
• Use built-in reports to understand progress and quality trends.
  
  

ATM is also the only test management app that holds the Runs on Atlassian badge, a mark that confirms the app is hosted and operated directly within Atlassian’s infrastructure. This ensures tighter security, compliance and reliability compared to traditional Connect-based apps.

👉 Explore ATM on the Atlassian Marketplace

Conclusion

Test management in vanilla Jira can be achieved with some creativity—custom issue types, workflows, and automation rules. This approach is cost-effective and works well for smaller teams. However, the lack of reporting, traceability and scalability makes it difficult to rely on for larger projects.

For organizations with broader needs, dedicated apps such as ATM provide robust functionality directly inside Jira. These tools make test management more efficient, scalable and aligned with modern software delivery practices.