标签：
因为bug有没有修复的问题，我和测试干了一仗。这是我工作近八年来第一次。
而我也是第一次在没有bugzilla或者jira这样的问题跟踪及管理工具的情况下干活。
每天我拿到的buglist是当天的bug文档+昨天的bug文档+前天的bug文档+大前天的bug文档+等等等。我希望项目赶紧上线，这样我每天就不需要看很多重复的（每天都看）、已经没有意义的（已经修复或不能重现或重复）bug。
每天巡逻查看bug文档的时间随着测试周期的开展递增。我努力将属于自己的bug放在自己的视野里，整理在todolist，因为项目紧急，测试介入的时候开发任务还没有完成，我需要将每日的进度及修复的bug（到后期只发修复bug）发邮件回复并抄送各种人。
所以，问题一很明显：时间成本。每个相关开发、测试、产品的时间成本。每个被抄送人的时间成本（我个人不喜欢抄送各种领导，但有时很无奈）。
除了每天早上我来公司先走一圈上述bug文档外，每天下午还要去回归bug。开会要等电梯等人等安插投影仪。讨论确实可以使我知道很多事情，但我觉得这种事情我可以通过其他方式更便捷的获取，并且还能留有备份。
这种备份就是对bug的注解。而不仅仅是对bug状态（修复与否）的改变。
所以，问题二：bug跟踪、问题注解。
注解，有助于知道一个bug为什么存在，也能审查是否有类似bug出现；方便自己遇到类似问题的解决思路。
状态标识，有助于快速跟进此bug，避免重复阅读验证；
不是所有的bug都会在项目时间内解决，在这种情况下如何平衡？
你如何评定你的项目风险？应该不仅仅是因为bug数量。
所以，问题三：bug优先级的设定。
优先级的设定一般都是做用例评审时根据功能、性能、用户体验、可用性等标准来评判。设定的标准不同，也会导致对项目风险评估的差别。
优先级的设定的可靠程度取决于测试的经验和对项目的理解能力。
优先级出来后，就需要根据bug的轻重缓急来处理。每一个消灭bug的人都懂，fix掉bug的感觉最爽。特别是解决一些优先级高但简单的问题。
尽管大部分的bug是在它正确的级别队列里，但也有漏网之鱼。一些隐晦的bug可能牵扯到你处理问题的解决思路，它们看起来优先级低，但也许很重要。这要看你是否能够很快判断出这个问题背后隐藏的坑。
个人认为在完成代码后，代码自审是扫雷的第一步。不仅做了一次代码重构、梳理业务，还能让你找到一些隐匿起来的问题。
优先级的设定，会让项目里的人清楚项目风险；每一个bug修复，也会让人很清晰的看到目前的风险。
也能让你在项目周期内未搞定的bug，对项目上线的风险影响，以及项目所能承受的风险做出比较评估。
项目风险谁来背？人都是喜功不喜过。但出来混就是有风险的，人也是要有担当的。那么谁来背呢？
在我以前的团队，项目谁发起，有谁背。一般都是产品经理是产品、项目的直接负责人。如果有项目经理参与的项目，项目不能如期上线，这是项目经理的职责。
但作为团队成员，项目风险是每个人都应该主动扛起的。你需要对你负责的部分负责，这也是起码的职业操守。
所以，问题四：bug修复率、bug重开率、放弃延迟率，都是项目参与人对项目风险的评价标准。，也是对个人能力的一个评价标准。
能够将此加入考核，也可以平衡部分人的压力，让团队的人更加具有责任心。虽然我们期待每个人都尽心尽力有主人翁的精神，也难免懈怠，有这样的准绳也是不错，客观公平，有数据可查。
bug是每个项目人都需要面对的。没有bug的系统也几乎是没有的。界定bug、bug跟踪、管理，是我们参与项目就会遇到的问题。如果有好的工具，那为什么不用呢~不要以为我们的项目更新迭代的速度快，就可以置之不用。试想一下，把bug放在一个好用的jira上，给众人开发权限好呢？还是把bug放在一个word文档上，给众人群发邮件好呢？
其实云平台可以告诉我们答案。经过实践证明的工具，会比我们重新摸索好用。至少我们现在这种状态，需要一个工具支持。期待有关方面能尽快提供这方面的支持~
标签：
原文地址：http://www.cnblogs.com/hanyuxinting/p/4205302.html
