I’ve heard a lot about Jira not being optimized for QA as, at its core, it is specifically a Project Management solution, and, therefore, it is not about test management. But let’s be honest here, Jira feels unnecessarily complicated when you get started with it, regardless of your position or goals. And given it’s the go-to standard for organizing and managing software development projects – of which QA is an integral part – you’ll barely have a choice in the matter.
That being said, Jira can (and should) be optimized in a way that is equally efficient for developing new features, testing, and releasing them.
In this article, we talk about:
Effective use of Jira in software testing
Optimizing Jira the QA workflow
Writing and managing tests in Jira
Additional tools and Jira plugins that can help your QA process
Jira for development VS Jira for QA
Let’s start with the elephant in the room. I’ve seen a lot of materials stating that Jira is not built with bug tracking in mind and that it is often lacking in “this and that”. This statement is true as Jira wasn’t built for development, HR, procurement, or marketing specifically. It is a project management system that is designed to help with, well, managing teams.
That being said, the teams themselves will use Jira differently. And some may have an arguably simpler time. Developers, for instance, might not need to spend as much time in Jira as QA engineers due to the fact that they don’t need to create their tickets daily: They’ll be working on a handful of User Stories per Sprint. You, on the other hand, will have to cover these stories with tests.
The key to striking a delicate balance where everyone can do their job effectively lies in planning your processes in Jira in a way that considers the interests of everyone on the team.
Designing processes with a Jira QA workflow in mind
Let’s look at a couple of handy tricks and process improvements that can not only help QA engineers be more effective, but improve everyone’s work on a software development project.
Include testers when you estimate QA tasks
QA engineers aren’t typically responsible for providing estimates. However, this can be a good practice as they have much more hands-on experience and can deliver more accurate estimates for QA tasks.
Allow testers to help set bug priorities
As a rule of thumb, QA engineers are quite good at prioritizing bugs thanks to their user experience testing background. Obviously, a project manager can change these priorities based on business needs, but it is beneficial to allow testers to set initial bug priorities.
As a tester, you need to consider the following factors when prioritizing a bug in Jira:
How often does it occur?
What is the severity (how much does it impact the user)?
Is the issue blocking main functionality or some other features?
What devices/browsers does the bug happen in?
Is the bug impacting the users in a way where they churn or leave negative reviews (have similar bugs caused it before)?
For how long has the bug been happening (death by a thousand papercuts is still a thing)?
What other features are also coming in this sprint, and what are their priorities?
Design your board to be more process-friendly
The iconic Kanban board is probably the first thing that pops into one’s head when thinking about Jira. And if you’ve worked on several projects, you’ve probably seen them arranged in a variety of ways. The general approach sorts your issues into several columns that move from “to do”, to “in progress,” and then to “done”. That being said, you are not limited to a specific number of columns. Use this to your advantage.
I’d suggest having more columns that can clearly illustrate the path your issue needs to go through before it can be considered done.
I’d consider having the following columns:
TO DO
Ready for development
In progress
Ready for review
Ready for testing
In testing
Reopened
Ready for release
Released
Having a separate column for every stage may seem overwhelming, but only at first glance. In reality, this array gives everyone a nice high-level view and becomes an asset for the QA team.
QA-relevant issue fields
QA engineers don’t typically need too many extra bells and whistles when it comes to issue fields. In fact, testers will mostly need the default ones with a handful of minor exceptions. However, these tiny changes can make a world of difference in the long run.
Here’s an example of issue fields I find to be useful in a QA ticket.
Summary: This field will have a short – usually one-line max summary of the main problem.
Description: This section will be the home to your pre-requisites (if needed), expected and actual results, steps to reproduce, device details, app version and environment info (unless you have specific fields for this information), and generally any other delta that could help with reproducing the issue withoutasking QA for additional help.
Issue type: This field is typically assigned by the Project Manager. They will decide whether an issue is a Story or something else. That being said, you need to ensure that your QAs have the option to create bug report tickets on their own.
Assignee: self-explanatory.
Priority: This field is where either the Project Manager or QA engineers themselves set the priority of a bug.
Labels: People often overlook this field. However, I find it to be an exceptionally good way of grouping tickets together.
Environment: This field can add a lot of necessary details, like whether the feature is in dev or staging. You can also specify hardware and software, like using Safari on an iPad Mini.
Affects Version and Fix Version fields: these fields can also add a bit more context by clearly stating the version of the software. This is handy because the QA engineer can easily understand the version of the app/software that should be used for testing.
Components field: This field can come in handy when you need to specify if the product consists of multiple components.
Attachment field: You can use this field to add screenshots with errors, log files, or even video recordings of an issue.
Linked Issues: This field will help you link bugs to stories or Epics for feature implementation if you know that there’s a relation.
Due date: This field is useful for general awareness and understanding of when the issue is planned to be fixed. Do note, however, that this field should not be filed by QAs.
Please keep in mind that this suggested list of fields is what I consider good to have, but they are not a hard requirement. If you feel comfortable that your process can skip some fields and simply hold more info in the description – go for it.
The same can be said about making more fields. Yes, it may seem tempting to formalize everything possible, but you shouldn’t go too far. The more fields there are – the more time you’ll spend on filling them. This is even more true given the nature of the QA process, as you may need to create dozens at a time.
Cultivate the right comments culture
Comments in tickets can be a gold mine for a QA engineer as detailed and specific notes will help discover a lot about the feature. They can also become a rabbit hole of irrelevant fluff, as reading through dozens of them will take away precious time that could have been better spent elsewhere.
Jira is not Slack, nor should it ever become a messenger. Therefore it’s best that your team uses tools that are meant for communication to discuss most details and questions and put the finalized requirements or needed context into tickets.
Tags
Whenever you are adding any details that should be relevant to a certain developer – tag them. Obviously, the same is true for engineers and managers who want a QA person to look at something specific.
Pro tip: You can use a checklist plugin to break down tasks into actionable items. Smart Checklist for Jira will allow you to add custom statuses, tag users, and set up deadlines for each item individually.
Sub-tasks
Many testing teams use sub-tasks for bugs that are related to a feature ticket. This approach usually narrows down to either personal preference or the culture a team has developed. And it makes a lot of sense, at least on paper.
That being said, I’d advise against it as sub-tasks are not clearly visible on the board, making it harder for the manager to review progress. Another reason for using separate tickets for bugs is that sometimes a decision can be made to release a feature despite it having some bugs, in which case, they’d really love the ability to move it to done.
A workaround would be to create separate issues and link them together. This way, you’ll still see the feature a bug is linked to without negatively affecting the visibility of the board.
Backlog grooming
A typical backlog consists of dozens of tickets with a “medium” or lower priority. If uncared for, it will eventually become a black hole that hoards copious amounts of tickets that never see the light again. But have you ever heard of the straw that broke the camel’s back?
People who continuously experience minor bugs and inconveniences will eventually shift to a more stable solution. Therefore you need to ensure that at least some of the tickets from the backlog are continuously making their way into the sprint. Some of the best practices I’d recommend to make sure that the minor bugs don’t become a major issue are:
Periodically having Sprints that are dedicated to lower-priority issues
Committing to pulling a certain number (it doesn’t have to be a large number) of tickets from the backlog into every sprint.
Sprint lag for automation
Covering a feature that’s still in progress with automated tests can lead to a lot of unnecessary work as things may (and probably will) change. That’s why having your automator lag one sprint behind so they can cover a completed feature with scripts is actually a nice practice. The fact that the tickets were already covered with test cases is also a boon, as they will add even more context. You’ll have to properly label these kinds of tickets to avoid confusion.
How to write tests in Jira?
We need to understand what tests are before we are able to write and execute them properly. Luckily, the concept is quite far from being rocket science.
Your typical test will be comprised of three parts:
The scenario: This is the basic idea of a test and is used to indicate what you are trying to validate. An example could be making sure a user can only log-in using valid credentials.
Expected result: An expected result is the behavior you’d expect from a feature when it is working correctly. Think of it as the requirement for success.
Validation: This is the description of the method you’ll be using to test the feature against the requirements.
Following these basic principles will help you write, document, and execute excellent tests. As for using them in Jira specifically, here’s what you should do.
Indicate that the issue is a Test Case in the title. Example: Test Case: Login functionality.
Mention the necessary details in the description: Share the test steps you will be taking, like accessing the login interface and entering valid and/or invalid credentials.
Share expected results in the description as well.
Creating test cases in Jira can be a tedious and repetitive task, but it is an essential step in ensuring the quality and functionality of a product. A well-written test case can save time and budget in the long run. Consider following these tips to write kick-ass test cases.
Start by clearly describing the purpose of the feature and its benefits to the user. This goes beyond just stating what the feature does and should also explain why it is important to have.
Define the user interactions and activities required to achieve the desired outcome. This will help ensure that all necessary steps are covered in the testing process.
Specify the framework and methodology of the test cases, including any relevant tools or techniques that will be used.
Use detailed steps that illustrate what to do, where to navigate, which button to click, etc. This helps the team understand and follow the test case.
Prioritize the test cases based on their importance and relevance to the project. This will help in forming the scope for smoke and regression testing.
Always link the test cases to the requirements in Jira to ensure that the testing process is aligned with the product’s specifications. This will also help in identifying any dependencies between the functionality being tested.
Group the test cases based on the product components or user personas, and use labels to categorize them. This will make it easier to manage and search for specific test cases in the future.
Include variations in the test cases by testing the product under different scenarios and conditions. This will help ensure that the product works as intended in all possible situations.
Take advantage of additional tools and functionality available in the Atlassian Marketplace to enhance the testing experience within Jira.
How to manage tests in Jira?
Generally speaking, there are two schools of thought when it comes to managing tests in Jira. One is pretty straightforward and relies on using the functionality that’s available in Jira out of the box. The other advocates for using external products like the add-ons that are available on the Atlassian Marketplace. Xray is probably the most well-known add-on for testing, hence I’ll be using it for my examples. But for now, let’s focus on option number one – vanilla Jira.
Using sub-tasks
As I mentioned above, you can use sub-tasks for tests, but this option has a series of drawbacks and limitations. Therefore, I’d suggest adding an additional issue type to your Jira instance for test cases. This approach will allow you to use sub-tasks more effectively (yes, you’ll need to make custom sub-tasks for this to work), as they’ll be attached to a specific test case issue. And you’ll be using them for submitting the results of your tests.
For this, you’ll need to open the global settings of your Jira instance , and choose the issues option from the drop-down menu.
From there, you’ll need to click on the create button and add your custom tasks and sub-tasks.
Then you will need to go to schemes to add your newly created issue type. Simply drag it into the column on the left.
Connect the newly created issue type with the test case results Jira subtask and use them for your QA purposes.
The benefits of this approach are:
This method is workable,
not necessarily too hard to configure,
and it will not cost you any additional funds.
On the downside, this can not resolve the challenges associated with reusing test cases, and there’s barely any support for exploratory testing or test automation.
Using plugins
Then there’s the option for using additional add-ons from the marketplace like the aforementioned Xray.
Xray is a testing tool that supports the entire testing process, including planning, designing, execution, and reporting. To facilitate this process, Xray uses specific issue types within Jira.
During each phase of testing, you can use the following issue types:
Plan phase: Test plan issues are used to create and manage test plans.
Design phase: Precondition and test issue types are used to define the testing specifications. Test sets can be used to organize the tests.
Execute phase: Test execution issues are used to execute tests and track their results.
Report phase: Test execution issues are used to generate built-in requirement coverage reports. Custom issues can also be created using Jira Software tools to create additional reports.
If you are new to Xray, it is recommended to start with a small project and use test issues to create and execute tests for your requirements in an ad hoc, unplanned manner. You can learn more about this process here.
The pros and cons of this approach are literally the reverse of using the default functionality of Jira – you will be able to do more in less time, however the added comfort will cost you.
Using checklists
As I mentioned, there are two “conventional” ways for managing tests in Jira. However, there are some that are less common, and they typically involve certain combinations of the two. Checklists are a great example of an unconventional way for managing tests.
Smart Checklist for Jira, for instance, allows you to add checklists to your issues. The built-in Markdown editor simplifies your workflow as you can type or even copy-paste your tests. You can use the formatting options to your advantage when writing tests. For example, you can use headers for test topic values, checklist items for test case values, and details to store your expected results. This way, your tests will have actionable statuses, and deadline and assignee functionality, all while being attached to the parent ticket.
Conclusion
Jira may seem overwhelming at first glance, but from complexity comes configurability and flexibility. You are free to mold the software in a way that fits your processes, resulting in more productivity inside a unified hub every team in your company uses.
Would you like to learn more about Jira?
Learn about incorporating feedback from outside your organization using the Issue Collector
Write kick-ass user stories
Create meaningful project plans in Jira