Bug recording and reporting packages.
-
We've used Bugtracker daily for the past eight months. It's intuitive, has tons of features and does the great job for our team of five. We are opening it up to a larger group shortly. It does lack the auto-response, but being open-source you can add this feature. The code to do so in available but I haven't made this patch yet. It's highly configurable, especially if your tsql skills are average. There's also a excel export if the reporting is an important consideration. All in all I'd go with Trac, for the Project management/wiki features, but I'm in a .net shop so this works out well since the skillset to manage the system is inherent. Best wishes.
If there isn't already enough contradictory advice in this thread to thoroughly confuse you, and you want still more, I've put together a page of links to discussions on this exact topic, comparisons of issue tracking systems.
-
I used to work with Fogbugz and it was ok. (3 years ago). It may be great now. Changed jobs to a company using Problem Tracker (NetResults). Didn't like that at all. Messy, slow, not configurable enough, hard to have more than one window open per user at a time. Changed jobs recently to a company that made me select a solution. :-) They had just started with BugTracker.net. It is free, and it works reasonably well. I wanted something that gives more control over the workflow though, so I ended up buying OnTime (axosoft.com) I'm very happy with it and I get nothing but positive feedback from my users (web developers). We have dozens of active projects. Customers can log in to the customer portal and I can configure exactly what they can see. When they report a defect, incident or request a feature, the item gets assigned to the appropriate project leader automatically. E-mail notifications go to customers when an item is rejected or approved, and after it has been fixed AND tested. Nothing gets lost or is forgotten anymore. Also... Quick and adequate responses from their support staff if you do have an issue with their product. Cheers, Speertje
Regarding "I wanted something that gives more control over the workflow", this was a weakness of BugTracker.NET. About a month ago, though, I added the file "workflow.cs". There's a stub function in it that BugTracker.NET will call. My function doesn't enforce any rules, but if you replace my function with yours, there's your workflow. You would have to know just enough C# to code some "if" statements. I haven't gotten any feedback on it, so I don't know if anybody is using it yet.
-
I'm the author of BugTracker.NET. This might be the statement that Mike Lang is referring to, from the BugTracker.NET documentation at http://ifdefined.com/doc_bug_tracker_programmers.html#code I started BugTracker.NET in 2002 as a learning project, to teach myself .NET and C#, to get those technologies on my resume. At the time I didn't own Visual Studio, so I went about learning .NET the same way I had learned Java in its early days: I downloaded the SDK, edited files using a text editor, and compiled using the command line. If you work with the SDK and the documentation of for the .NET libraries, you won't even come across the term "code-behind". Code-behind is a Visual Studio concept, not a .NET concept. I didn't know about code-behind when I created BugTracker.NET and so BugTracker.NET does not use that technique. It's not a philosophy. It's just how I happened to start the coding. Mike Lang, I'd be interested in your critique of BugTracker.NET's functionality, as opposed to the coding style.
There are some helpful features in the tool, but if you want to do more than minor cosmetic changes you have alot of work ahead of you. The code is full of spagetti code on top of the lack of code behind, which makes it really hard to wade through. I'm sure you, the author, knows exactly where everything is and how to make the UI look at behave exactly how you want. However, most people will have difficulty. I tried to move the validation error messages on edit_bug to the top of the screen. I couldn't figure out how to do it via the css capability in a way that didn't put the error messages on top of the issue form inputs. I did post a question asking for help with no reply. My next course of action was to wade through the code, and that was just a pain so I gave up. My employer didn't want me to waste more than a couple hours on it. Also, there was the problem of how to handle incorporating changes from new versions into code customizations. Overall, moving the error messages using code just wasn't worth all the effort. Another oddity I found was when I created custom fields in 'development' and then later tried to migrate all the changes to 'production'. I used Redgate SQL Compare to migrate the structure changes and the data changes to the meta data tables. When we ran the code in production, the custom fields appeared on the form in the wrong order, but most importantly when an issue was saved the entered values went to the wrong columns. The issue had to do with how column 'meta-data' is stored, in that some code somewhere is querying the columns by the order in syscolumns and somewhere else is using the configured order in the meta-data tables. I didn't drill down to the actual problem lines of code. But the solution was to manually edit the metadata in the production database so that the order matched the syscolumns order. Sql Compare does not use syscolumns directly which is why it did not see a difference. It is bad programming practice to use syscolumns like this in the first place, and totally couter-intutive to do so when the 'column order' is supposedly defined in the 'meta-data' table. I don't remember the other issues we had off the top of my head. I did post some in the sourceforge forum. You did a good job answering many issues and I commend you for the didication. That's great if the tool works for some people, but I wouldn't recommend it. Would you rather use a tool that was designed to meet the needs of it's users, or a tool that was a learning project? I a
-
There are some helpful features in the tool, but if you want to do more than minor cosmetic changes you have alot of work ahead of you. The code is full of spagetti code on top of the lack of code behind, which makes it really hard to wade through. I'm sure you, the author, knows exactly where everything is and how to make the UI look at behave exactly how you want. However, most people will have difficulty. I tried to move the validation error messages on edit_bug to the top of the screen. I couldn't figure out how to do it via the css capability in a way that didn't put the error messages on top of the issue form inputs. I did post a question asking for help with no reply. My next course of action was to wade through the code, and that was just a pain so I gave up. My employer didn't want me to waste more than a couple hours on it. Also, there was the problem of how to handle incorporating changes from new versions into code customizations. Overall, moving the error messages using code just wasn't worth all the effort. Another oddity I found was when I created custom fields in 'development' and then later tried to migrate all the changes to 'production'. I used Redgate SQL Compare to migrate the structure changes and the data changes to the meta data tables. When we ran the code in production, the custom fields appeared on the form in the wrong order, but most importantly when an issue was saved the entered values went to the wrong columns. The issue had to do with how column 'meta-data' is stored, in that some code somewhere is querying the columns by the order in syscolumns and somewhere else is using the configured order in the meta-data tables. I didn't drill down to the actual problem lines of code. But the solution was to manually edit the metadata in the production database so that the order matched the syscolumns order. Sql Compare does not use syscolumns directly which is why it did not see a difference. It is bad programming practice to use syscolumns like this in the first place, and totally couter-intutive to do so when the 'column order' is supposedly defined in the 'meta-data' table. I don't remember the other issues we had off the top of my head. I did post some in the sourceforge forum. You did a good job answering many issues and I commend you for the didication. That's great if the tool works for some people, but I wouldn't recommend it. Would you rather use a tool that was designed to meet the needs of it's users, or a tool that was a learning project? I a
Mike - that's for taking the time to respond. Regarding the code full of spagetti and me knowing exactly where everything is... actually, I wish that were true. The code is hard for me too, but I would argue that even if I had done everything right, there is complexity in the requirements/functionality, so there is going to be complexity in the codebase, no matter how well organized. Bug tracking sounds simple, until you throw in configurable workflow, permissions, custom fields, and then the interaction of those things. Then it gets hard. In my blog, at http://www.ifdefined.com/blog/[^], you'll find that a lot of posts are essentially me just whining about complexity. I didn't sit down in 2002 and write the application full blown with all its features. It has evolved. But, something I want to point out is that I have not broken backwards compatibility in those 5 years. I have felt a duty to the people who trusted me enough to depend on my application not to break compatibility. But, as Microsoft can tell you, preserving backwards compatibility also contributes to a complicated codebase. You mention FogBugz. If you think my codebase is daunting, imagine FogBugz. They created their own freakin' programming language to handle their complexity issues: http://www.joelonsoftware.com/items/2006/09/01b.html[^] For another glimpse at complexity, read the "Status" section from this Jira issue. Jira is a very widely used issue tracking system: http://jira.atlassian.com/browse/JRA-1330[^] Regarding the position of the validation error messages, moving them with css, I apologize for not answering that post. I also would not be able to do it using .css. Another developer recently volunteered to help with BugTracker.NET and what I asked him to do was to make the edit_bug.aspx friendly to css positioning. We'll see how that goes. Regarding the way I used syscolumns, well, it's a bad design by me, but because of backwards compatibility issues, I may be stuck with that design. I'm glad you were able to workaround my design mistake. If nothing else, I need to update the docume
-
I'm the author of BugTracker.NET. I've made some improvements in how BugTracker.NET looks "out-of-the-box", but if you still don't like the appearance, you have a lot of control via css and some other configuration files. Here is more info about customizing the appearance of BugTracker.NET: http://ifdefined.com/doc_bug_tracker_css.html
Hi Corey, question to the author of BugTracker.NET: do you know any migration tools (in my case from FogBugz) to convert old data into BugTracker.NET DB format? Thank you in advance Gr. Sergey
-
Hi Corey, question to the author of BugTracker.NET: do you know any migration tools (in my case from FogBugz) to convert old data into BugTracker.NET DB format? Thank you in advance Gr. Sergey
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
-
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
Thank you for your answer. I definitely mail you SQL script if management decision will be to switch from FogBugz to BugTreacker.Net.
-
Sorry, no. I'd probably go about it by just writing SQL statements like insert into [some BugTracker.NET table] select ..... from [some FogBugz table] You might find it helpful to use "SET IDENTITY_INSERT [some BugTracker.NET table] ON", which allows you to insert rows into a table without SQL Server incrementing the identity column automatically. If you do succeed with your conversion, I'd be grateful if you emailed me your SQL.
-
-
I realize I am opening up a can of worms here, but we need an easy to use bug recording package at my current company. One to record the bugs. Allow assigning of developers, updating status, generating reports, etc... Preferably with the ability to automatically assign, and respond by e-mail. Thanks for the input and abuse! Bill
Wow... lots of great comments here. This is my take (add it to all the other opinions). Some of the pay products are great. Fogbugz, JIRA, etc. But that cost A LOT. Fogbugz is 25 bucks a month per person. We have 100 folks working at my company. There is no way they are going to buy that (I tried). Mantis, Bugzilla, etc are free... but their interfaces are kinda crappy. They are open source projects and were made for programmers by programmers. We tried a few of these and our non-tech staff were confused by them. In the end we created our own simple bug tracker . It doesn't have all the bells and whistles as some of these other systems but it caught on at my company and a few of our clients asked to use it on projects we weren't involved in, so we made a product of it. If anyone is looking for a dead simple bug tracker, check us out www.thekillingjar.com.