Bug recording and reporting packages.
-
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
I've used FogBugz, and it worked for us. Personally, email filtering didn't work very well for us, but maybe it was never set up right. I've also used Bugzilla and that worked for us as well. And the price was right. :) Currently using TeamTrack. (No idea what the "business mashups" stuff is all about). Not enough experience yet to comment on it, but it seems more polished than either of the others. Good luck.
-
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
Flyspray is another open source, web based, bug tracking system solution that we have been using for a couple months now and works well. http://www.flyspray.org[^] If has ability to automatically assign. E-mail notifications for a number of events. Updating Status And a host of other features (that we haven't gotten around to using yet). Good Luck!
-
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
We use www.spiceworks.com While it is not a bug reporting and reporting package, we do use the trouble ticket part for tracking issues.
-
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
I've used a few different ones. Currently we use Clearcase DIMS. It's a bit of a top-heavy app, but it works ok. We're transitioning to tracking defects via Quality Center. I can't say that I recommend doing that as so far it's been a mess to get setup and ported to. By far the easiest and simplest I've used is Mantis (http://www.mantisbt.org/[^]. It's simple to set up, easy to use, and if you have any php experience it's fairly easy to tweak.
-
We're thinking about using this? Do you have any opinions on this product?
SG Cause is effect concealed. Effect is cause revealed.
It is horrible. It was written by a guy as a way to learn asp.net. That's not just a put down, but a statement by the author. The author did not use code-behind and considers that a feature because you can just put a revised aspx file in the web site without recompiling. Stay away from bugtracker.net! My last employer forced me to implement this software for their issue tracking which was replacing an entirely paper based tracking system. They went with it purely because it was free. They weren't even willing to consider the $400 site license of another commercial product.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
-
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
-
We're thinking about using this? Do you have any opinions on this product?
SG Cause is effect concealed. Effect is cause revealed.
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.
-
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
Been working with Jira - and saw others using it too (and rather large companies). Cannot recall the entire feature list, but it did seem to have everything we needed. No stability issues.
-
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
-
http://ifdefined.com/bugtrackernet.html[^]
Best wishes, Hans
[CodeProject Forum Guidelines] [How To Ask A Question] [My Articles]
We've been using BugTracker.NET for a couple of months now. It appears to have a fairly complete feature set. (I just use it, don't administer it.) David
-
I've been using BugTracker.NET for a year or so now, at two different companies. It isn't very slick, the colour scheme is awful, design is pretty messy. For for a team of 4-6 developers, a couple of testers, BA's and PM's it works OK. Especially considering the price (free). Takes about 10 minutes to setup if you have MS SQL and an available IIS server. It is easy to make a few modifications if you need them, although once you start that you get a desire to rewrite the entire thing :-) So personally I would recommend it, because it is easy to install, easy enough to use, does most things I can think you would want a bug tracking piece of software to do, and because it is free you don't need to justify the price to managers etc - which always seems to take a while. Good luck Andrew
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
-
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.
-
It is horrible. It was written by a guy as a way to learn asp.net. That's not just a put down, but a statement by the author. The author did not use code-behind and considers that a feature because you can just put a revised aspx file in the web site without recompiling. Stay away from bugtracker.net! My last employer forced me to implement this software for their issue tracking which was replacing an entirely paper based tracking system. They went with it purely because it was free. They weren't even willing to consider the $400 site license of another commercial product.
Michael Lang (versat1474) http://www.xquisoft.com/[^]
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.
-
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.