不是测试人员的“锅”，要怎么“甩”？

作为资深测试人员，你是不是经常听到这样的话，为什么这么LOW的BUG会出现在客户手上？为什么功能没测完就发给客户测？这个BUG不是代码问题，需求是这么定的？这个需求不合理，开发表示拒绝，等等需要测试背的“锅”。

所以从一开始，测试就要关注需求。往往在讨论设计时，开发和需求很容易忽略了测试，他们潜意识里觉得这不关测试什么事。可是，测试也要熟悉业务，熟悉功能，熟悉各种设计，而且测试需要站在用户的角度来去考虑他们的设计是否有不合理的地方，并提出自己的建议。这些工作，测试人员需要主动，积极参加，多提建设性意见，这样可能会让开发慢慢发现测试人员的重要性。
其次，沟通最频繁应该还是关于bug的讨论。下面列出几个遇到的沟通问题，及我的解决办法。
1、“这个bug我无法重现”
解决方法（参考）：
类似问题首先要自己反思下，bug重现步骤是否没有说清楚。Bug应该简明扼要，重点突出。如果描述存在歧义，一定要及时纠正并积极改善。有时会遇到概率性的bug，要告诉开发概率是多少，尽可能多的提供重现条件。
2、“这不是代码问题，需求就这么定的”
解决办法（参考）：
需求也是人定的，如果觉得有异议，可以找需求人员了解清楚，为什么这么定，然后把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。不过我们可以把沟通结果备注在这个BUG下，以后也能有证可查。
3、“这块是别人负责的，我负责的部分没有问题”
解决办法（参考）：
如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。
4、“有问题吗？”（也就是开发认为这不是个问题）
解决办法（参考）：
测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，开发总觉得无大碍。比如，一个列表默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能，而且也有解决办法，所以不认为是bug。这个时候，需求能定的可以打需求决定，需求不明确的，要好好跟开发沟通，可以让他在有时间的时候处理，不需要急着马上处理。
5、“用户不会像你这样操作的！”
解决办法（参考）：
测试过程中，我们可以要把客户想像成“白痴”，他会怎么操作，谁都想不到。我们也不可能覆盖所有可能性，但是大多数用户会出现的操作，我们当然要测试。慢慢地把开发从代码的世界里带出来，带到用户的世界里，让他换个角度思考问题，毕竟软件开发不是为了实现功能，是要满足用户需求的。如果最后还是没能说服他，第一向领导反映，第二做好沟通的记录，将来备注在测试报告里。

除了bug上的问题，还有测试安排上的问题，有时候小功能没有做好，或者某个文档、图片没有上传，等小功能做好了文档上传之后，很可能开发忘记告诉测试。所以，平时的工作中，一定要主动记录问题，主动沟通和督促，并反复确认，不要怕麻烦。
总结起来，测试在工作上要主动询问，态度上不能轻易妥协，习惯上要善于记录细节，方法上软硬兼施。