There’s a very good reason why more and more teams start using Jira for testing. The interface every Jira user knows well, extended with a dedicated test management app, turns out to be a perfect solution to track the whole software development process in one place. One of such apps, Requirements and Test Management for Jira (RTM), brings your organization of all the testing objects to a higher level.  The tool allows structuring Requirements, Test Cases, Test Plans, Test Executions, and Defects into transparent trees of folders and subfolders. That kind of view not only makes collaboration between all the stakeholders easier but also helps see how particular elements look in the context of the overall project. In this article, we would like to present how you and your team can make the most of that RTM’s functionality. 

When it comes to test management, the most valuable thing is time – and time is exactly what good object structure and work organization can give you and your team. Transparent folders and subfolders speed up defining priorities, assigning tasks to team members, and executing them.

Besides that, testing activities are strongly connected to each other: well-designed requirements, all covered by related test cases, minimize the number of possible defects in the end and thereby help to economize the time and effort spent on fixing them. Taking into consideration how many steps the whole testing process counts, we can certainly say that realizing them continuously is the only way to achieve the great quality of the final product. So it’s definitely worth a while to prepare an intuitive list of Requirements and Test Cases, which will help with setting up Test Plans and Test Executions later on.

Having said that, organization of testing elements must be adjusted to the type of the project and particular needs of the team. Below we present some ideas on how to structure requirements and test cases in Jira with RTM‘s tree view.

Requirements and test cases differ when it comes to priority: some of them have to be done as soon as possible, some can wait, and some are strictly connected to each other so it’s better not to proceed with them before finishing the previous ones. The best way to verify priority is by checking the Priority field, which one sets up on New Requirement and New Test Case creation screens. When they’re prepared, the tree view allows to arrange them from Critical to Trivial by putting the most urgent ones on the top of the list. Thanks to ‘drag and drop’ repositioning, modifying the order is simple and fast. Testing is a dynamic process, and that’s why the flexibility of a tool is so important. If priorities of the objects change throughout analysis or later, during test execution, RTM gives a possibility to easily adjust to all those changes and preserve continuous progress.

When the testing process of a product contains many requirements and test cases, categorization by feature will surely help with keeping track of what is going on with the project. On the screen below, product requirements are visibly organized in folders and subfolders. After preparing a software requirements specification document, it should be easy to design a similar scheme for test cases. Here we should describe which functionalities of the upcoming product should be tested to achieve the project’s goal, as well as find relations and dependencies between them. In Requirements and Test Management for Jira, it’s a good idea to enter Components and Labels on the Details tab and sort cases based on that information. Doing that at the very beginning prevents the risk of having a mess in the process later.

Structure by feature in RTM 

There are different types of requirements. To describe a project we can start with the basic four

Requirements of each type are equally significant. With the tree structure, it is simple to divide them so your list would be transparent for everyone who takes part in the process. Thanks to appealing data presentation, where the types have their own colors and icons, the organization of items is clear at a glance. On the Relations tab, we can see right away how many requirements of which kind have to be covered by related test cases and by that create a complete list of tasks to dispose of among testing team members. This kind of structure is best when you test a single product, otherwise, it may become a bit chaotic during execution.

Structure by types of requirements

As folders and subfolders in RTM can be arranged however we see fit, the choice of your project’s requirements and test case structure is wide. In order to be sure that your final product will work in all the environments you want it to, requirements have to be tested in every condition individually. That’s why in Test Cases we have a field named RTM Environment. Running test cases in various browsers, on desktop, mobile or tablet is absolutely necessary to not let yourself be taken by surprise when the product is released. In the process of testing on different systems, both requirements and test cases may be similar or even exactly the same. That’s why it’s smart to divide them by environment in order to spot the slight differences.

Structure in the RTM environment

Another example that shows how useful customized folders are is the possibility to structure requirements and test cases by Assignee. Imagine how much easier it would be for each team member to have a dedicated folder. It will certainly help to save time that would be spent on searching for the cases to be realized by each person. Well-organized objects eliminate the risk of double execution of particular test cases. What’s more, it’s generally known that a clear definition of people responsible for particular elements of the whole project motivates and speeds up the process.

When organizing Test Cases in RTM it is possible to sort them by testing levels or types. We distinguish four basic levels of test cycles:

Source: Software Testing Fundamentals

If it comes to types of testing, people name up to 9 of them and the most common are:

Managing test cases in Jira with RTM per testing level defines the order of their execution, and organizing per testing type sends a clear message to Jira users about what to focus on in each category.

Even after the big release of a software product, in almost every case we can be sure that there are updates coming. The common problem with new versions is the consequences of changes. Modification of one unit can impact the other, not necessarily in a good way. It’s important to control all actions and their results from end to end, especially in such a complex process. That’s why sorting test cases per software version allows preserving the order of the executed changes and makes it easier to track which version caused possible bugs. When it comes to the organization of the objects by software version, we can distinguish two possible ways:

As in Test Plans can be re-executed in our app, if something doesn’t go our way, we can always execute test runs all over again and spot the cause.

Methods we’ve listed before are only a few examples of how can you structure your software requirements and test cases in Jira using Requirements and Test Management for Jira (RTM). The truth is that RTM gives you the possibility to customize the tree view according to your project’s needs. Given that there’s no limit for nesting folders, you can use all the mentioned ways on one view! Make a good plan of collected requirements, assign test cases and bring your software project organization to a higher level.

If you’d like to test Requirements and Test Management for Jira (RTM) yourself, take a free 30-day trial from the Atlassian Marketplace.