（转载）这到底是不是Bug？

感觉这篇文章不错，针对发现的一个问题是不是bug时的一些解决方法，值得学习，就以原创形式转载，请大家见谅，也谢谢作者Tester Chen分享。

随着软件行业的快速发展，以及客户、市场的高要求，软件本身的复杂度、要求不断提高。这一现象也直接导致以前只有大中型公司才配备的测试人员，现在在越来越来越多的小型公司也开始出现。
小公司测试人员的出现，一方面是为了适应产业的发展需求；另一方面也是为了提升产品质量、加强公司的竞争力，保证公司不被市场所淘汰。但这样一来也就直接增加了公司的管理、人力及资金成本（测试人员的薪水虽然相对比开发人员低，但也是一个不小的数字）；最后因为小公司制度及管理的欠缺，暴露出很多问题，往往直接或间接的导致开发、和测试的不和谐，这也是我们今天讨论的话题。

这个是缺陷！这个不是缺陷！
对于是不是缺陷这个话题往往被很多人很厌恶，大家都厌恶谈论这个话题，因为谈及他往往令人不愉快，但很多的时候他却在我们身边真实发生。
测试人员认为某个情况是缺陷，但开发人员认为这个不是缺陷，而争论具体的情形在需求中也没有明确的描述，公说公有理，婆说婆有理，说不清了！如果只是开发、测试对于工作上理解的差异还好，但往往争执由此开始，矛盾也就由此产生，不和谐的气氛由此埋下种子。

出现上述的情况的原因有几种：
①公司在没有对原始需求进行评审、整理、并书面化形成文档（需求也是需要测试的，这点很重要）
②公司完全没有需求这一档子事，完全在没有需求的情况下进行开发、测试（走一步看一步的情况）
③开发、测试对需求的理解存在差异（开发、测试没有良好的沟通）
④需求本身的定义存在二义性（与①相关，没有对需求进行测试）
⑤个人的性格与情绪

问题出现了，如何解决？
不管是开发人员还是测试人员：
①思想要保持统一的认知，我们所做的都是为了公司，为了我们的产品，任何的争论都不存在任何的个人感情与感情色彩
②出现问题时，都要先从自身找原因，很多时候往往是因为我们自己的简单思维而导致，所以，当你在工作中对某个事情存在疑问时，多问自己几个为什么，再向他人请教，或回复他人
③我们讨论的只是问题，不直接关系到个人的工作能力与工作作风，人非圣贤，有错就改，并不失面子

当无法确认是否为缺陷时，测试人员：
①发现无法确认的缺陷时，如果有其他的测试人员可以征求其他测试人员的意见（同行评审，同行评审往往能发现80%的问题），如果彼此都认为此应该是缺陷时，可以找到相应的开发人员进行讨论。如果开发人员同意你们的意见，则可以提交缺陷，着手修复（如涉及比较重大的业务逻辑时应该要向上级汇报，申请确认）
②如果开发（甚至多位开发人员）对缺陷不认可时，我们可以向测试组长（或测试总监）请教，请求对缺陷进行确认，如果领导和开发人员都认为此不是缺陷，并且无修复的必要时，我们可以保留我们的意见，同时记录下此缺陷（到后期如果有时间再进行评审）
③如果测试组长（或测试总监）也认为此是缺陷，但在无论如何解释的情况下开发人员仍不认可时，我们可以由测试组长（测试总监）与开发项目经理（技术经理）进行交涉、确认，最终确认缺陷情况
④如果有必要，我们可以邀请开发、测试、需求（如果有）、产品（如果有），甚至技术总监（CTO）进行开会（需求或缺陷）评审
⑤最后，也是最重要的一条，不管是开发，还是测试，都不要越级汇报

另外，有部分许多公司把缺陷作为开发人员和测试的员的业绩指标，在某些大公司这些确实是在施行、也是可行的，但在中小型公司或管理达不到CMMI4或5的情形时，我个人不赞同那样的作法。因为你不是他，你就做不到他……
而你那样做产生的直接结果就是让开发和测试从此不和谐，彼此勾心斗角，何必呢？！