*
The moose likes IDEs, Version Control and other tools and the fly likes Recommendations for a bug tracker? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Recommendations for a bug tracker?" Watch "Recommendations for a bug tracker?" New topic
Author

Recommendations for a bug tracker?

Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
Hi there

We are busy starting a new application and we are looking for a good way to track bugs.

I have tried Roundup, Trac and Mantis and I was wondering what software most people on this forum are using. Are there any packages that you could recommend?

Many kind regards,
Rachel
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Moving to IDE's and other tools...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
My very first recommendation would be to not to need one. Why do you think you will?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15957
    
  19

Originally posted by Ilja Preuss:
My very first recommendation would be to not to need one. Why do you think you will?


Well.....

For those unfortunate enough not to have experienced the joys of working with IBM mainframes, IEFBR14 is a dummy program whose sole requirement in life is to zero out a register and then immediately return to the OS. It was 2 instructions long and commonly served as a kludgy place to hang dataset allocation statements in JCL.


Customer surveys are for companies who didn't pay proper attention to begin with.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Originally posted by Ilja Preuss:
My very first recommendation would be to not to need one. Why do you think you will?

Why wouldn't you need one? How do you note defects? Even if you fix them immediately, it is still useful to have a record.

Rachel,
A spreadsheet serves as a fairly good/simple tracker.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:

Why wouldn't you need one? How do you note defects? Even if you fix them immediately, it is still useful to have a record.


If I were starting a greenfield project, I'd plan not to have any. I'd hope to at least come close enough to that goal to not need a software tool to record them. Seriously.
[ February 23, 2005: Message edited by: Ilja Preuss ]
Ravi Sathish
Ranch Hand

Joined: Feb 26, 2002
Posts: 131
Rachael

Bugzilla is most preferred open source bug tracker

If you want something J2EE based...

Try ITracker http://www.cowsultants.com

Ofcourse you need to do lots of configurations viz. jboss-3.2.x, database (mysql/oracle) etc.

Ravi
Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
Hi there.

Thank you all for the advice. I am looking at Bugzilla now. Of course my best solution would be to not have to use a software tool to record all of these. But when trying to keep track of bugs and having to assign them to people, I find that a software solution is far better than having to communicate every bug to my team. I would spend my whole day walking around or typing out emails to assign to people and I would get no other work done.

Thanks again!
Rachel
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rachel Swailes:
But when trying to keep track of bugs and having to assign them to people, I find that a software solution is far better than having to communicate every bug to my team. I would spend my whole day walking around or typing out emails to assign to people and I would get no other work done.


That sounds like a lot of bugs you plan to have. I wonder wether it would be more effective to invest into bug *prevention* instead of bug *management*...
Chris Johnston
Ranch Hand

Joined: Dec 13, 2004
Posts: 85
So are you saying that you are capable of building perfect software each and every time? How would you define the differences between bug prevention and bug management?

Whether it is a bug or a missing feature or something the user does not understand in the interface or anything else that may be considered a problem with the software, you always need something that allows you to track these problems and to properly document them.

I have used Mantis in the past and found it to be a capable and feature complete bug tracker.


www.fuzzylizard.com
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Originally posted by Ilja Preuss:


That sounds like a lot of bugs you plan to have. I wonder wether it would be more effective to invest into bug *prevention* instead of bug *management*...

Even with bug prevention, you are still going to have bugs. I think a more realistic target is to have less bugs than in the previous version. Ilja, I'm guessing you are farther along in this that I am to be able to consider not having any bugs.

For example, in our previous iteration we had 20 defects recorded. Even if we were to shoot for half that number, I would want a place to record ten defects. As to "a lot" of bugs, I would want to record it even if it is one. That way there is a record of the bug, so that class of errors doesn't happen again. In my mind, a defect tracking log serves as defect prevention for the future.

"But when trying to keep track of bugs and having to assign them to people, I find that a software solution is far better than having to communicate every bug to my team."
Rachel,
I completely agree. Having a centralized list definitely decreases the bug management time. In turn that frees up the time you would have spent on bug management to focus on bug prevention!
Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
I agree that bug prevention is the way to go. But you can only prevent bugs to a certain extent. For example, today we found a bug that if our application runs on a windows 98 machine with a really old graphics card that it freezes the computer. There was no way that we saw taht coming!

So I would rather have a system in place where we prevent as far as possible, and for the ones we find, we record and assign to get fixed.

Thank you all very much for the advice. And I bug free development to you all!

Many kind regards,
Rachel
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rachel Swailes:
I agree that bug prevention is the way to go. But you can only prevent bugs to a certain extent. For example, today we found a bug that if our application runs on a windows 98 machine with a really old graphics card that it freezes the computer. There was no way that we saw taht coming!


Yes, ok.


