Expanding the default JIRA workflow

Jordan Packer

I'm currently brainstorming with my QA department on the optimal workflow for our JIRA issues. It seems that the classic workflow is too basic for our needs, yet the QA department wants something that seems too "overkill."

As many of you know, the basic workflow that I'm referring to is as follows:

The workflow that our QA department wants to use is this:

The main reason why they have so many steps is because they want to be able to know (via JIRA filters) what is "ready to be deployed to Test" and what is "ready to test in Test"; what is "ready to be deployed to Stage" and what is "ready to test in Stage". I'm trying to be an adopter of the new Deployment Projects feature in Bamboo so that a JIRA issue can show which environments it has been deployed to.... which seemed like the answer to our problem, but then we realized that this only works if one commit is all it takes to fix the issue. If there are more commits that need to come after the first one, then the JIRA issue may be showing as "Deployed to Test" but it may not necessarily be "ready to test" (because there are still a few more commits coming to completely fix the issue). The other big problem with trying to go this route is that the "Deployed to Test, Deployed to Stage" pieces of information are not searchable in JIRA. In other words, I can't create a filter that will tell me which JIRA issues have been "deployed to Test". I realize that you can get this kind of information by comparing releases in the Bamboo deployment project, but to our QA department that means there's one more place they have to look to get the information (wherease with their proposed workflow, they can get all the info they need in a JIRA query.

I need to know what other people out there are doing to solve this kind of problem. How do you let the QA department know what is ready to test at any given time? Just moving the issue to an "In QA" status or a "Ready for QA" status doesn't seem to be enough because, even though the issue may be ready for testing, they don't know yet if that code has actually been deployed to their environment.

Any and all suggestions are welcome and appreciated! Thank you!

John Price

I don't know the size of your shop or what other processes you use around build and deployment, but in our case we try to keep the Jira workflow simple and incorporate other types of communication (build notifications, standups, etc.) to decide when to start testing particular issues. So our workflow goes something like:

Open (Start Progress)

In Progress (Send To Testing)

In Testing (Mark As Tested)

Awaiting Release (Close Issue)

Closed

Our Rapid Board has four columns (To Do/In Progress/In Testing/Done). The last two statuses (Awaiting Release/Closed) map to the Done column.

We push the latest changes to the test server each night via TeamCity, and then in the morning we have our standup which would include any tester roles on the team. So for a QA person to know if something is ready to be tested, he or she would think like this:

Did it get marked In Testing prior to the last QA deploy? If so, I can test it.

Am I not sure? Ask the developer at the standup, or just via chat (we like HipChat - shameless Atlassian plug). Also, if the developer knows who's going to test a story, they can just assign directly to the QA person, right?

The biggest issue we have is that we sometimes move all the sub-tasks of a story to In Testing but forget to move the story. But usually between developer push ("hey I'm done") and QA pull ("When is that darn story going to be ready to test?") it's fine.

I think you are correct to avoid mapping every single little process step into Jira - keep it simple. It's ok to have pieces of the process that are outside your tool; even with motivated technical users like dev/QA, the more steps in the tool, the more likely people won't reliably update their tickets and then you've got bad information anyway. There are tons of other things you don't model in Jira already, right?

Got Latest Code

On Hold - Coffee Break

Checked In Some Stuff

etc.

Make sure people are actively talking via standup/chat/Skype/whatever. If you don't have that, no Jira workflow is going to help.

Good luck!