QA Manager's dream come true
August 19, 2014

QA Manager's dream come true

Anonymous | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Software Version

6.2.4

Overall Satisfaction with Atlassian JIRA

We use JIRA as a task and defect tracking system across several products and divisions within our organisation. Prior to adopting JIRA several defect tracking systems were used, both internally and externally sourced solutions and so a project was started to centralise on a single system to ensure continuity between teams for reporting and implementing enterprise wide process flows.
  • Integration to a wiki (Confluence) which is a must have for software development, not only the what (JIRA ticket) but the WHY (confluence page with diagrams and commentary/dialogue between contributers). You can create JIRA tickets from within Confluence and you can link to related confluence pages within JIRA.
  • Several product teams follow Agile methodologies such as Scrum. JIRA comes with great support for scrum out of the box with planning boards and story point features.
  • Half of the battle when using defect systems and content management is finding related issues or pulling reports from them. JIRA provides a nice syntax language for doing complex queries (JQL), the search engine is robust and it's really easy to create links between stories and the bugs found during testing.
  • Dashboards are great but if you want to do more complicated queries than just showing number of open defects or bugs per week/release then the standard offerings can be limiting and often searching for solutions you are pointed towards 3rd party add-ons that are expensive.
  • Time tracking is simple in JIRA but whilst there are third party time tracking/reporting tools available, it really should be something that is included in the standard product instead of a third party add-on.
  • Often with stories/epics you may have started life in a Confluence page and the content is relevant, it would be nice if you could embed content from Confluence into the body of a JIRA ticket instead of just linking to the page - often you end up copy pasting paragraphs from one system to the other to communicate the point to engineers.
  • Team members are able to focus on their pending actions much more effectively leading to increased efficiencies.
  • Product roadmap is much more visible which has led to conversations regarding ROI comparisons earlier in the process than it used to.
  • There is an increased amount of admin inputting all the jira issues into the system but this is a double edge sword if you want visibility of everyone's pending actions.
Personally we used an in house solution previously and with that system there was a better integration to our source code system and issues could be directly entered by customers whereas our enterprise policy does not allow that with JIRA, instead we integrate to Salesforce as our CRM portal. JIRA is definitely a nicer engineering tool but as we are not using Git or Atlassian's Bamboo (build management system) then we are not getting as much out of the tool as we could. JIRA has a very clean interface, I found it easy to navigate and the agile board is great for keeping focus on finishing tasks in the current sprint. This is something that was very difficult to do in our in-house system and isn't the easiest to do in Salesforce.
JIRA is now integral to our processes, it has taken 18+ months to get to this stage, I can't see us not renewing for at least a few more years. There are complaints about any system but most of the people I've spoken to in engineering are happy with the tool and are finding it provides a simple way to turn ideas into reality or error messages into resolutions for bugs.
I think JIRA can be more suited to a single product, or limited release cycle teams than historical based products or very large teams using a single project in JIRA. There are many git centric features being released, consider how tight you want the integration to your source code control if you use something like Mercurial. JIRA for a large enterprise (if self-hosting rather than On-Demand) is not something that you get up and running and then it runs itself, you definitely need to have an IT team supporting it and the many upgrades if you want new functionality from recent releases.