|
FogBugz baby yeah! 
|
|
|
|
|
|
Just to chime in here, I'm quite happy nowadays using GitHub's issue tracker. And it was painless[^] to integrate into the client's website, so they can keep tabs on issues. 
That said, I've worked with several others, and as others have posted, they all pretty much suck. One day I will write a decent bug tracker, one that is configurable to the project needs, isn't dog slow, doesn't clutter your screen with a ton of "I don't give a sh*t about that field", is interactive rather than just statically showing issues, easily quantizable (think "sprints" but don't think "sprints")
And by interactive, I mean being able to say "here's some issues I'll be working on" and it could ask how progress is going, what issues / dependencies have been encountered, etc.
Marc
|
|
|
|
|
Thanks for the feedback. I like the GitHub articlet too.
It would be very cool to have something that integrated with Git &/or Hg so I could commit fixes, enter the bug number and then the same comment in the commit would go into the bug tracking software.
Yes, I'm dreaming.
|
|
|
|
|
newton.saber wrote: It would be very cool to have something that integrated with Git &/or Hg so I could commit fixes, enter the bug number and then the same comment in the commit would go into the bug tracking software.
I believe TFS will do that for you.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: believe TFS will do that for you
That's quite cool.
|
|
|
|
|
Back when I was a rookie, we used this tracking system[^]. I would not exactly call it software. It was more like a pile of analog electronics with a analog computer.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I've tried to introduce bug tracking, really I have, when the only choice offered is TFS on a REALLY slow server it is a little difficult.
Currently a user is most likely to stump up and bitch in the devs ear that his system is broken and he needs to fix it! Alternatively a printed page of excel list is left on his keyboard by some anonymous user.
QA team hah hah hah hah hah hah hah hah hah hah hic!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I totally understand and guessed that at least 25% of the responders would say something like what you've said. I've experienced the same often. When I asked the QA team how they would track the bugs, they said, "uh, well, we can email them". Ugh!
|
|
|
|
|
Bugzilla and its sufficient.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
I like the Bugzilla icons. HOnestly, it looks like one of the better ones, but looks possibly difficult to configure. But maybe they're all difficult to configure.
|
|
|
|
|
Not too difficult. There are some good tutorials to do this. Might take you a couple of hours (2 to 4) creating a bugzilla server on linux.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
I've installed a bugzilla server and what the tutorials are lacking is things relating to the webserver part... I used apache2 and I had to first enable the website on the webserver (not in the tutorials) before it worked. If you can see apache2 start (index) page from your web browser, it tells you on there how to do it.
Hope you find success (I almost gave up).
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >></div>
|
|
|
|
|
Previously Rally, now ClearQuest, moving to Jira in near future.
Marin
|
|
|
|
|
Numerous people are moving to JIRA. I've used it and it feels quite bloated to me.
I want something simple that reads my simple mind and makes my bug tracking simple.
Good luck with the transition.
|
|
|
|
|
Long ago, we used something called Perfect Tracker.
It had a web interface, with a custom search facility that was vulnerable to SQL injection attacks.
Turned out to be its most useful feature...
|
|
|
|
|
Staffan Bruun wrote: vulnerable to SQL injection attacks
Bug tracking software with the bugs already in it.
|
|
|
|
|
Did you try Excel Online ?
|
|
|
|
|
In one way I hope you are joking.
In another way -- since my QA people use nothing except outlook to report bugs -- I think you are on to a simple idea that really could work.
I'm stuck in an endless looping paradox.
|
|
|
|
|
|
|
|
In the last year I've used Teamforge and Redmine. In the past I've also used irRational Clearquest  , SharePoint (worked great as a simple bug list, especially since SP was familiar to our non-technical users), and (many years ago) Visual Intercept. Currently IT is soliciting interest in how many teams would be interested in replacing TeamForge with JIRA. Although they're currently calling it "voluntary" I expect that within a year they'll decide it'd be cheaper to shut down teamforge than to pay licensing fees for two trackers and force everyone else to switch as well.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Our change request system (bugs, enhancements, new functionality) is built into the application (client/server, .NET, SQL Server). Users can request a change from within the application and it then goes through a management/development process. Works great for us.
|
|
|
|
|
We use mantis. It's not amazing, but it works.
We know PHP and have modified the workflow (shocked it is not data driven to configure).
But after customizing it and using it since it was Beta, it is kind of second nature.
Our applications allow the end user to email in issues with/logs if they have crashes or problems.
We had to put a simple script on the server to pull them into mantis.
I agree. They all have drawbacks. We use a process where we RESOLVE things, and then
the clients CLOSE them (okay, we close them during an interactive meeting with the Clients,
as they confirm the resolved issue is published).
We use it for 3 reasons:
1) Visibility/Planning
2) Communication/Process
3) EOM and EOY Summaries. Very cool to to show 70% of annual effort was on New Features!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
