Jira automation rules in software testing process

[#1]

The challenges of complex projects

Creating software is a complex process that requires numerous changes and modifications along the way. When we take into consideration how many team members work on gathering requirements development, testing, and other related activities we can imagine that there is really difficult to keep on track and know what everyone’s doing at the moment. The consequences of not being up to date can be costly for the budget, frustrating for the team, and in the end, delay the final release of the product. Misunderstandings lead to duplicating the work of other people involved, developing features that aren’t the project’s top priority, the general chaos in asks, and overwriting each others' data. The mistaken cases have to be done all over again and lots of engagement goes to waste, not to mention the time spent on fixing the errors as well as replanning the work from the very beginning.

Nobody wants this kind of situation. The good news is there are ways to eliminate or at least minimize the risks of complicated processes. What’s more these solutions aren’t necessarily surprising, as the key to success is nothing more than effective project management. The organization of particular steps of the from the start always pays off. In the present article, we’re going to explain how to do it.

This is where Atlassian’s Jira steps in

The tool supports all kinds of teams in achieving their business goals. The intuitive, well-known software enables to create a structure of transparent relations between the tasks of the company’s employees and automatically informs the co-workers about the modifications implemented inside and across the teams. Multiple types of issues and categorization models allow us to individually design the way of administration that fits the specific project’s needs. Jira Software enables real-time cooperation on the highest level, which appears to be completely indispensable nowadays when working remotely became our dailiness.

Jira’s functionalities make it much easier to control the complex activities in IT-related processes. One of the examples of these processes is testing. Starting from collecting requirements through assigning test cases, creating test plans, executing them, and finally reporting defects to fix, it includes many different stages that have to be performed. Tests involve the work of business analysts, product owners, managers, testers, developers, and many more stakeholders. This is why it’s crucial to make it possible for everyone to stay up to date. We strongly recommend using Jira with a dedicated test management extension for the purpose. Hexygen’s Requirements and Test Management for Jira is a great choice because it covers each step of the process and is embedded into the Atlassian’s product. Thanks to this it’s maximally user-friendly and can be easily managed by all the team members familiar with Jira interface, no matter their testing experience.

Jira automation rules in Requirements and Test Management (RTM)

In order to make using RTM for Jira even more successful, we found a way to implement Jira native functionalities into our app. Jira’s automated rules allow to immediately inform the users about all the modifications made throughout the process. It turns out to be extremely useful when it comes to testing. As in Requirements and Test Management the testing objects are configurable just as Jira issue types, seamless integration with the Atlassian software is possible and intuitive. As for now, we focused on the four rules, which in ours and our customer’s opinion were the most needed along the testing journey.

Rule 1: Update issue status based on related issues

In Atlassian’s Jira we distinguish tasks and subtasks, the main issues, and linked elements that are related to them. The structure reflects exactly the one that can be made between the testing objects, like for example RTM’s Test Cases and Test Plans. In this case, a Test Plan would be the main issue and linked Test Cases - the specific subtasks. Remember here that links that connect the testing elements in Requirements and Test Management in Jira are set up by default from advance. It means that in order to use this automated rule with our testing extension, you have to indicate in the rule’s details the link name that you use whilst working with RTM.

Let’s imagine the situation where all the particular Test Cases are classified as Reviewed or Accepted, so we would like to automatically mark the whole related Test Plan accepted. Or, where we know that a specific Test Plan is ready to be executed and for some reason not all of the included Test Cases are properly tabbed yet because for example the tested functionalities were checked whilst testing others or the assigned person just forgot to mark them accordingly, which can happen when there are numerous objects to take care of. It can be done manually, but we would have to scroll through all the elements and find the ones that are missing. If we have the automatic rule set up, all these activities will be done instantly after the modification. Moreover, whilst setting up the Rule details we can determine who to notify about the possible errors or risks so that using automation wouldn’t cause any ommissions throughout the process.

Screen from setting up an automated rule about an issue status update based on the related issue

Rule 2: Change issue status upon issue edition 

The second rule turns out to be useful in the case of all testing elements during the process, equally when it comes to Requirements, Test Cases, Test Plans, Executions, and Defects. When one of the team members changes something in one of the objects, like for example the Assignee, Priority, or Environment we should assume that this element should be reviewed, as the comments or its status assigned before may no longer be up to date. This is where we can use the “Change status on edit” rule - to make sure the given object still has an acceptance of all the stakeholders. If we set it up accordingly, it can automatically change the edited issue’s status to In progress. Thanks to this, it will be easy to check on the RTM’s Test Plan or Test Execution view that this particular object on the list is yet to examine. 

How to set up an automated rule which enables changing issue status upon its edition

Rule 3: Notify watchers of related objects about changes after issue edition

The third rule is about sending information to all indicated users, for example, Assignees, Watchers, or Reporters, about the modifications of their objects of interest (or some/all of the issues related). How this rule can be applicable in testing in RTM for Jira? In our app, Test Cases are assigned to related Requirements, gathered at the beginning of the process by the stakeholders responsible. Each person working on a Test Case would like to know if there were any changes made on the linked Requirement. Testers work usually involves checking if a specific functionality works in given conditions and environment. Once the related Requirement changes, gets rejected or its acceptance is withdrawn, it means unnecessary work and wasted time of a team member responsible for verifying it.

Business analysts, managers, or customers don’t always remember to inform all of the team members about the change they made in the Requirements module. They focus mostly on this first, very important stage of the process. In order to avoid misunderstandings and unnecessary overslipping, it’s a smart idea to apply an automated e-mail notification rule, like it’s shown in the example below:

An automated rule in Jira which makes it possible to notify about changes made after issue edition

Rule 4: Notify watchers about object changes after an issue link is added or removed

Last but not least: the fourth automated rule. It’s quite similar to the previous one. It also concerns informing the team members involved (Assignees, Watchers, Reporters, people called out in the comments section, administrators, etc.) about the changes made in the given issue. The difference is that this time, the rule notifies about adding or removing the linked issues to the specific objects. In Requirements and Test Management for Jira, the whole testing process is ordered and put in a logical way, where users intuitively pass through all the stages one by one. Test Cases are included in Test Plans, which are finally executed. But what if during the Test Execution, someone adds a new Test Cases to Test Plan, or removes one? It can be crucial to the process and change a lot, so it’s undoubtedly best to know about it as soon as possible. Thanks to this, the team can re-execute the plan and make sure that everything works as it should be.

This is where we use the fourth rule. Not only we can inform the people interested in the object about the change and who made it but also send them a message with a suggestion of a solution (like considering to go through the Test Plan all over again):

An example of a properly set up automated rule in Jira which enables to notify watchers about changes after an issue link in RTM is added

An automated rule in Jira which notify watchers about changes after an issue link in RTM is removed

Note: Remember to set up two different rules to notify about adding as well as removing related links to the testing objects!

Everything can be done manually by the team members involved in the testing. But as simple as it sounds, we should benefit from the convenience of automation processes. Not only it speeds up the whole work but also eliminates typical “human mistakes”, which happen quite often when it comes to the complex IT process. This is why once again we encourage you to apply Jira possibilities into Requirements and Test Management and make the most of both. See for yourself how smoothly the two tools cooperate and support driving your results to the highest level!