Bug管理经验和实践(下).docVIP

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