近来我遇到越来越多的人对我们会发布还有bug的产品大为惊讶。而让我大吃一惊的是，这些人中还有许多是软件测试人员，我本以为他们应该对此早已经有所了解。建议大家先阅读Eric Sink较早写的（但是很棒的）文章。不知道我还能对此话题有多少贡献，但我想试试。
许多bug并不值得去修复。“你这也算是测试人员吗？”，你肯定会冲我大叫，“测试人员是产品质量的捍卫者。”我可以再重复一次（如果需要的话）许多bug并不值得去修复。“让我来告诉你原因。在大多数情况下，修复bug就必须要修改代码。而修改代码需要投入资源（时间）并会引入风险。这真是很糟糕，但这却是事实。有时，如果风险和投入远超过修复bug的价值，因此我们就不会被修复这些bug。
我们决定是否修复一个bug并不是，也不应该是靠“感觉”。我喜欢用“用户痛苦”的概念来帮助我做决定。我会用三个关键因素来考虑并确定“用户痛苦”：
1、严重性 —— 这个bug将产生什么影响 —— 它会让整个程序崩溃吗？它会导致用户的信息丢失吗？或者并不是那么严重？有更简单的解决方法吗？还是它仅仅是个无关紧要的问题？
2、频繁性 —— 用户碰到这个问题的频率高吗？它是程序主要工作流程中的一部分？还是隐藏在一个并不常用的功能中？在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。
3、对客户的影响 ——如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少（或者是你希望有多少）用户。这样你就需要判断，这个问题将会影响到每位用户，还是仅仅一部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。
以上3点因素就构成了一个公式。给上面的每一个因素都分配一个数值范围，并且用一些计算 —— 你可以直接使用加法、乘法或是基于你的应用程序以及市场因素加上权值。打个比方，我们只需要执行加法并且对每个bug赋予10分的数值范围。
Bug #1：比如它是一个会让程序崩溃的bug（10分），它存在于程序的主要部分（10分），它影响了80%的客户（8分），因此这个bug的”用户痛苦“量值为28分，我们打赌我们肯定会修复它。
Bug #2：它仅仅是一个关于排列的bug（2分），它出现在二级窗口中（2分），这个bug所在的那部分程序只会在旧版本中被使用到（2分）。因此这个bug的“用户痛苦” 量值为6分，我们很可能不会去修复它了。
遗憾的是，很多情况并不像上面所说的那么简单。Bug #3是一个数据丢失问题（10分），它存在于一个应用程序的某个主要部分中，却只在某些特定的情况下才出错（5分）（顺便提一下，数据是主观编造出的）。客户研究证明它很少会被使用（2分）。因此它的 “用户痛苦”量值为17分，这是一个模棱两可的数据，修与不修都可以。一方面，修复它所需要的投入可能并不值得，只要这个问题能够被理解，并且它没有任何盲点，不再理会这个bug很可能是正确的处理方法。
- 从另一方面来看，你必须把它和系统中的其他bug进行权衡。我们在这里应用“破窗效应（Broken Window）”—— 如果应用程序中有太多此类中等阈值的bug，产品的质量（或者最起码，从质量的感觉上）一定大受影响。你在考虑系统中每一个bug的时候，还应该结合考虑系统中其他（已知的）bug，并且以此来分析、决定哪些bug是需要被修复的而哪些则不值得被修复。
正式发布的软件中有bug的确是一件十分糟糕的事 —— 但基于我们现有的开发工具和开发语言，我们还没有找到一个更加合理的解决方法。
补充：
写出这篇文章的时候，我想我遗漏了公式中的第四个因素：发布日期。临近发布日期时，这个因素在修复/不修复bug的决定中也起了关键作用。然而我并不确定它是否是第四个因素，也无法确定在临近发布时期时，修复一个bug所需要的 “用户痛苦”量值的阈值是多少。
可参见作者Alan Page原文：http://blogs.msdn.com/b/alanpa/archive/2009/09/30/why-bugs-don-t-get-fixed.aspx
文中所说破窗效应，参见： http://zh.wikipedia.org/zh/破窗效应
另补充Eric Sink的文章：我觉得写得更好。
The world's six billion people can be divided into two groups: group one, who know why every good software company ships products with known bugs; and group two, who don't. Those in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group two, a new hire on the team or a customer, who is shocked that any software company would ship a product before every last bug is fixed.
Every time Microsoft releases a version of Windows, stories are written about how the open bug count is a five-digit number. People in group two find that interesting. But if you are a software developer, you need to get into group one, where I am. Why would an independent software vendor - like SourceGear - release a product with known bugs? There are several reasons:
· We care about quality so deeply that we know how to decide which bugs are acceptable and which ones are not.
· It is better to ship a product with a known quality level than to ship a product full of surprises.
· The alternative is to fix them and risk introducing worse bugs.
All the reasons are tied up in one truth: every time you fix a bug, you risk introducing another. Don't we all start out with the belief that software only gets better as we work on it? Nobody on our team intentionally creates new bugs. Yet we have done accidentally.
Risky changes
Every code change is a risk. If you don't recognise this you will never create a shippable product. At some point, you have to decide which bugs aren't going to be fixed.
Think about what we want to say to ourselves just after our product is released. The people in group two want to say: "Our bug database has zero open items. We didn't defer a single bug."
The group 1 person wants to say: "Our bug database has lots of open items. We have reviewed every one and consider each to be acceptable. We are not ashamed of this list. On the contrary, we draw confidence because we are shipping a product with a quality that is well known. We admit our product would be even better if all these items were 'fixed', but fixing them would risk introducing new bugs."
I'm not suggesting anybody should ship products of low quality. But decisions about software quality can be tough and subtle.
There are four questions to ask about every bug. The first two are customer ones, and the next two are developer ones.
1) How bad is its impact? (Severity)
2) How often does it happen? (Frequency)
3) How much effort is required to fix it? (Cost)
4) What is the risk of fixing it? (Risk)
I like to visualise the first two plotted on a 2D graph, with severity on the vertical axis. The top of the graph is a bug with extreme impact ("the user's computer bursts into flames") and the bottom one has very low impact ("one splash screen pixel is the wrong shade of grey").
The horizontal axis is frequency: on the right side is a bug that happens very often ("the user sees this each day") and on the left, one that seldom happens.
Broadly speaking, stuff gets more important as you move up or to the right of the graph. A bug in the upper right should be fixed. A bug in the lower left should not. Sometimes I draw this graph on a whiteboard when arguing for or against a bug.
Questions three and four are about the tradeoffs involved in fixing the bug. The answers can only ever make the priority of a bug go down - never up. If, after answering questions one and two, a bug does not deserve attention, skip the other two. A common mistake is to use question three to justify fixing a bug that isn't important. We never make unimportant code changes just because they're easy.
Every code change has a cost and a risk. Bad decisions happen when people make code changes ignoring these two issues.
For instance, our product, Vault, stores all data using Microsoft SQL Server. Some people don't like this. We've been asked to port the back end to Oracle, PostgreSQL, MySQL and Firebird. This issue is in our bug database as item 6740. The four questions would look like this:
· Severity: People who refuse to use SQL Server can't use Vault.
· Frequency: This "bug" affects none of our users; it merely prevents a group of people from using our product.
· Cost: Very high. Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable. Adapting the backend for any other database would take months, and the maintenance costs of two back ends would be quite high.
· Risk: The primary risk lies in any code changes made to the server to enable it to speak to different backend implementations of the underlying SQL store.
Obviously, this is more of a feature request than a bug.
Example: Item 10016. Linux and MacOS users have problems over how end-of-line terminators show up. Last October, we tried to fix this and accidentally introduced a nastier bug that prevented users creating new versions of a project. So the four questions for 10016 would look like this:
· Severity: For a certain class of users, this bug is a showstopper. It does not threaten data integrity, but makes Vault unusable.
· Frequency: This bug only affects users on non-Windows platforms, a rather small percentage of our user base.
· Cost: The code change is small and appears simple.
· Risk: We thought - wrongly - that the risk was low.
If testing had told us that the risk was higher than we thought, we would have revisited the four questions. Because the frequency is relatively low, we might have decided to defer this fix until we figured out how to do it without breaking things. In fact, that's what we ended up doing: we "undid" the fix for Bug 10016 in a minor update to Vault, so it's now open again.
Contextual understanding
Not only do you have to answer the four questions, you have to answer them with a good understanding of the context in which you are doing business. You need to understand the quality expectations of your market segment and what the market window is for your product. We can ship products with "bugs" because there are some that customers will accept.
I know what you want, and I want it too: a way to make these decisions easy. I want an algorithm with simple inputs to tell me which bugs I should fix and in what order.
I want to implement this algorithm as a feature in our bug-tracking product. Wouldn't it be a killer feature? In the Project Settings dialog, the user would enter a numeric value for "Market Quality Expectations" and a schedule for the closing of the "Market Window". For every bug, the user would enter numeric values for severity, frequency, cost and risk. The Priority field for each bug would be automatically calculated. Sort the list on Priority descending and you see the order in which bugs should be fixed. The ones near the bottom should not be fixed at all.
I'd probably even patent this algorithm even though, in principle, I believe software patents are fundamentally evil.
Alas, this ethical quandary is not going to happen, as "Eric's Magic Bug Priority Algorithm" will never exist. There is no shortcut. Understand your context, ask all four questions and use your judgment.
Experienced developers can usually make these decisions quickly. It only takes a few seconds mentally to process the four questions. In tougher cases, gather two co-workers near a whiteboard and the right answer will probably show up soon.