So I would rather have a system in place where we prevent as far as possible, and for the ones we find, we record and assign to get fixed.


I certainly agree that you should record and assign bugs you find. I just wonder why you'd need a software tool for that...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:
Even with bug prevention, you are still going to have bugs. I think a more realistic target is to have less bugs than in the previous version. Ilja, I'm guessing you are farther along in this that I am to be able to consider not having any bugs.


For the past three years I've worked on legacy systems, so "bug free" actually is a phantasy to me. But it's a nice phantasy, and one that I'd like to make reality should I ever start a greenfield project in the future.

And there *are* teams out there reporting, say, two bugs a month. That's what I would aim at - and therefore I wouldn't plan for having a bug database until it became obvious that I failed at it.

As to "a lot" of bugs, I would want to record it even if it is one. That way there is a record of the bug, so that class of errors doesn't happen again. In my mind, a defect tracking log serves as defect prevention for the future.


Here I actually differ. Having a bug in a database doesn't make that class of errors not happen again - reflecting about it does. A very effective practic, I could imagine, might be for every bug that is found to write both a system level and a unit level test that fails because of it - before fixing it. That will tell us something about what kinds of tests (and perhaps other defect prevention techniques) we were missing and should implement in the future.

Having a centralized list definitely decreases the bug management time.


If I have to manage ten bugs, why do I need software for that? Why wouldn't, say, a stack of index cards suffice? Seriously.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Originally posted by Ilja Preuss:
Here I actually differ. Having a bug in a database doesn't make that class of errors not happen again - reflecting about it does. A very effective practic, I could imagine, might be for every bug that is found to write both a system level and a unit level test that fails because of it - before fixing it. That will tell us something about what kinds of tests (and perhaps other defect prevention techniques) we were missing and should implement in the future.

I didn't mean to imply having the bug in a database prevents the class of errors from happening. A test prevents that error from happening in the same place. I like to use the bug "database" (in my case it is a spreadsheet - aka list) periodically to make sure the same things aren't slipping through. It serves as a sanity check that we really did incorporate those tests/defect prevention techniques and the defect class is really gone forever.

If I have to manage ten bugs, why do I need software for that? Why wouldn't, say, a stack of index cards suffice? Seriously.

My spreadsheet has two tabs: open and closed. This provides a simple way of keeping track of what bugs were fixed and when. (Yes, I realize this could be done with index cards too.) How do you share your stack of index cards electronically? We have developers in different locations. We've taken pictures of retrospectives, but those don't represent changing data. It seems like a spreadsheet is easier to manage than index cards for this.

