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 not test management. But let's face it, Jira feels unnecessarily complicated at first, regardless of your position or goals. And since it's the gold standard for organizing and managing software development projects, of which quality assurance is an integral part, you have little choice on the matter.
That being said, Jira can (and should) be optimized to be equally efficient for developing, testing, and releasing new features.
In this article we talk about:
- Effective use of Jira in software testing
- Jira QA workflow optimization
- Writing and managing tests in Jira
- Additional tools and Jira plugins that can help you with 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 material suggesting that Jira was not designed for bug tracking and often lacks "this and that". This statement is true as Jira was not specifically designed for development, HR, acquisitions or marketing. It is a project management system designed to support team management.
That being said, teams themselves will use Jira differently. And some may have onepossiblyeasier time. For example, developers may not need to spend as much time in Jira as QA engineers because they don't need to create their tickets on a daily basis: they work on a handful of user stories per sprint. You, on the other hand, must back up these stories with evidence.
The key to finding a good balance where everyone can do their job effectively is to plan your processes in Jira to reflect the interests of all team members.
Process design with a Jira QA workflow in mind
Let's look at a few useful tricks and process improvements that can not only help QA engineers be more effective, but also improve the performance of everyone involved in a software development project.
Involve testers in the calculation of QA tasks
Quality control engineers are not usually responsible for providing cost estimates. However, this can be good practice as they have much more hands-on experience and can provide more accurate estimates for quality control tasks.
Let testers help prioritize bugs
Typically, QA engineers are pretty good at prioritizing bugs thanks to their experience with UX testing. Of course, a project manager can change these priorities based on business needs, but allowing testers to set initial defect priorities is beneficial.
As a tester, you should consider the following factors when prioritizing a bug in Jira:
- How often does it happen?
- What is the severity (how much does it affect the user)?
- Is the issue blocking core functionality or some other feature?
- On which devices/browsers does the error occur?
- Does the bug affect users in a way that they leave or leave negative reviews (was it previously caused by similar bugs)?
- How long has the bug been around (death by a thousand paper cuts is still around)?
- What other features will be added in this sprint and what are your priorities?
Make your dashboard more process-friendly
The iconic Kanban board is probably the first thing that comes to mind when you think of Jira. And if you've worked on multiple projects, you've probably seen them organized in different ways. The general approach sorts your issues into multiple columns ranging from "to do," to "in progress," to "resolved." However, you are not limited to a specific number of columns. Use this to your advantage.
I would suggest having more columns illustrating the path your problem must take before it can be considered solved.
I would consider the following columns:
- AGAIN
- development ready
- In progress
- ready for review
- ready for the exam
- at exams
- opened again
- ready to start
- Approved
Having a separate column for each phase might seem overwhelming, but only at first glance. This matrix gives everyone a good high-level overview and becomes an asset to the QA team.
QS-relevant problem areas
QA engineers usually don't need too many extra bells and whistles when dealing with problem areas. In fact, with some minor exceptions, testers mostly need the default settings. However, these small changes can make a big difference in the long run.
Here's an example of problem fields that I find useful in a QA ticket.
- Summary - This field contains a brief summary of the main issue, typically one line at most.
- Description - In this section you will find your prerequisites (if required), expected and actual results, steps to reproduce, device details, app version and environment information (unless you have specific fields for this information) and generally any other Delta that will help could reproduce the problemsinAsk for additional help from Quality Control.
- Issue Type - This field is typically assigned by the project administrator. You will decide if a problem is a story or something else. With this in mind, you should ensure that your QAs have the ability to create bug report tickets themselves.
- Officer: Self-explanatory.
- Priority - This field is used by the project manager or QA engineers to set the priority of a bug.
- Tags: This field is often overlooked. However, I find it an exceptionally good way to group inputs.
- Environment - This field can add many necessary details, e.g. B. whether the feature is in development or in the deployment phase. You can also specify hardware and software, e.g. B. Using Safari on an iPad Mini.
- Affects Version and Fix Version fields: These fields can also add a bit more context by clearly indicating the version of the software. This is useful as the QA engineer can easily understand the version of the application/software to be used for testing.
- Component Field - This field can be useful if you need to indicate if the product has multiple components.
- Attachments Field - You can use this field to add error screenshots, log files, or even video recordings of an issue.
- Related Issues - This field helps you link bugs to stories or epics for feature implementation if you know there is a relationship.
- Due Date - This field is useful for general knowledge and understanding when the issue should be fixed. Note, however, that this field should not be archived by QAs.
Note that I think this suggested list of fields is a good thing, but not a mandatory requirement. If you are certain that your process can omit some fields and just include more information in the description, do so.
The same goes for creating more fields. Yes, it may be tempting to formalize anything, but don't go too far. The more fields there are, the more time you spend filling them out. Even more so given the nature of the QA process, as you may need to build dozens at a time.
Cultivate the culture of right comments
Ticket feedback can be a goldmine for a QA engineer, as detailed and specific notes help uncover a lot about the feature. They can also become a rabbit hole of irrelevant fluff, as reading dozens of them wastes valuable time that could have been better spent elsewhere.
Jira is not Slack, nor should it ever be a messenger. Therefore, it's best for your team to use communication tools to discuss most of the details and questions, and to include any final requirements or needed context in the tickets.
hang tags
Any time you add details that should be relevant to a specific developer, mark them. Of course, the same goes 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 allows you to add custom statuses, tag users and set deadlines for each item individually.
underweight
Use many test kitsunderweightfor errors related to a feature ticket. This approach usually comes down to personal preference or the culture a team has developed. And it makes a lot of sense, at least on paper.
However, I would advise against it as the subtasks are not clearly visible on the board, making it difficult for the manager to check progress. Another reason to use separate tickets for bugs is that sometimes a decision is made to release a feature even though it has a few bugs, in which case they would love to be able to postpone it so it's ready.
A workaround would be to create separate issues and link them together. This way, you can still see the function that an error is linked to without negatively impacting the visibility of the dashboard.
Creation of the order book
A typical backlog consists of dozens of "medium" or low priority tickets. If left unattended, it will eventually become a black hole hoarding huge amounts of tickets that will never see the light of day again. But have you ever heard of the straw that broke the camel's back?
People who constantly experience bugs and minor hiccups will eventually move to a more stable solution. So you need to make sure that at least some of the backlog tickets make it to the sprint continuously. Some of the best practices I would recommend to ensure minor mistakes don't become a bigger problem are:
- Host regular sprints dedicated to lower-priority topics
- Commit to pulling a certain number (doesn't have to be very large) of tickets from the backlog in each sprint.
Sprint delay for automation
Covering a feature that is still a work in progress with automated testing can result in a lot of unnecessary work as things can (and probably will) change. Because of this, it's good practice to let your automator go back a sprint so you can script an entire function. The fact that the tickets were already covered with test cases is also a boon as it adds even more context. You must label these types of tickets correctly to avoid confusion.
How do I write tests in Jira?
We need to understand what tests are before we can properly write and run them. Fortunately, the concept is pretty far from rocket science.
Your typical test consists 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 might be to ensure that a user can only log in with valid credentials.
- Expected Result: An expected result is the behavior you would expect from a function when it is working correctly. Think of it as a requirement for success.
- Validation - This is the description of the method you use to test the function against the requirements.
Following these core principles will help you write, document, and run great tests. To use them specifically in Jira, do the following.
- In the title, indicate that the issue is a test case. Example: Test case: Login functionality.
- Please mention the necessary details in the description: Please share the test steps you will perform, such as: B. accessing the login interface and entering valid and/or invalid credentials.
- Communicate the 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 to ensure 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 for writing impressive test cases.
- Start by clearly describing the purpose of the feature and what it will do to the user. This goes beyond simply specifying the function and should also explain why having it is important.
- Define the user interactions and activities required to achieve the desired outcome. This ensures that all necessary steps in the testing process are covered.
- Specify the test case framework and methodology, including any relevant tools or techniques to be used.
- Use detailed steps that illustrate what to do, where to navigate, what button to click, etc. This helps the team understand and follow the test case.
- Prioritize test cases based on their importance and relevance to the project. This will help form the scope for smoke and regression testing.
- Always associate test cases with Jira requirements to ensure the testing process aligns with product specifications. This also helps to identify dependencies between the tested functions.
- Group test cases based on product components or user personas and use tags to categorize them. This will make it easier to manage and find specific test cases in the future.
- Include variations in the test cases by testing the product under different scenarios and conditions. This ensures that the product works as intended in all possible situations.
- Take advantage of additional tools and features available in the Atlassian Marketplace to improve the testing experience in Jira.
How to manage tests in Jira?
In general, there are two schools of thought when it comes to managing tests in Jira. One is quite simple and is based on using the features that are readily available in Jira. The other advocates using external products such as plugins available on the Atlassian Marketplace. Xray is probably the most popular plugin for testing, so I'll use it for my examples. But for now, let's focus on option number one: standard Jira.
use subtasks
As I mentioned earlier, you can use subtasks for testing, but this option has a number of disadvantages and limitations. So I suggest adding an additional issue type for test cases to your Jira instance. This approach allows you to use subtasks more effectively (yes, you need to create custom subtasks for this to work) as they are attached to a specific test case problem. And you will use them to send your test results.
To do this, you need to open the global settings of your Jira โ๏ธ instance and select the Issues option from the drop-down menu.
From there, you need to click the Create button and add your custom tasks and subtasks.
You then need to go to Schematics to add your newly created problem type. Just drag it to the left column.
Connect the newly created problem type to the test case resultswait for subtaskand use them for your quality control purposes.
The advantages of this approach are:
- This method is doable
- not necessarily too difficult to set up,
- and it won't cost you any extra money.
On the other hand, this cannot solve the challenges related to test case reuse, and there is little support for exploratory testing or test automation.
Use of Plugins
Then there is the possibility to use additional plugins from the market like the Xray mentioned above.
Xray is a testing tool that supports the entire testing process including planning, design, execution and reporting. To facilitate this process, Xray uses specific issue types in Jira.
At each stage of the test, you can use the following types of problems:
- Planning phase: Test plan issues are used to create and manage test plans.
- Design phase: The test and precondition problem types are used to define the test specifications. Test suites can be used to organize tests.
- Execution Phase: Test execution issues are used to run tests and track their results.
- Reporting Phase: Test execution issues are used to generate built-in requirement coverage reports. Custom issues can also be created using Jira Software tools to generate additional reports.
If you're new to Xray, it's a good idea to start with a small project and use Test Problems to create and run tests for your needs on an ad hoc, unplanned basis. You can learn more about this processHere.
The pros and cons of this approach are literally the opposite of using Jira's default functionality: you can get more done in less time, but the added convenience will come at a cost.
Use of checklists
As I mentioned earlier, there are two "conventional" ways to manage tests in Jira. However, there are some that are less common and usually involve certain combinations of the two. Checklists are a great example of an unconventional way of conducting tests.
Smart checklist for Jiraallows you, for example, to add checklists to your problems. the built-inMarkdown-Editorsimplifies your workflow as you can type or even copy and paste your tests. When writing tests, you can use the formatting options to your advantage. For example, you can use headers for test topic values, checklist items for test case values, and details for storing expected results. This way, your tests will have actionable statuses, assigned and due date capabilities, while still being attached to the parent ticket.
Diploma
Jira may seem overwhelming at first, but with complexity comes configurability and flexibility. You can customize the software to fit your processes, resulting in greater productivity within a unified hub used by every team in your organization.
Want to learn more about Jira?
- Learn how to integrate using feedback from outside your organizationCollector of anger
- Write assholeuser stories
- make it meaningfulProject plans in Jira