7 ways to structure software requirements and test cases in Jira

Katarzyna Kornaga - 23 May 2019 - 0 comments

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 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 to structure 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 overall project. In this article, we would like to present how you and your team can make the most of that RTM’s functionality.

Why is structurization so important?

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.

Beside 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 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.

7 ways to structure software requirements and test cases in Jira

1. Structure by priority

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 checking the Priority field, which one sets up on New Requirementand 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 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 a continuous progress.

2. Structure by feature

When 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 specificationdocument, 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 theDetails 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.

3. Structure by types of requirements

Business requirements – business cases usually created by investors, marketing departments, software designers or product managers in order to maximze profits or improve service in general;

UI requirements – actions and information available for users from the level of user interface;

Functional requirements – features of the final product with an objective to solve potential user’s problems;

Non-functional requirements – additional functions under development that are also important for the stakeholders.

Requirements of each type are equally siginificant. 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 colours and icons, 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 task to dispose 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.

4. Structure by environment

As folders and subfolders in RTM can be arranged however we see fit, the choice of your project’s requirements and test cases 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 conditions individually. That’s why in Test Cases we have a field named RTMEnvironment. 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.

5. Structure by Assignee

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’sgenerally known that a clear definition of people responsible for particular elements of the whole project motivates and speeds up the process.

6. Structure by testing level or type

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

Unit Testing – at this level individual features of a final product are tested in order to verify if each unit of the software works as designed. It’s worth remembering that this stage doesn’t require test cases, as unit testing is performed during coding. For tree-structured view it’s better to perform Module Testing where every module of a product’s system is tested one by one;

Integration Testing – level of a testing process where functionalities are tested as a group to prevent bugs that may occur during their integration;

System Testing – where the whole, combined product’s system is tested to check its compliance with presumed requirements and sometimes also with external software;

Acceptance Testing – final testing of a complete piece of software, where the goal is to confirm if the product meets all the business requirements, works in expected use cases and is ready to release.

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

Regression Testing – performed to make sure if the whole system and previously implemented cases work well, despite the changes made during further development;

Smoke Testing – relies on checking general functionalities to confirm if the product is ready for more detailled tests;

Stress Testing – testing the software in unusual conditions (for example when the memory of environment is full);

Performance Testing – verifies the final speed and effectiveness of the product.

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

7. Structure by softwareversion

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 are the consequences of changes. Modification of one unit can impact the other, not necessarly 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 to preserve an order in executed changes and makes it easier to track which version caused possible bugs. When it comes to organization of the objects by software version, we can distinguish two possible ways:

by Release Version – where we focus on all the released updates and extensions of our product;

by Fix Version, or actualizations resulting from bugs in the software. On the Defectstab, we have the Fix Version field, which can help with assigning particular test cases to the right version.

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.

Shape up your testing

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 RTMgives 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.

Kasia Kornaga is an Atlassian Apps Content Specialist, responsible for writing about requirements and test management on the Deviniti blog. She tries to discover and understand the mysteries of software testing process in order to share the knowledge with the readers interested in the subject. As an SEO enthusiast, most of all she values helpful, unique content where users can find answers to their questions, so she probably knows what you will look for before you even start. When she’s not writing, you can find her at the theatre, at home with a book or passing on city streets on her bike.

Yes, Deviniti can contact me about future job opportunities for up to 2 years

"I hereby accept processing my personal data by Deviniti Sp. z o.o. according to GDPR regulations, and agree on receiving information about this and further similar events sent by abovementioned."

Cookie Policy

By clicking "Continue" or continuing to use our site, you acknowledge that you accept our Privacy Policy. We also use cookies to provide you with the best possible experience on our website. You can find out more about the cookies we use and learn how to manage them here.