You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
The article has been originally written by Magdalena Korgul
Keeping the documents organized may take some time at first, but after you developed a plan or order, it takes a lot of stress off of you. A number of studies confirm that a neat and tidy environment affects the way we work. A clean desk, organized documents, and a proper work plan can save even hours of our workday. It’s no different for any type of office work.
We asked our Apps Quality Assurance team how they organize Requirements and Test Cases in Jira. In this article, we’ll present to you how the Page Object methodology helps in keeping the work well-ordered and what tricks we use while testing in RTM – Requirements & Test Management for Jira.
The impact of our environment’s cleanliness on our work may be larger than we expect. Sometimes, you may feel it in your bones – when you sit at a tidy desk, just in front of your laptop, the work somehow progresses smoother and faster than when you have to cut your way through the mugs collected this week and a pile of paper. And the researches confirm your intuition – the cleaner our space, the easier the job. According to the study published in Current Psychology, people with a tendency to clutter in their homes are more likely to procrastinate. Employees themselves agree to that. This Brother survey shows that 40% of employees admit that an untidy workspace makes them less productive, and 1 in 3 office workers can miss an opportunity of promotion because of their messy desks.
That is enough to claim that keeping your desk, but more importantly, your work, organized – helps you to be more productive and less stressed. How to implement it while testing in Jira?
Although Jira was not made for test management in the first place, with a little help, it can be used as one. It doesn’t have a built-in testing technology, but there are plenty of apps on the Atlassian Marketplace that are made just for test case management. One of them is Requirements & Test Management for Jira (RTM) made by our Deviniti team. It allows for collecting Requirements, writing Test Cases, and then grouping them into Test Plans. Thanks to the possibility to collect Requirements and Test Cases in tree structures, tracing the progress and preventing the additional bugs is much easier.
In Deviniti, we use RTM in two teams: one responsible for creating and developing the application and in our Apps Quality Assurance team. We’ve talked to our testers and asked them, how they organize the Requirements and Test Cases for easier project management.
Requirements & Test Management for Jira wins with its simple and transparent layout. In just a glimpse of an eye, we can see all the elements that will be necessary for us to proceed with the testing process from A to Z. While starting with the app, on the left side of the screen, we can see the list of the features that RTM provides. Here, we have Requirements, Test Cases, Test Plans, Test Executions, Defects, and Reports. RTM is easy to use and transparent thanks to the division into categories.
How did our team put all the functionalities together and organized the requirements? The app’s product owner, responsible for organizing the work, arranged the folders. The folders are arranged according to the views we have in the app, but also according to the functionalities, eg. Onboarding view, Tree, and Flex search view. Each folder houses epic tasks (containing features with smaller tasks) and stories – lesser tasks. A tree-structured view with folders and subfolders allows us to have all necessary elements within reach and check the requirement status in Jira faster.
Once the test cases are written by the tester, the product owner assigned test cases to cover the requirements. When clicking on the particular Story, we can see a detailed view and the Test Case tab. Here, we can check the Test Cases that cover this particular Requirement. This kind of organization allows the tester to make sure that his tests are written on the basis of a certain requirement. The product owner, on the other hand, can be assured that the requirements are being covered based on the specific test cases.
On the last level, the views are organized into additional folders based on the task status. Already executed tasks are moved to different folders. Thanks to this, the support team can be up to date with the planned requirements for a given view. We also copy the task structure while organizing epics. Stories that are created from the epic are placed in the structure below the epic so that the relation between epics and stories is clear.
In the Test Case module, we have our tests categorized in folders and subfolders. In our team, the test cases are organized according to the “page object pattern” module, as so-called Views. We can choose, eg. the Requirements view with the Test Cases covering all the functionalities that we have in the Requirements view. What’s more, each test Case contains the Relations tab that enables quick access to requirements in a given Test Case and enables the tester to view the requirement’s body easily.
But folders are not the only idea to keep all our Test Cases organized. In every summary of the Test Case, the tester writes which view the given Test Case can relate to. Such descriptions are necessary to conduct and invaluable in the event of a sudden change of tester taking care of a given Test Case or even in absence of time. Now, we can quickly see what area this Test Case concerns. We don’t have to go through the individual steps and get acquainted with the details.
Based on the Test Cases, Test Plans are created. These are for example regression tests, new features, or automated tests. It allows us to create a clear structure, where folders are organized by release, so we can have an overview of the chronology of the Execution Tests performed in previous releases. Each Test Case can be added to several Test Plans – it all depends on our needs and the tests’ extent.
Jira requirements management can be easier when we implement some visual aids. In both Requirements and Test Cases views, apart from descriptions, we use emoticons. Contrary to appearances, they don’t cause chaos in the app – quite the opposite. We found out that using emojis is helpful for visualizers. Each emoji has its meaning and appropriate marking of Requirements and Test Cases allows for quick identification of the element we’re looking for.
Some Test Cases have a robot icon next to them, which means that this particular test has been automated. Now, we can see which test cases are automated, just by looking at the Test Cases tree.
We also use a blue heart emoji that tells us which test cases are planned to be automated in the near future. Of course, you can mark your test cases with any emoji available emoji. It all depends on which information will be the most important for you to gain just by peeking at the tree.
What are the results of a good organization of our Requirements and Test Cases in Jira? It brings great benefits for the testers, the product owner, and the whole development team. Without it, anyone apart from the testers wouldn’t have the chance to keep up with the tester’s work. No formal documentation equals no insight into the currently tested functionalities.
Lack of proper organization would also disturb the work of the test team itself. Only order in the documentation allows the tester to avoid the stress caused by the fact that they don’t know what next steps to take, so they have to improvise.
Last but not least, proper ordering is essential for detecting what we dislike most – bugs. Testers, while performing Test Executions, immediately attach bugs to them. As a result, app users can see what bugs were resolved in the past and track the chronology of repairs. The testers now have a base of defects – they can go back to them and check whether a certain bug didn’t appear again. Thanks to the documentation we don’t have to remember the particular bugs, because everything is documented.
Martyna Wiśnik [Deviniti]