A bug is anything that bugs someone who matters

connie

一个对bug的定义的问与答，也许我们也经常在工作中碰到这种问题。值得一看。

Q. My company’s QA team is relatively new, only a few years old. We are still learning about our profession, and appreciate articles and information from recognized experts such as yourself. Can you help, or at least, point me in the right direction, on a question that’s a big source of contention between our QA and Development teams?

There is an issue of “what constitutes a bug?” Some developers believe that true “bugs” can only be caused by malfunctioning code, and anything else is merely a matter of opinion. They believe that if you don’t get a sql error or exception error or some other screen-swallowing alert, it’s not a bug, regardless of how it works.

The QA staff believes that usability issues, poor navigation, and even bad design also constitute bugs, since they invariably return from the customers as such. We base this belief on what we have seen in our customer bugbase over the past few years. Developers say that customers are too picky, and QA says that the customers pay the bills, they have a right to be picky. We should anticipate their “pickiness” when we develop code.

The philosophical debate rages on. I don’t expect you to settle the debate, but do you have an opinion on this question?

A. A bug is anything that bugs someone who matters. Testers matter. So, especially do customers and users and management. Bugs don’t necessarily mean that the developers made an error or should be blamed. But they still need to listen. Someone needs to be in a position to decide which bugs will get fixed and which will be deferred. It should be whoever decides on the approval of new features, a third party. Programmers have a responsibility to provide rough estimates of cost to fix, and testers should provide an estimate of impact if left unfixed—usually via a severity rating.

阿布虎

Thanks for writing so many.