Manage Bugs between Dev, QA and Production

Question

My software team have just started using Jira to manage bugs, so I am fairly new to the process that is available to Jira.

The systems we build are internally facing applications or customer facing web applications, and we release to these environments on a change request by change request basis, rather than through a product lifecycle type of development lifecycle.

The way we plan to use Jira, is for each project (which is usually a single CR) to have its own project created in Jira. Our process is then as follows

• Developers code and unit tests, until ready for integration testing
• Developers start integration testing and any bugs are raised in Jira, under a version named Development.
• Once all development bugs are fixed, we then move into QA, where we hand over the build to the testing team. A new version 'QA' is created, and all bugs found in QA are logged against this verison.
• Once all bugs are closed, the project goes Live, and the project is closed in Jira.

From what I have seen of the more agile product type uses of Jira, I suspect we are using the version fields in the wrong way, but as I am new to Jira I am not sure if we are, or if there is a better way of doing it.

Would appreciate hearing from someone who has used Jira in this type of environment to see what the right way to use Jira is.

Answer 1

Here's what I'd recommend after using JIRA in a number of different environments, with varying team sizes and types of project.

• Use JIRA projects to denote large but discrete functional areas of work that correspond to a subset of team members in your organization, e.g. a new web application or internal customer app.
• If the project or the team working on it is big enough to warrant it, use JIRA components to define different functional areas. You can then assign component leads who will automatically be assigned new issues against their components, and you'll be able to track which functional areas have the most bugs and maybe need more attention from the test team.
• For versions, you can certainly set up development, live and QA versions as you've described, but these are more traditionally mapped to the JIRA issue status. With the standard JIRA workflow an issue will be Open while a developer is working on it, Resolved after the feature or bug fix is completed, and then Closed if QA verifies the feature or fix, or Open again if QA identifies a problem.
• If you have long-lived applications where you get multiple CRs that specify new features for the same app, I would use JIRA versions to define the different releases of the app, based on a feature set and / or time schedule.

With the approach above you'll be able to track the work of each team or individual developer / tester and know when all issues on an app have been addressed so that you're ready to do into test or deployment. I see you mentioned that you're not using a traditional product lifecycle, but unless your organization is very small and you develop apps that are thrown away after their first version is ready, I think you'll get a lot of benefit from this approach.