Bug Tracking has been a common discussion at work recently. Like many software companies, we've adopted the use of Atlassian’s Jira. It’s flexible enough for all the diverse product teams to be able to use it, and intuitive enough where very little education is needed to start using it. The hardest part, it seems, has been to get the teams to ACTUALLY USE IT.
As a tester, and more importantly in this discussion, as the QA Manager, I want to enforce a policy of “Jira All The Things!” (See what I did there? I’m not above shameless plugs for the blog.)
But we’re using Jra as a means to not only track bugs found in testing, but also:
- Bugs Found in Production
- New Features requests from our Stakeholders
- Client Questions on the Product Suite and the subsequent responses sent to them
- Updates to existing Features
- Changes to the database configurations; in both system and client
So now the question from the team comes back;
“What really needs to be put into Jira and what can we just stick to endless e-mail threads on?”
OK, they don’t actually say it like that, but those are really the two options. Endless e-mail discussion threads with no workflow involved and, subsequently, no obvious resolution or just put it in the Jira backlog.
I might have come across as biased there.
While I feel the need to track all the features, new and updated, in some efficient way, I’m nonplussed on the method of how we track. But I’m holding the line at bugs.
Put all the bugs in Jira.
Track them, follow them, know when they creep up, sneak back into the hidden recesses of the code and once again appear like some coded perennial flowers.
What’s in it for me, you ask?
I've jokingly said, too many times according to some, that we unfortunately don’t get paid by the bug. If we did, I'd Jira me up a new car and summer home on each build. But I’ve found that bugs in the system sometimes live longer than the testers that stay on the projects. Leave a legacy to those who follow you; live on in your bug reports.
Open a Jira.