Bug tracking software have to do a few things good:
Step 2. Make it easy to enter a bug
Easy, right? Lets think about the process of entering bugs. What information do you want to enter to make a good bug description, now that you have managed to crash the program or discovered where the program sucks. You could choose from a plethora of information.
Error information
Screenshots
( I have not seen a single program which lets you capture this information within the bug tracking software, except as attachments. Attachments do not tell the story in a sequence.)
Logs
(same as above. The bug tracking software makes no effort to learn about the crashed program. Chances are if someone already has entered a bug for the software, the bug tracking software can learn where to look for logs, what logs are important and what else the program can attach “just in case”)
That sequence of whacky actions you did that managed to crash the program.
Step 1. Search previous bugs information.
I purposely put Step 2 before Step 1. Most of the times you run into a bug, you don’t immediately get the feeling that hey someone before already ran into this problem and maybe I should search our greate bug tracking software to make sure it not already in there. Once you collect some information on the bug, it might cross your mind to search for previous such bugs.
Now folks, most programs suck here. Can’t search text let alone search attachments, or any other field that might make sense. Forget any intelligent matching of language. After all, people write differently.
Some bug tracking software that reside in my mind’s hall of shame (these are just the one’s that I have used):
1. Mercury Quality Center
2. Any Siebel based Bug tracker
3. Compuware TrackRecord
Feel free to enlighten me to the world of better software management.
This entry was written by , posted on January 18, 2006 at 11:16 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.
Yes I mean it. Put your developers in the Quality Assurance role. Atleast once in their lifetime every developer should spend time exclusively in the Quality Assurance role. You know what happens? Your regular QA folks get better at figuring out problems due to the close interaction. The developer’s attitude get better towards the frustrations QA guys feel when dealing with bugs that keep reappearing or annoyances built into the software. Result? The developer’s code gets better.
Your developers may kick and scream. The good ones are going to make use of the opportunity and make the code better. They are going to make the quality assurance team better.
Don’t think about it. Just try it.
This entry was written by , posted on at 11:11 pm, filed under Uncategorized. Leave a comment or view the discussion at the permalink.