Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

coldacid

Bug tracking: Categories/components?

This topic is 5186 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

For those of you who use a bug tracking system, what sort of categories or components do you break your projects into? On top of that, are there any that you break down further? (Also, if anyone uses Mantis or Bugzilla for tracking, want to send me tips on managing defect tracking software?)
Christopher S. ''coldacid'' Charabaruk <chrisc''at''meldstar''dot''com> [personal site]
Meldstar Entertainment -- Creation, cubed.


Every time I think I''ve heard it all from SCO, they come up with a new howler." Steven Vaughan-Nichols, eWeek

Share this post


Link to post
Share on other sites
Advertisement
We use primarily the following categories for sorting:

1) Severity - the most important number, goes from 0 to 4, 0 being a must-do and 4 usually being a minor UI tweak.

2) Status - primary categories are "just created", "assigned to programmer", "ready to be tested again", "fixed". There are others (notably "on hold")

3) Owner - only one at a time, but can be changed at any time. Usually correlated with status.

4) Project - individual projects have their own flag fields.


Components include:
-Description of recreation scenario
-Build # in which fix is fully implemented
-unique ID (for interdepartmental discussions)
-environment to which bug applies
-owner/status change log

hope that helps

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t know how large your development team is, but we have our product broken down into specific areas that people can post bugs against (ie file manager, editor, etc). Each area has a default developer and tester (which can be changed as needed). We then have a ranking system for rating the bugs (must fix, down to feature request).

We also have a field for a general description, and another field for steps to reproduce. Then we have a third field that allows anyone to commment on the bug (usually this is manager/developer/QA).

Share this post


Link to post
Share on other sites
AP: Your first para is the sort of thing I''m looking for. But I''m wondering specifically what components you''d break a game project into.

I use the category term only because that''s what Mantis calls them (and that''s what I''m using, only for the ease of install over the much better Bugzilla).

Share this post


Link to post
Share on other sites
IMHO, it''s a bad idea to use categories except in a very large application (millions of lines of code). It''s much better to have bugs directly assigned to developers. Trying to categorize bugs will inevitably lead to edge cases and unaddressed issues. Someone, either the tester, the QA lead, or some AP should assign each bug to whichever developer is most directly responsible for the portion of the code the bug is most likely in, and categories be damned.


"Sneftel is correct, if rather vulgar." --Flarelocke

Share this post


Link to post
Share on other sites
quote:
Original post by Sneftel
IMHO, it''s a bad idea to use categories except in a very large application (millions of lines of code). It''s much better to have bugs directly assigned to developers. Trying to categorize bugs will inevitably lead to edge cases and unaddressed issues.


That''s fine until you have more bugs in a system than a single developer can handle, and until you want to prioritize improvement of a particular subset of application code.

ld

Share this post


Link to post
Share on other sites
quote:
Original post by liquiddark
quote:
Original post by Sneftel
IMHO, it''s a bad idea to use categories except in a very large application (millions of lines of code).


That''s fine until you have more bugs in a system than a single developer can handle, and until you want to prioritize improvement of a particular subset of application code.

ld


Right. Like in a very large application.

I like pie.

Share this post


Link to post
Share on other sites
quote:
Original post by RenderTarget
Right. Like in a very large application.

We must be using different definitions of "very large", then.

[edit]By which I intend, millions of lines of code is not necessary in order to have this problem. I've seen the problem crop up in 5000-line systems.[/edit]

ld


[edited by - liquiddark on March 11, 2004 9:03:28 AM]

Share this post


Link to post
Share on other sites
quote:

By which I intend, millions of lines of code is not necessary in order to have this problem. I've seen the problem crop up in 5000-line systems.



Wow...too many bugs in a 5000 line system for developers to handle? Were all the functional lines missing?



[edited by - crazy166 on March 11, 2004 9:29:33 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by crazy166
Wow...too many bugs in a 5000 line system for developers to handle? Were all the functional lines missing?

Try writing production code when your functional specs are written by people who have no idea what they actually want sometime.

ld

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!