Separate trackers for features and defects?

Question

At my company we use JIRA for new feature requests and then the QA department logs any bugs/defects in Quality Center. I find Quality Center to be very non-userfriendly as it requires IE because it uses ActiveX.

Is this a common practice to use separate trackers for feature requests and defects? Is there any advantage to having separate trackers?

Answer 1

Hey.
I actually have the same setup at my work. I must say it doesn't have sense, if you use QC only to store defects. If you need bug tracking, you can stick with Jira. But you must understand that QC is tool dedicated for QA and it does much more. So it has sense to have Jira and QC if you (I mean QA at your work ) use all/most of QC features and you have Jira plugin that synchronizes defects between QC and Jira (I know about two plugins for Jira like that).

[end of answer]

If you're thinking 'but why the fck QA needs this stupid tool?' let me uncover a bit about QC for you.
Please understand that although both provide bug tracking capabilities, they have very different target and purpose. I assume that most people (programmers) here know Jira, so I will uncover a bit about QC for you:

1. It is Test Management system. It looks at (almost) all possible aspects of QA and is specialized only for that.
2. It has Management module, where you can define software releases, cycles, provide their descriptions, documents, links, etc..
3. It has Requirements module, where you can store requirements with descriptions, associated documents, links.
4. It has Business Components module, where you can define sort of 'areas' of application, define they expected behavior, expected input and output. Later you can combine those components into business process with flow of actions, inputs, outputs, expected behaviour - nice setup to link with proper test.
5. It has Test Plan module, where you define tests, their description, associated documents, test steps, expected results...
6. It has Test Resources where you can define additional resources for your tests
7. It has Test Lab module where you group tests into Test Sets, and where you run them. This 'runner' gathers from you actual results, screenshots, Defects...
8. It Has Defects module which is database of bugs with their descriptions etc. Additionally you define different roles and Defect Life Cycle so you can manage them the way you want.
9. It has Dashboard module where you can display tracked information about testing.
10. Between all those modules in 2-8 you can setup links, if you do so QC provide you Traceability Matrix between Requirments, Tests, Defects, Test Execution, Software Release, and so on...
11. It has Document generator which allows you to generate various 9also user-defined0 reports based on all information in QC (I say all as it has built in module that allows you to querry QC database and put info into report automatically).
12. It has integration with QuickTestPro 9and some other tools) which allows you to upload to the server automated tests, and additionally it allows you to run them from server on remote machines. You can schedule sets of tests to run on different machines and have results reported directly to QC database.

P.S. It is a big tool, used properly works great, otherwise it sucks

Answer 2

Somebody's feature is somebody else's bug. For example, is it a bug if some button text is too small to read, a button is in a weird place like on the status bar, or help text is less than helpful? Users would probably say yes, while developers (and maybe power users) would often say no, because they are familiar with the quirks.

Having separate systems adds inertia to moving from one to the other, rather than just reclassifying it. This means that escalation of an important feature request is artificially less likely than it would be with a single system.

Of course, it could be that you don't want users to be able to see bug reports, but only feature requests. That should be possible to ensure in any modern bug handling system.

Answer 3

Separate systems is not a good idea at all. It means you have to search in 2 places. It means you can't link defects to a parent feature request. It means you have 2 sets of tracking ID's... the horribleness goes on.

A single system makes life easier. Most decent tracking systems will let you tag/flag an entry as a "feature" rather than an actual thing thats broken.

To my way of thinking, a feature request is merely a defect anyhow - that lack of the feature comprises a defect in the eyes of the person making the request: "If you can't do X then its broken and I don't want it".

In my current business I log everything reported by customers - some of which are defects, and some of which are requests for new features. As far as I'm concerned I need a single place for everything for simplicity and visibility.

Answer 4

Depends on your policy around bugs & releases.

Do you always fix all open bugs before releasing? If so, separate trackers are probably a good idea (or at least a filter in your main tracking software that essentially renders it as separate trackers).

If, on the other hand, your organization uses a more "Agile" policy then you may consider bugs == features == stories and you just prioritize and deliver as many of the high priority stories as you can in each cycle. Here, you just dump everything into one story tracker.

Answer 5

Quality Center has hooks for automated testing that may be used by a QA department. I don't know if JIRA has similar functionality or not. Where I work we have Target Process and Quality Center that keep track of bugs so things are duplicated to some degree there at the moment.

Answer 6

I wouldn't. The moment you start implementing a new feature you are going to be making new bugs. So you might as well have the new feature task right in there so you can track it along with any related bugs.

Answer 7

Feature requests and defects are basically the same thing - somebody would like the system to change in some way, either providing new functionality or correcting erroneous behaviour. It is beneficial to have a single consolidated list so that relative priority can be applied to all of the feature requests and defects in the backlog; individual developers can only work on one thing at a time and the most important next item may be either the development of a feature or a fix for a defect. A feature request may be more important than an outstanding defect and vice versa.

With regard to the tools you mention, as pointed out in some of the other answers, Quality Center is primarily a QA tool which allows you to input requirements, define test cases and execute step-by-step tests. Where a test fails, it is natural to immediately raise a defect without changing context and Quality Center provides defect management functonality to allow you to do this. The difficulty is then in managing the process of fixing and retesting defects against the other work that is in the backlog and this is where things can get complicated. I have seen teams that have set themselves up so that feature requests get raised as 'defects' in Quality Center to give them a full view of the work backlog; this has a strange feel to it, however raising defects in another tool e.g. JIRA breaks the link between the defect and the test from which it originated.

There may be other compelling reasons to use a specific tool, e.g. if you have integrated it with your source code repository and deployment process, which may override the level of choice you have around how integrated the front-to-back process can be. The best demo I have seen of a full requirements-to-deployment solution is Rational Team Concert, however I haven't had hands-on experience with it.

Answer 8

Tracking defects and feature requests separately is not a bad idea, and I've seen it often. It sounds like the problem is using two different systems that might not even be able to talk to each other. Can you use JIRA to track them both? That way you can tie future defects back to earlier feature requests and see how everything interconnects. This can be useful.

Answer 9

I have never heard of anyone using two incompatible systems. It is well known that the higher the cost of transition, the less likely someone would be able to do a transition. Feature to/from bug transitions are common so it doesn't make sense to separate issues.

Most mature issue management systems allow you to define fairly different workflows for each type, which should resolve most issues. There are also enough plugins to take requests from users without making them users on the issue tracking system.