bug管理的经验和实践3（下）.docxVIP

Bug 管理的经验和实践（下） 在这个系列的前面两篇文章里，我们先是探讨了 Bug 管理的理念和 意义，然后又从软件系统的构建角度更进一步探讨了 Bug 管理技术层面的问题。这次我想 我们应该来探讨Bug管理中□人□的问题了。当然，所谓人的问题，就是管理制度的问题。 有了先进的理念、坚实的软硬件基础，还需要有相应的管理制度与之相配套，否则 Bug 管 理就只是一个摆设。你认为一个软件开发团队应当制定严格的 Bug 管理制度吗？没有一个 相配套的管理制度，会有怎样的后果？ 我们在第一篇文章中讨论过，微软的软件研发可以总结为以下两点： （1）．需求（PM）、开发（Dev）、测试（Test）三权分立，分工明确、各司其职 （2）．每个产品的每个版本遵循同样的模式：流程＋工具＋人，并不断反馈（以改进流程、 升级工具并提高团队/员工的能力） 回到你这个问题，Bug 管理制度其实就是定义 Bug 处理流程，有了好用的工具之后， 我们需要这样的流程去明确指导如何对 Bug 进行管理。但是一个软件开发团队应当制定严 格的 Bug管理制度吗？坦率的讲，不需要。严格的制度在软件行业就意味着教条、负担和 不切实际，让一帮聪明的大脑陷入无边无际的条条框框不能自拔，明知道是包袱还要去背、 是火坑还要去跳，直到有一天终于受不了，最终结果不外乎三个：过劳累到、对付一天是一 天或者干脆辞职换个工作。因此我觉得应该用□Bug管理指导原则（guidance）□来替换□Bug 管理规章制度（rulesregulations）□这个词。 所以我认为Bug管理就是去制定适合自己团队实际情况的Bug处理流程和指导原则， 制定者（管理层）应该起到真正指导的作用，他们要非常清楚下面这些问题的答案： l 我们需要测试什么：哪些软件（网站）、哪些模块 l 测试人员的分工：什么人负责什么模块 l 测试工具和环境：巧妇难为无米之炊。你不能安排一个测试人员去测某个模块，而 没有给他提供必要的软硬件环境 l 测试的进度安排：干这一行加班是不可避免的，但是需要有度，人不是机器，长期 的劳累谁都扛不住。如果时间很紧，那只能去抓重点，要有所不为 l 发现一个问题时，如何用Bug管理工具去创建一个Bug：标题如何写、严重程度、 详细重现步骤、错误状况、期望结果、现场附件、这个Bug去分配给谁 l 当一个Bug被处理掉时，测试人员应该如何验证并关闭 l 当一个Bug的解决方法有争议时，谁来仲裁 l 定期的Bug提醒，比如当前每个人的Bug情况 l Bug状态报告：Bug数目的变化趋势及我们应该采取的行动 l 阶段性的总结反馈：哪些地方我们做的好，哪些做的不好，为什么、如何改进 l …… 没有这样配套的 Bug 处理流程和指导原则，再好的工具都将会是一个摆设、甚至是添乱的 工具。就像一个乐队有非常出色的各种乐器，但乐队指挥是个外行（就像成龙电影《双龙会》 一个镜头），那么演奏出来的一定会是混乱的乐章。  根据你的了解，国内中小型软件开发企业中 Bug 管理制度方面有什么缺陷？主要的 问题是什么？ 我想目前中小软件企业的Bug管理主要存在的问题是： 1. 不重视测试，认为测试人员无关大局，随便测测就行了。当然这种情况正在逐步好转， 因为大家都开始意识到了测试重要性； 2. 有些企业，认识到测试的重要性后，却走向极端 --- 制定了极其严格的规章制度：无数 琐碎、难用的测试工单、非常严密的一级级权力控制，在 Bug 管理系统中谁能看到什 么信息、谁可以解决、谁可以关闭等等，非常严格。一个需要灵活变化的工作变成了工 业制造车间流水线的一个工种，让测试人员陷入制度的泥潭，不能把主要精力投入测试 工作本身； 3. 管理层自身没有制订明确的Bug处理流程及相关指导原则，让测试人员在黑暗中摸索， 走到哪儿算哪儿，不能给他们以切实有效的指导和帮助； 4. 管理层把软件的质量保证责任一股脑推到测试人员身上，任何问题都去指责下面的测试 人员，殊不知测试仅仅是研发的一个环节，前面需求、开发两个环节如果没有好好做， 测试将会极其被动，比如：没有需求文档，怎么测试？这是一个系统工程； 5. 错误的考核标准：管理层用 Bug 个数去衡量测试人员的工作成绩，谁发现的 Bug 多谁 的工作就做的好。这是一个十分危险的倾向，将直接导致测试人员去重视 Bug 个数这 个数字本身、而不是产品的真正质量。 遗憾的是，即使在微软内部，各个地方研发中心也有这个倾向，比如经常出现大陆、 台湾、韩国、日本四个地方某个软件的测试人员虎视眈眈的在半夜