What bug tracking system do you use?

Pipelines
1

I’m curious to hear what bug tracking systems people out there use.

We’ve used (ahem…):
[ul]Post it notes on monitors for our first game Death Rally in 1996… (shipped with 0 known bugs unless you count the DOS installer… :)[/ul]
[ul]Excel and post-it notes for Max Payne 1 (shipped with 0 known bugs… :)[/ul]
[ul]Bugzilla, Alienbrain Bugs (lord help us) and random emails for Max Payne 2 (shipped with a few known bugs, especially on PS2)[/ul]
[ul]Bugzilla for Alan Wake (will ship with 0 known bugs… :)[/ul]

We’ve looked at JIRA, but it really seemed like more complicated than Bugzilla without adding much more usability.

We’ve also looked at the “thing” that Microsoft uses internally, but that seemed overly complicated and not really usable for us due to some security paranoia.

We’ve got some kind of hack bridge built between Bugzilla and MS’s bug tracking system, but I’m not really sure if it works properly or not.

Previously with Rockstar Games we collaborated with their bug system (FileMaker Pro) manually with the dog slow and awful web interface.

Right now, our Bugzilla is slightly customized so that the “barrier to enter a bug” is much lower than usually. So that all you pretty much need to enter is:
[ul]Game vs. Tools[/ul]
[ul]High/Med/Low[/ul]
[ul]Description and re-pro steps[/ul]

In the real life, what usually happens is that when most artists/designers enter a crash, they find a tech art person and explain what happened. Then the tech art person usually asks the artist/designer to repro what happened and (if it is reproducable) then the tech-art person re-pros the same case on his own workstation, tries to minimize/optimize the steps to reduce it (so actual debugging is easier/faster) and then posts the bug.

We have a culture where the poster of the bug is the only person who is allowed to close the bug once fixed, so maintaining a solid “how to reproduce the bug” case is very necessary.

Hmm, this sounds like tech art is sometimes complementary to the QA… Well, I guess it is, but tech art is more involved in the tools and the mysterious things that QA can’t rep-ro. :slight_smile:

SamiV.

2

Internally we use a simple text file, since we are only a couple of guys all in the same room, that is easy enough.

When working on a XBLA title, it involved Microsoft and an external testing company, and so in that case we used Microsofts web-based bug tracking tool.

It wasn’t to bad, a little slow at times and dealing with bugs going back and forth usually feels pretty tedious no matter what tool you use.

Its a bit like talking about what tools you use to clean your ‘septic tank’. Some tools maybe much better then others, but it remains an unpleasant topic :slight_smile:

take care,

3

We’re currently using Jira… It took me a while to get it all configured and pruned down to just what we needed, but it does the job quite well. (yes, my TA role also includes bug-tracking and source control admin in conjunction with the Lead Programmer)

The best feature imho, is it’s ease of use. Anybody can open a browser and manage all their bugs right then and there; no applications, no nothing. You can’t do some of the more complex searches of some other products, but I’ve yet to not find another way to get the same results

It ridiculously customizable; workflows, fields, you name it. It also has a pretty robust plugin system for triggered events and Altassian has some decent add-ons for code-review (if you’re into that sort of thing) and source control integration.

The back-end is just a vanilla SQL server, allowing unfettered and direct access to anything you want; very convenient for tool integration, etc.

4

We use our own internal bug tracking asking software. It’s pretty good. It needs a few features but its fairly easy to use. We used Bugzilla on Sopranos and I’ve used Activision’s tracking software on Shrek the Third.

5

For years we’ve used an in-house web-based bug/task tracking system, with SQL on the backend (and Cold Fusion, of all things). We have a newly rewritten one ready to deploy for coming projects, but I don’t know much about it. Just that it’s written better, with a few new features.

We’ve evaluated several off-the-shelf replacements over the years (not sure what exactly) but so far nothing has fit the bill for one reason or another.

6

Bugzilla worked pretty well at Whatif Productions when I was there. Pretty simple really.

Was nice that you could attach screenshots if needed. Wasn’t nice that you couldn’t edit previous posts, if you made a mistake, or if the first poster didn’t know what they were talking about.

Same situation as the OP… whomever posted was the only one supposed to close it, a coder fixing the bug could mark it fixed, but the QA had to confirm to actually close it.

Bugzilla did have a problem sending out emails though, admin never got that to work with Exchange for some reason.

7

I don’t work for a game studio but I feel this topic is general enough that I’ll chip in.

We settled on bugNet (http://www.bugnetproject.com/ )for the last few development projects and I really enjoyed working with it. It is an open source web solution, sadly written in asp.net but it is the best we found to fit our needs. Comparing it to some of the other solutions posted here, it is pretty basic in comparison.

We also give close rights only to whoever is in charge of QA. Initially when one marked a report as ready for QA it would stick in the developer’s inbox. We changed that for the latest project to where it physically moves it to a QA category so once you mark it as done, it goes away and you don’t have to look at it anymore. Psychologically I find this helps a lot :smiley:

8

No games here either, but TV series. We started with notepad/ultraedit text files, for fixing scenes etc. When more people came on board, it became problematic, overwriting each other comments etc. So I have written a php/mysql “projectnotes”. It’s sorta of like a forum but each thread related to a file/scene and can have a different status. The status can be defined for project needs, so sometimes you want a file to be fixed by in our case mocap operators, the director, or someone else. So if a file is fixed, you change the status to “needs reviewing” and the appropriate person can start reviewing that on his own time. Also in the system there’s a way to assign a rating to a scene so that junior mocap editors don’t messup a difficult file. It’s not flawless, but it’s way better then notepad and problems with overwriting other peoples input.

-Johan

9

In the past we used MANTIS and the various publishers’ databases, which was a hassle. We now use Hansoft’s bug system since we use Hansoft for project and document management as well. Our QA Manager works with the QA Manager on the Pub side to keep databases in sync. He also tries to keep really stupid useless bugs from reaching us.

10

When we get to choose, we usually use Bugzilla. Otherwise, whatever the publisher want us to use (there tends to be a lot of testing on the publisher’s side, so we need to conform to their setup)

11

We’ve got our own system, it allows us to assign/track/edit/close bugs. It’s integrated with the engine too, so that 1 keypress on a devkit will take a screen shot and create a new bug for you to fill in the details.