Franktcc

Some people don't understand why there are always so many bugs in a developing product. If I can bend your ear a moment, I like to explain how it happens. Let me ask you a question that how often do you make a mistake in your daily job? You probably say "well, it depends. I would make more mistakes if I am new on the position, and less mistakes if I am kind of familiar with all the tasks". See, as long as you realized the bugs are born from engineer's mistakes, you can imagine how many bugs can be made in a complicated product which needs many engineers get involved. The total bug number of a product is close to the sum of every single bug made by involved engineers. Here comes a problem. If you are either a programmer or a tester, how many bugs can you remember at the same time? one? five? ten? Note that you at least have to keep in mind not only the steps to reproduce but also the bug status. The worse part is that you must be confident with the answer when your boss is asking "how is the status of the bug?". How could it be possible? Not to mention that the boss usually likes to know the bug statistic. (ex. Severity-A 10 bugs, Severity-B 21 bugs, etc) Somebody says "Well, I can use post-it notes, can't I?" Yes, you can do that until your boss fires you 'cause you can't find the damn note from hundreds of notes within 10 seconds. Boss normally has no patience, remember that? Above explains why a good software development needs a "Bug Tracking System (BTS)". Quoting from Joel on Software, keeping a bug database is one of the hallmarks of a good software team. If you are working "on a team of ten" which claim that they are professional and don't need any kind of BTS, I would suggest either you persuade your boss to build one or you quit immediately. There are many bug tracking system "on" the market including FogBUGZ which was promoted by Joel on his article. Some useful rules for a BTS, 1. Every bug can only be assigned to one person. A bug is like a hot potato: The assignee can only either solve it or assign it to somebody else. :D 2. Every bug can only be closed by its creator who is most likely a tester but a programmer. 3. Bug status should be real-time reported to every relevant person via e-mail. 4. Once BTS built, programmer shouldn't accept any other kind of bug report, such as e-mail. 5. Avoid the temptation to add new fields to the BTS. Don't easily give in to some clever ideas provided by engineers. If you do, your bug entry will end up with a hundred fields that you need to supply. It results in slowing of a bug report and confusing people.

Franktcc

Mar. 8, '10

Article Reference: http://www.joelonsoftware.com/articles/fog0000000029.html

#####

To assure me of being able to memorize unfamiliar vocabulary and idioms easier, I am writing some articles by use of these words with hyperlink. Please DO NOT "infer" any conclusion from the content of articles as they might be not based on the truth. ^_^ PS. My friend, Please correct me if I use any word improperly, it will be highly appreciated.

#####