问题
I found a lot of questions asking for the best tool, but none asking for the features, you really need? And what features you never really needed?
(I caught myself to be comparing tools on feature matrices. Something I hate, because in the end I will be using only the 3-4 most important features and leave the rest untouched.)
回答1:
It need to:
- collect bugs
- order bugs on priority/severity/due date etc
- assign bugs to developers
- track a bug history
- link similar bugs together
- link bugs to customers
- link solved bugs to releases
- provide enough information or a reference to get the information to reproduce the bug
- usable by more than one developer
- bug status need to be accessible by the client that reported the bug.
And there are more.
回答2:
Simple end user data entry. Without this you won't have bugs entered, which equals worthless bug tool.
回答3:
I can't answer this question for you, because I can't predict what is important for you, or what your situation is:
- Are you on a large or small development team, or are you a one-man shop?
- Would it be useful to have a system in place where you could have your application automatically send in trouble reports that create incidents in your bug tracking software?
- Is being able to predict a release schedule important, or is this just something for a side project you're doing in your spare time?
- Is integration with source control important?
In reality, you're the only one who can answer what features are required for you.
回答4:
Those are the 3 must-have features I find most important:
- Web interface so people can follow-up
- Source control integration, otherwise it's really hard to track who did what and deploy patches
- Configurable workflow with email notifications
回答5:
Things I would really like to see:
1) Voting - i.e. how many customers/users does this bug hurt?
2) Severity/priority/whatever - the distinction between these terms is subtle and normally (IMHO) insignificant, but you have to have some idea of how important the bug is. Most tools have this, but overcomplicate it.
3) Dependencies - both internal (on other bugs in the same system) and external (external libraries, software, etc). Most bugs have this in reality, but it's not normally expressible in the database, leading to long, pointless debates at triage time.
Things I think are largely pointless:
1) Any extensive questionnaires - any bug-tracker that asks too many questions will just get bad data. That's worse than none.
2) Controversial, but compulsory daily/weekly/whatever email notifications. They just get filed as spam/ignored/filtered out. If developers should be fixing bugs, and aren't, that's a management problem. Software cannot fix this.
回答6:
Need:
来源：https://stackoverflow.com/questions/318996/what-should-a-good-bugtracking-tool-be-capable-of