I do agree that you don't need software specifically for bug tracking.
[ February 26, 2005: Message edited by: Jeanne Boyarsky ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:
How do you share your stack of index cards electronically? We have developers in different locations.


To be frank, I don't know what I would do in that situation. Quite possible that I would start using such a tool, too. Or I would just handle them like feature requests and put them together in the planning tool.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
For all my private sandbox stuff I use index cards to keep track of both features I may want to add and bugs I may want to fix (as well as constraints I have to obey -- although I'm not sure anymore if the cards are an optimal solution for those). It works great.

I used to do the same thing with .txt files on my computer's desktop but that didn't work out. It was simply too difficult to reorganize the .txt file. Yes, you read it correctly. Too difficult. Text file. On my desktop.

Things like Excel sheets and database-driven websites are good for organising large amounts of homogeneous data. However, the advantage those index cards have is that they don't limit me to a spreadsheet format, for example. If I want to draw a little diagram to document my thinking for that later time when that particular feature/bug becomes my first priority, it's a question of seconds and the diagram is there. GIMP would still be loading its libraries by the time I've already got what I need...

At work, we're not using index cards. The main reason being that the people who we need to communicate our status to or who want to check on our status are not too receptive to shuffling a deck of cards. They want to be able to access the status while sitting in a meeting because someone might ask -- and they usually don't know the status so they have to check right there and then. The environment is without a doubt very dysfunctional in more than one way. This is one of those ways.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

For my private stuff, I write things on scrap paper. I like having this on non-electronic form so I can look at it while my computer is frozen or rebooting. This tends to be the lower level development stuff like the list of mini-tasks within a task (method to do X, method to do Y) and defects/refactorings that I find before the feature is "done."

I like using a list rather than index cards because rewriting things reminds me they exist. If I used index cards (or post its) for this purpose, some things would stay around forever.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeanne Boyarsky:
I like using a list rather than index cards because rewriting things reminds me they exist.

Are you saying that you like rewriting your list into a new order every time your priorities change?

Originally posted by Jeanne Boyarsky:
If I used index cards (or post its) for this purpose, some things would stay around forever.
I don't follow. Why would some things stay around forever if you used index cards or post-it's?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:
I like using a list rather than index cards because rewriting things reminds me they exist. If I used index cards (or post its) for this purpose, some things would stay around forever.


My experience is exactly the other way around: Something typed into a software tool is "out of sight, out of mind."

Index cards, on the other hand, are very tangible: you can watch the stack of bugs/features grow and shrink. That seems to have an important psychological effect, in my experience.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Heh. I just remembered one "feature" of the index cards. I usually keep a pile of unfinished cards next to my laptop while coding. Every now and then, I accidentally swipe the cards to the floor with my sleeve and curse like a sailor. It acts as a nice incentive for getting rid of those cards (by implementing them, of course)
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Originally posted by Ilja Preuss:


My experience is exactly the other way around: Something typed into a software tool is "out of sight, out of mind."

Index cards, on the other hand, are very tangible: you can watch the stack of bugs/features grow and shrink. That seems to have an important psychological effect, in my experience.


Looks like you are working in ideal conditions. The places where I have worked , there is a need to bug tracking system. This can be attributed to various reasons: turnover of resources, entitlement of author of feature and future reference to fix approaches that can be recycled.

With my experience, I would vote for a bug tracking system compared to index cards etc. This will definitely help complex systems on which multiple resources(including developers, PMs and qa testers) to be in sync.


Kishore
SCJP, blog
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Originally posted by Lasse Koskela:
Are you saying that you like rewriting your list into a new order every time your priorities change?

This list is below the level of priorities. It is all the things I need to accomplish to complete a task. For example, if I am creating a screen, I need to create a Struts action, a session bean method, a JSP, ... If I don't need the screen anymore, the whole list is irrelevant. It's only the refactorings that can get copied from list to list. And those aren't really things we prioritize; I just do them. In general, I accomplish roughly 80% of the things on the list before I need to rewrite it anyway. I actually got this idea from one of Kent Beck's books. It was a way of thinking about what tests you needed to write.

I don't follow. Why would some things stay around forever if you used index cards or post-it's?

Because I will put the index card or post-it under another paper and promptly forget about it. I do like your system for dealing with the cards though


Originally posted by Ilja Preuss:
My experience is exactly the other way around: Something typed into a software tool is "out of sight, out of mind."

Ilja,
This list isn't for bugs/features. As it's a paper list, it isn't "out of sight, out of mind." The list is way below the level of detail you write on the index cards in XP.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Jeanne Boyarsky:

This list isn't for bugs/features. As it's a paper list, it isn't "out of sight, out of mind." The list is way below the level of detail you write on the index cards in XP.


I see.

I actually have to admit that I typically use a software tool for this kind of list: Eclipse has this nice feature of creating entries in the Task list from ToDo comments in the source code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Kishore Dandu:
Looks like you are working in ideal conditions.


Far from. And we actually use a BugZilla instance - partly for communications with our customers, partly simply because we are working on a system that is now in development for over seven years, and we simply can't bring it into a perfect state tomorrow. It's getting better, though.

Still, if I'd were involved in starting a new greenfield project, I'd vote for first trying without such a tool.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Originally posted by Ilja Preuss:
I actually have to admit that I typically use a software tool for this kind of list: Eclipse has this nice feature of creating entries in the Task list from ToDo comments in the source code.

I've used that for longer term things. Like "delete this when move to Oracle". I like that it gets into CVS.
Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
Bug tracking with index cards would work well if it were just me or just me and one other person because then we wouldn't loose the cards. But trying to keep track of cards amongst my whole team would just turn into too much admin. The advantage that I see in a software based solution is that it simply removes the amount of admin that I would have to do on a daily basis. Especially during the testing part of the coding iterations.

Most importantly though, when the boss needs to know the status with certain bugs or features, it is far easier to put a link on his desktop that takes him to a software tracker than to say that the cards are distributed amongst my team and I would have to spend half an hour to track the card down.

But for you guys who are talking about having so few bugs, what are you methods to procuding software? What kind of design methodology are you using? OOAD or XP or something else? At the moment we are moving away from "Design, develop test the whole darn thing" towards XP.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Rachel Swailes:
But for you guys who are talking about having so few bugs, what are you methods to procuding software? What kind of design methodology are you using? OOAD or XP or something else?

I can't claim that I would write zero-defect software. Having said that, I've found that automated unit tests do a very good job of getting rid of regression. Another technique I've personally found very effective in keeping defect counts low is test-driven development. While testing is not TDD's main focus, it does help in writing better tests -- tests that I would easily miss if I was to write them after having implemented the code they're testing.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rachel Swailes:
But trying to keep track of cards amongst my whole team would just turn into too much admin.


I don't think it really *needed* to turn out that way, though it might depend on the size of your team, and how much it is colocated. Care to share some numbers?

The advantage that I see in a software based solution is that it simply removes the amount of admin that I would have to do on a daily basis. Especially during the testing part of the coding iterations.


The advantage of not using a software based solution, on the other hand, is that it better fosters face-to-face conversations, which might be quite valuable.

Most importantly though, when the boss needs to know the status with certain bugs or features, it is far easier to put a link on his desktop that takes him to a software tracker than to say that the cards are distributed amongst my team and I would have to spend half an hour to track the card down.


I'd actually prefer him to communicate more directly with the team than through a link on a desktop. For example by walking into the team room, taking a look at the card wall or something and perhaps asking a short question into the room. That not only might trigger some important conversations, but also shows the developers who is caring about what, thereby improving motivation (if nothing else).

And if it takes half an hour to track the cards down, I'd first try to improve card handling before introducing a software tool.

See http://www.scissor.com/resources/teamroom/


But for you guys who are talking about having so few bugs, what are you methods to procuding software? What kind of design methodology are you using? OOAD or XP or something else? At the moment we are moving away from "Design, develop test the whole darn thing" towards XP.


We are moving towards XP-inspired Agile development. Two of our current defiances are bringing legacy code under unit tests (just ordered Micheal Feathers book ) and how to start with automating acceptance tests for a highly interactive desktop application.
Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
Well, to give you some numbers, we are just a small company at the moment, having pretty much everyone except two of us removed in last November. Then hired another 8 people since then and looking to be over 20 by the end of the year. So it's not so much as looking for a communication solution now, but looking for a solution that will stick until the end of the year.

Our struggle at the moment it also to bring legacy code under control. I think that when the new system starts that we will use test driven xp and then I'm hoping that having the tests before and during development that we'll eliminate these bugs that are cropping up. At least with maintaining legacy code, we are learning better ways to do things.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15957
    
  19

For those who didn't actually follow (or understand) the link I posted way back near the beginning of this thread, IEFBR14 is a dummy program. Its sole purpose in life is to return to the operating system and to do so in such a way that JCL won't accidentally abort the job because the exit code was some unfortunate value. Or, in S/360 assembly language:

Exactly 2 instructions long. Unfortunately, there was about a 1 in 4 billion chance that when the program was entered, register 15 would contain a value that when subtracted from itself would cause the program to abnormally terminate due to arithemetic overflow. A second attempt also failed. It took 3 tries, I'm told, to make a 2 instruction program work reliably.

Another formative moment in my career concerning bugs was a mainframe program that silently carried a bug for over 20 years when one day IBM did an OS upgrade that caused it to start failing on our mainframe and the mainframes of our customers all in the same week. Someone had been stuffing a byte just outside of allocated memory and with the new OS release, that location was no longer as likely to be on an allocated memory page.

So I don't really believe in "bug-free" programs, regardless of methodology used. Besides, like they say "That's not a bug, it's a feature!". Some of my favorite program features actually came from people finding useful exploits for bugs and clamoring for them to be formally adopted into the system.

Now personally, I've always found Bugzilla confusing to use, but that may be because my primary use for it is to try and see if the annoying feature of the program in question is, in fact, logged as a bug and what, if anything, anybody's doing about it.

Bugzilla's geared towards large complex projects that get lots of incident reports. Where I work, we use Jira, though that's actually more of a problem-tracking system than a bug tracker/development aid.

For my own projects, I just use a list manager app that runs on my PDA.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tim Holloway:
So I don't really believe in "bug-free" programs, regardless of methodology used.


A program doesn't need to be totally bug-free to make the use of a bug tracking program unnecessary, possibly even counterproductive.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30123
    
150

Rachel,
I think all of the approaches mentioned will scale appropriately. Even the index cards if you are in one location As a memeber of a growing team, I think the most important thing is to have a process in place when new people start. Even if the process is still evolving, the new team members start with the mindset of "this is how we do things."

On a related note, I highly recommend the Michael Feather's book that Ilja referenced for dealing with legacy code.
Rachel Swailes
Ranch Hand

Joined: May 18, 2004
Posts: 434
Thanks, I will be sure to look at that book. I was searching on the net on this topic and I found this page that might be of interest to you.

http://www.fastcompany.com/online/06/writestuff.html

Thanks again for all the advice!
Rachel
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rachel Swailes:
http://www.fastcompany.com/online/06/writestuff.html


Interesting read!

But certainly not the only way to produce high quality software (assuming that not always human lives are at stake) - I've heard of XP teams having just a handfull of bugs a year, too.

I agree that you need to grow up and take responsibility, reflect on why bad things happened and how to prevent them in the future. I don't think that the process needs to become overly heavyweight as a consequence, though. And you certainly don't need to discard your rollerblades and mountain bikes...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Recommendations for a bug tracker?
 
Similar Threads
bean method's convention
regarding deadlock
Scrolling through a textarea
JavaRanch site navigation
Super Bowl XXXVII