Jira
monday.com
While Jira is not the best tool for manual testing (it simply wasn’t built with QA in mind), it is – by far – the go-to choice for most software development projects.
Jira has gained its popularity thanks to its vast customization capabilities. In simpler words, there are ways to fine-tune it to meet the needs of a manual tester.
Moreover, it’s a two-way street: there are ways a QA engineer can utilize the tool to a greater extent.
Jira manual testing basics
Jira is built in a way where every task and subtask ends up in the “done” column. This is a challenge for manual testing as the fact that you are done with the case doesn’t mean you won’t be reusing the test case.
Fortunately, there are certain ways you can work around this limitation using the functionality Jira offers.
If you are working on a smaller project, User Stories and Sub Tasks should be 90% of Jira functionality you’ll need for manual testing.
This simplicity, however, does not mean that there’s no method behind it. For instance, you’ll need to include the following elements into your test case / user story:
- The steps you’ll need to take to reach a certain goal: be descriptive, but not too wordy. Having a numbered list that goes from the homepage to clicking on the contact button, to filling out the fields in the form is enough.
- Expected results: What do you want the user to experience when following the aforementioned steps? Should the form give an error message if an invalid sequence is typed in? And does it do so?
Sub-tasks bring the reusability into play. They’ll serve as iterations or individual test runs. Do note that, if you are using sub-tasks in this manner, you’ll need to label each of them with the
- Expected outcome
- Version
- Assignee
There’s a downside to using Jira in this way. For starters, the number of stories and subtasks you create will affect the sprint scope for the dev team. In addition to that, the growing number of tasks will be harder to manage on projects of a larger scale and scope. Some of the possible solutions would be to ask your Jira admin for help with setting up a dedicated testing project, or with creating a specific issue type for test cases. The latter option is preferable for times when everyone needs to keep their finger on the project’s pulse, as tracking the data in a single project is much simpler than managing several.
Manual testing using Jira: best practices
Now that we’ve covered the basic Jira setup, let’s dig a bit deeper into the meat of testing in Jira.
- Test cases: Writing test case descriptions is a monotonous, repetitive task. But think about it this way – the better a job you do at this stage, the more time (and budget) you’ll save in the long run. Try to be as clear and descriptive as possible:
- Always mention the “why” or the need for the feature to be present. This description is somewhat different from what a feature does as it needs to cover the benefit to the user as well as the functionality.
- Clearly define the activities a user needs to go through during their interaction with the product in order to achieve their goal.
- Mention the frameworks of the test cases.
- Add screenshots to illustrate the steps a user is taking better.
- Add prioritization: Select the correct priority for each test case. You’ll be able to form the scope for smoke/regression testing based on these priorities.
- Stay true to the requirements: the fact that teams keep their requirements in Jira is one of the strongest sides of the product. It is your job, however, to become the “bridge” between the documentation and the QA processes. Always link to the requirements as it is one of the clearest indicators of dependencies between the functionality you are testing. This approach will help you, the dev team, and business analysts alike.
- Group your test cases: You will be working with a lot of scripts. There will naturally come a time when they become unsearchable due to the sheer volumes of similar results in the system. One of the best things you could do to prevent this from happening is to categorize your tests based on product components (like testing scripts for administration) or user persona (for example, a registered user). Use labels for these categories when groupings when naming tests.
- Add variation to your test cases: It’s great when a system works well in an appropriate environment. But you don’t want your users to face an unpleasant surprise when using the software under heavy load or when the internet connection is down? Plan to run the same tests under different scenarios and conditions to truly make sure that the software is working as intended.
- Rely on additional tools and functionality that can elevate your experience inside Jira: the Atlassian Marketplace has a nice selection of add-ons you can use to better manage and run your test cases.
Add-on for manual testing with Jira
You can always use an integration of the tool you are already using, or add the missing bits of functionality with a handy add-on. For instance, you can use Smart Checklist’s templates functionality to create the steps necessary to run the test case once, and they’ll automatically be there once you open an issue of a certain type.
Our Jira Checklist allows you to make checklist templates for all kinds of recurring tasks like test cases. Decide which tickets you’d want to come with a pre-generated checklist, set them up once, and every following ticket that’s related to the process will come with this checklist from the get-go.
Smart Checklist allows you to automate templates even further through customizable extended conditions. These conditions go beyond issue type and cover request Type, priority, components, labels, reporter, standard custom fields, among others. Do note that this functionality is limited to the Server/DC version of the add-on.
Alternatively, there are excellent QA-specific add-ons like ZephyrSquad or QMetry for Jira. They can help you access and create tests from Jira issues, craft traceable reports or inject test definitions into tasks. You can learn more about these add-ons in our review.
