Test documentation is a critical aspect of testing applications: teams need to write test plans, test scenarios, and chart out testing workflows. Most of this is handled in some kind of test management tool, though that could require extra costs and yet another system to work in. If you don’t have an official test management tool, Jira offers enough configurations for both manual and automated testing workflows. Let’s take a look at setting up Jira for a team’s QA processes.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
Testing Workflows
It’s important that QA is involved early in the lifecycle of a feature. QA involvement can and possibly must start before an Epic is ever entered into Jira. As soon as an Epic and associated stories are introduced to a feature team, QA can kick off their own testing workflows.
A typical workflow for teams consists of work for both manual testers and automation engineers (AQA).
Epic Introduced to Team
- Testers provide estimates for any testing effort
- Manual testers gather test cases and write any necessary new ones
- AQA create automation skeletons in preparation for features that are ready to test
Stories Become Ready to Test
- AQA prepare test environments
- Manual testers execute test cases
- AQA create automation around new features
- AQA execute any existing automated tests
- QA team create bugs for issues found
Though this defines a basic structure for development and testing, incorporating some early pair testing can help reduce the churn of fixing bugs. Oftentimes, bugs can be found, fixed, and verified in one quick session between a developer and tester.
Stories Pass Testing
- Manual testers include testing results for a feature
- AQA Engineers complete test automation
There are plenty of moving parts with testing features and that complexity only grows when teams have multiple stories on their boards. However, Jira offers some options that can help keep testing manageable. One such option is the Sub-Task.
Jira Sub-Tasks
Sub-tasks are tasks for each Epic or Story organized and visible for the team. They can be created for both manual and automated testing efforts so teams can then assign specific tasks to members responsible for them.
How would this look for testing?
In many projects, Epics are used for simply organizing a large body of work. Teams may not work directly against Epics, so in these scenarios individual Stories are better suited for QA sub-tasks.
For projects where both Epics and Stories are pulled into an Agile planning board, QA tasks can be added to both levels depending on the nature of the task. High-level QA tasks that apply across a new feature may be better suited for Epics, while specific testing actions fit into individual stories.
Sub-Tasks for Epics Introduced to the Team
- Provide estimates
- Create & gather test cases
- Prepare skeletons for automation
Provide Estimates
An important aspect of this planning is the QA estimate – the number of hours (or days) needed for testing a feature. Similar to development estimates, these should take into account the time needed for all necessary testing activities (such as regression and acceptance), as well as test automation.
Test estimates typically look at the amount of testing needed for an entire feature, so the QA team incorporates testing times for every Story under an Epic for accurate numbers. Estimates are also needed very early on in the process, so including a Sub-Task under the Epic ensures that this important step isn’t missed.
As a general rule, Sub-Tasks should represent no more than 2 days of effort. If a particular task takes more than 2 days then the team may need to break things up into smaller chunks of work. This protects the project from any surprises in planning.
Create & Gather Test Cases
QA teams may already have a suite of existing test cases they can use for regression testing a new feature. They can use these in addition to any new tests they create. Testers look at the feature as a whole in order to determine what should be tested when stories become ready to test. This gathering phase also happens early, typically after estimates are shared. Adding this Sub-Task under the Epic helps testers prepare as soon as possible.
Prepare Skeletons for Automation
Oftentimes, there may already be some kind of user interface to interact with, regardless of the feature. Automation engineers can use existing UIs to start building out automated tests. These test skeletons can include locators for existing elements or functions that navigate right to the point where the new feature will be implemented. Automation takes time to develop so creating structures for what is already available sets the team up to complete new test automation sooner. In this case, a Sub-Task under the Epic is ideal.
Sub-Tasks of an Epic
These are just a few of the QA tasks that occur closer to the planning stages of a feature. Because they involve preparation at a higher level, subsequent Sub-Tasks could be a better fit for Epics. Individual test actions can then be attached to each Story Sub-Task.
Sub-tasks for Stories Ready to Test
- Execute test cases
- Run existing automation suites
- Create test automation
Execute Test Cases
Once a Story is ready to test, the QA team can grab it for testing. Creating a QA column in the Agile board is a good way to organize tickets that are ready to test as testers can then move tickets to that column and assign to themselves. This gives the whole team a better visual on what QA is testing.
As part of the testing process, testers typically prep test environments first. This could involve deploying a feature branch to a dedicated QA environment or setting up a local instance of the application on individual machines. Manual testers can begin testing once the environment is ready by executing test cases that were created or gathered in earlier planning phases. As tests fail, the team can create bugs for prioritization and move Stories using a Fail step.
This moves the ticket back to an Open or Reopened state (depending on the workflow) where developers can work on linked bugs.
Failed Story set back to Open status
As a general rule, each ticket has one tester. This ensures that critical testing isn’t missed. If a feature requires multiple testers then a little extra coordination is needed to ensure a ticket isn’t sent back to development before everyone has completed their own testing.
After testers complete manual testing they can attach the test results to the associated Story and move it through a Pass workflow.
This updates the Story to a Resolved state, marking it ready for a release. The status can vary depending on a project’s workflow.
Passed Story
Jira offers the ability to customize workflows that incorporate testing steps such as a pass or fail step for Stories.
Run Existing Automation Suites
If there are multiple test environments available then automated tests can execute in parallel with manual testing. This can be a suite of regression tests that cover areas of the application testers don’t have time to look at. Just like with manual testing, AQA can attach a report of the testing results to the Story.
It’s important to note that moving stories to a pass or fail state should be coordinated with the manual testing team. Automation covers regression points, but they cannot always account for bugs related to new functionality.
Once existing automated tests have completed, the AQA team can continue writing new tests for each Story.
Create Test Automation
This builds off the task for creating test skeletons. When Stories become ready to test, AQA continues creating automation that covers new features. If teams log hours against tickets then Story automation Sub-Tasks become crucial as they help separate development and QA hours.
With Sub-Tasks, QA can divide the work across their group. Sub-Tasks also keep the rest of the team informed of testing activities and they become even more useful as a team grows.
Agile QA board
If a feature team has multiple testers or QA engineers, having a list of tasks for each Story gives everyone a better view into what is needed to complete testing.
Recap
We’ve just looked at a few, simple examples for bringing QA workflows into Jira. Sub-tasks are a great way to keep QA steps organized for each story and epic. Jira provides a lot of flexibility for processes and it’s important to talk about what workflows work best for the team. How have you incorporated QA tasks into Jira? Let us know in the comments!
