相信很多测试人员在工作中都会遇到某些bug没有测出来这种情况，就是测试完后，给生产线，生产线发现软件问题会反馈。
就会出现，测试推开发，开发推需求，需求推客户变更。
而这种模式是追责找背黑锅的做法，不是优化、解决问题的做法。
如果每个环节都是护好自己，有问题就想办法推出去，作为测试人员，一定要留好证据，必要的时候作为自保。
比如测试设计、测试用例、测试用例评审结果、测试执行结果、测试时间、开发延期时间记录、bug单记录、遗留问题和风险判断记录等，随时准备开撕。
如果产品团队是真的想把产品质量做好，做有口碑的好产品，而不是找人背锅，找到一个人并把他干掉，然后其他人继续心安理得、按部就班的做事情。
那么，不追责任，只分析问题，并提出改进建议，不断的PDCA，才是好的方向。
在这种立场下，就事论事的的说，“软件测试完后，还有BUG，是测试人员的问题吗？”，答案是不一定，可能是测试的问题，也可能不是测试的问题。
举几个例子：
一、在测试用例中的场景，操作，没有发现bug，产品发布，这肯定是测试人员的问题。
这种问题经常发生在多轮次的测试中，反复的执行同样的用例会有疲劳感。
当一个新版本迭代后，可能一些基本的测试用例就不执行，根据经验直接pass。通常会没有事情，但是一旦有事情，就是测试团队的主责， 甩都甩不掉。
从解决问题的角度，方法也有很多，比如建立准入机制，每个流转到测试的版本，都必须满足进入条件，比如把基础的测试自动化，减少正向用例的疲劳操作，比如增加单元测试等等，不再枚举。
二、开发的蓄意隐藏，导致bug留出，这肯定是开发人员的问题。
在一些小概率复现的bug上，很多时候开发解决问题是拼人品，可能屏蔽几行代码或者增加打印信息，问题就莫名其妙的好了。
甚至项目紧的时候，开发就随便改点东西，要求测试人员验证，结果测试人员也撞大运，复现了两天没有出现问题，就认为bug修复了。
此类的问题，追溯下来，肯定是开发人员的责任，毫无疑问。
这种问题就不好解决了，通常而言，对小概率复现的问题，横向走读代码、代码提交审核规范可能比较有效，但是这么复杂的流程，也只有大公司才玩得起 。
三、产品实际使用超出想象，导致产品的bug，这就是全团队的问题。如果还能存活，就当吸取经验吧。
规划一款新领域、业务的产品，对这个领域可能没有深入的理解，那么可能会导致一些意想之外的bug。
比如我经历过的某车载产品，如果要实现某外挂设备的转动功能，有皮带和齿轮两种方式。新产品，新领域，从历史经验和成本等角度，选择了皮带。但是产品卖了一年多，发现在各种环境影响下，皮带非常容易老化，导致功能失灵，返修率很高，只能改版迭代。并不是没有经过老化测试和试验局，在试验局的时候，因为周期短（一个月），也没有暴露问题。老化测试使用的是室内产品的标准，得出的数据也是非常喜人的。
你能说这是测试的问题，或者开发的问题，或者硬件的问题，工艺的问题。只能是大家经验不足，是团队所有人的问题。
四、产品发布后，在某种操作系统下出现兼容性的问题，是谁的责任？也不一定。
4.1、主流的系统，比如win7，有兼容性的问题，机会肯定是测试的问题，没有覆盖主流的系统。
4.2、历史系统，比如xp，有兼容性问题。但是规格明确写明不支持xp。
那么有可能是市场调研、需求的问题，没有搞清楚产品的实际客户和特性。
也有可能是用户手册的问题，没有提示不支持XP，导致错误的安装。
还有可能是软件的问题，没有做保护，检测到是xp系统，就应该停止安装并提示系统太老。
而不是闷着头安装完，出现一些兼容性的问题。
总结一下，Bug是产品团队的问题，需要整个产品团队一起扛。要是各部门推责任，找替死鬼，那么测试就要做好过程数据，方便自我保护。如果产品团队有产品意识，产品经理试图做好产品而不是甩锅，那么坐下来讨论，具体的bug可能是不同小组的问题，想办法优化和改进就可以了。
以下是软件测试工作中的沟通问题
从一开始，测试就要关注需求。
往往在讨论设计时，开发和需求很容易忽略了测试成员，他们潜意识里觉得这不关测试什么事。
可是，测试也要熟悉业务，熟悉功能，熟悉各种设计，而且测试需要站在用户的角度来去考量他们的设计是否有不合理的地方，并提出自己的建议。
这些工作，测试成员需要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试成员的重要性。
其次，沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题，及我的解决办法。
1、“这个bug我这边重现不了啊~~~”
解决办法：这种问题首先要自省，bug描述里面是否没有说清楚。Bug应该简明扼要，重点突出。如果描述存在歧义，一定要总结并尽快改进。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现的条件。对于开发说的我本地是好的，我开发环境是好的，尽量不要去反驳，而是给出清楚的证据，告诉他，测试环境没有问题，是程序的问题！
2、“这个不是代码问题，需求这么定义的”
解决办法：需求也是人定的，如果觉得有异议，可以找需求人员询问清楚（一般都是找产品经理或者是研发老大），为什么这样定义，把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。但是我们可以保留交流的记录，证明曾经在这里发生过歧义。
3、“这块是别人负责的，我负责的部分没有问题。”
解决办法：如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
4、“有问题吗？”（也就是开发不认为这是个问题）
解决办法：测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，就要发挥测试的本事了，嘴甜一点，说说好话，态度柔和一些。因为既然是小问题，解决起来一定不难，耐心地催开发的改过来就好。催一次不行催两次，记住态度一定要好。
5、“用户不会像你这样操作的！”
解决办法：用户怎么操作，谁都预料不到。我们不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向上级反映，第二做好沟通的记录，将来备份在测试报告里。除了bug上的问题，还有测试安排上的问题，有时候小功能没有做好，或者某个文档、图片没有上传，等小功能做好了文档上传之后，很可能开发忘记告诉测试。所以，平时的工作中，一定要主动记录问题，主动沟通和督促，并反复确认，不要怕麻烦。
总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施
