Learn how to set up qTest Manager release integration with Jira fix versions and sprints.
Activate Integration Settings
All right, so the first thing we’re going to do is go to the Integration settings, of course, and select your Jira connection that you already have set up. And I’m going to walk through going through every single object so far, before we get to the new stuff around the release integration.
Add Defect Type
So, I’m going to add a new defect type here, and again, we’re going to integrate qTest Manager with two projects for defect tracking. So, I’ll go ahead and select this project, Jira+ qTest demo, and then I’ll select the bug issue type for the defect integration.
And now, I’ll go ahead and select another defect type. Again, this is existing functionality that we have here before the release integration that we’re going to get to, just showing you kind of how you can configure your qTest Manager projects to have multiple defects, connected into one qTest project around defect reporting over into Jira.
Add Requirement Type
And now, what I’ll do is I’ll turn on the requirement integration. So, this means what we’re going to do is add a requirement type of a user story in one of those projects, and then actually what will happen is those get pulled over into qTest Manager, in the requirement section, so we can then start adding in test coverage against those.
And quick reminder, you can also go to the actions area and select how you want these to be displayed over in the system. So, I’m actually going to choose the sprint field, and then choose the status of the issue type. What that will do is it will pull them over based off the sprint value of that project and then the status. Whatever custom or system field that I have in Jira that’s reflective on those user stories to actually show up in qTest manager. So, I’ve done that. I’ve got my defects, got my requirements.
Active Release Integration
Now, I’m going to turn on the release integration, and I’ve got two options here to map over to the qTest manager test plan. I can select based off of the projects, of course, and then I can choose if I want to pull in based off of fixed versions or based off of the sprints. I’m going to choose fixed version because I chose to organize my requirements under sprints.
If I go to the actions area, I can then select Unreleased, and then also the Released versions to pull those over. And then, the recommendation is to have this checked to also auto-populate those in the release scope. So, I’m going to save and activate this, and then before I actually show the pull over into qTest Manager, what I want to do is actually show you what’s going on on the Jira side before we actually retrieve the Jira data and set up the web-hook integration between us.
Connecting Jira Data Flows
So, let’s go to a Jira instance that I have here, and what you’ll notice is that I have two versions, version 1.0 and 2.0. We’ll focus on 2.0 today. But just know that one is released and one’s unreleased, and I chose to pull over both of those.
So now, I’ve got multiple Jira issues here. If you count these up and again, we decided to pull over the user stories, there’s around 10 user stories inside of this version 2.0. If I go to the backlog however, what you’ll notice is a split between five of those user stories that were a part of the version. That’s in the sample sprint two. And then, I’ve got some other ones that are actually outside of that sprint. So, it’s split between the 10 and the release. And then you’ve got five that are in the sprint, and then five that are in more of a backlog. So, keep that in mind as we go through.
Retrieve Jira Data
What we’re going to do is we’re now going to retrieve the Jira data to pull that over into the system and establish that real-time integration. So now, I’ve clicked the Jira data. You’ll notice is says, 16 out of 16. That’s because we’re pulling in not only just those ten, we’re pulling in other user stories that could be in other releases. And now, we’re going to click the Jira data, and you’ll notice it’s going to be two out of two, because as I mentioned earlier, we had a version 1.0 and a version 2.0, that’s over in Jira. So, now let’s go to the test plan and see what happens.
View Test Plan
Now, we’ve got the auto population of those versions over into the test plan. And then, if I focus on version 2.0, you’ll see that I’ve got those ten that have been pulled over underneath the release scope. So that looks good, in my opinion. We’ve got the 10 that we’ve showed, and now the 10 over in qTest Manager. Again, now that I’ve organized them over in the requirement section as well under the sprints, and then also the statuses, you can see there’s the five that are in sample sprint two, and they’re underneath the sprint two. And then you’ve got the five that are in the to do state. So again, looking good here. The five are evenly split, as we focus on sprint two.
Link Tests to Jira Issues
And now, let’s go in and actually talk about now what we can do here, because we’ve got version 2.0 there. That’s great. That’s a great field to show up over in the system as well. And now, if I go to test design, we’ve added some new functionality that allows you to quickly add these requirements that are part of that release scope, onto a test case to ensure that test coverage right away. So, if I go to a test case here, and I click the add button, you’ll notice we got this new test plan tab. And this is great because previously I had the requirements tab to pull from. But now, I can just say, okay, all those requirements or Jira issues I’ve pulled over for version 2.0, now I have them there. Now I’ve added those three right away onto that test case for me to have coverage.
Execute Test Against Jira Issues
And in the same way, I can pull them in for test executions, if I go to the test execution module here. So, now that I’m in a cycle, or let’s say I added a new test suite here, I’ll go ahead and add this. Just calling it real quickly. A new feature for testing two. And when I go to click the Add button, what you’ll notice is that now I also have the test plan tab as well, just like the requirements and other tabs across the system. Again, I can choose right away, which requirements I need to test. Now that I have test coverage against those, it’s going to dump in all those test runs, whether they’re manual or automated for me to go off and execute. So, it’s a really powerful way, really quick way for us to quickly align test cases to the requirements that are in scope, that we pulled over from Jira, and then quickly add them to test execution to actually go off and start running against those. So, great new feature for us to do.
Now, what I want to do is actually look at what would happen to qTest Manager and to all those that are in the system under test, as we move things around in Jira. Remember, we’ve got that real-time integration. So, let’s go ahead and talk about what would happen if I were to add something to that release scope. So, let’s go back over into Jira, and now what you’ll notice is that I’ve got those 10 that are in the release scope. But, what I want to do now is drop one of those 10 and move it into the sample sprint. So, what you’ll notice is that the folder structure is going to change over in the requirements area automatically. So, that already happened. That JQD-4 user store we moved over to the sprint, that’s now in a to-do state, and now we’re all looking good as well. In the same regard, we moved that over into the sprint, and now I’ve got six user stories in that sprint.
However, what would happen if we changed one of these user stories, in this case, it’s Jqd-5, and we actually changed it, not only moving it into the sprint but looking at I now want to add it to the fixed version? So previously, up into this point, we had 10 user stories in the version 2.0. Now, what I just did was I added an 11th, right? So, if I go back over now to the test plan, you can probably guess what’s going to happen. If I refresh that and I scroll down, what you’ll notice is now we have 11 attached to that release scope. So, this really helps out, making sure your testers are aware that the release scope has changed. And now, you need to add test coverage against these new artifacts that are a part of your release scope.