日常工作中，软件测试人员如何避免“背锅”

作为一名软件测试工程师，日常工作中最常打交道的肯定就是开发和产品经理。有沟通就会问题，有问题难免会有争执。那么你肯定听过这些话：

“这么弱智的bug你都测不出来吗？”
“为啥这个功能还没测完就上线了？”
“研发时间不够，你压缩一下测试时间”
“这个bug和开发没关系，注意看需求”

听到这些话，分分钟高血压，要说谁是超级背锅侠，那测试肯定当仁不让（要求追加“背锅费”）

问题的关键来了：作为测试的核心不是看人家的代码写的错不错，本质上要更关注需求。在开需求评审会的时候，开发和产品往往很容易忽略了测试，他们下意识会认为和下游没有关系。可是，熟悉业务，熟悉功能，熟悉各种设计是整个研发团队都需要达成信息共同的，而且测试需要站在用户的角度来去考虑他们的设计是否有不合理的地方，并提出自己的建议。上面说的工作，需要测试去主动，积极参加，多提建设性意见，让其他岗位的人认识到测试的重要性。其次，除了需求评审会沟通之外最频繁应该还是关于bug的讨论。下面列出几个比较常遇到的沟通问题，仅供大家参考。

“这有问题吗？”

（对方研发或者产品不认为是自己的问题）解决方式：在看待bug上，测试人员一定比开发要敏感，对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug，产品总觉得无大碍。比如，一个弹窗默认的宽度太小了，导致初次打开，有一些内容被隐藏在后面，但是这个宽度可以手动调节。开发觉得问题很小，不影响功能（开发往往只看重功能是否实现），而且也有解决办法，所以不认为是bug。这个时候，需求能定的可以打需求决定，需求不明确的，要好好跟开发沟通，可以让他在有时间的时候处理，不需要急着马上处理。

“这个bug我无法重现”

解决方式：先检查自己提交的bug描述，看看是否准确，bug重现步骤是否没有说清楚。bug应该简明扼要，重点突出。如果描述存在让人误解的表意，最好改过之前再给对方，如果还是无法解决就当面沟通，事后根据沟通内容来表述内容。遇到概率性的bug，一定要告诉开发概率是多少，尽可能多的提供重现条件。

“这不是代码问题，需求就这么定的”

解决方式：需求也是人定的，如果觉得有异议，可以找需求人员了解清楚，为什么这么定，然后把自己的想法告诉他们，看他们怎么决定。如果被需求说服了当然是最好的，如果自己还是不同意需求的看法，需求又不同意我的提议，那只能听他的，毕竟权力在他那里。不过我们可以把沟通结果备注在这个bug下，以后也能有证可查。

“用户不会像你这样操作的”

解决方式：测试过程中，我们可以要把客户想象成“儿童”，用户会如何操作，我们无法列出所有的操作选项，只有尽可能的去覆盖到位。不过也不用过分担心，毕竟用户都是成年人。开发的思考角度其实仅在于功能是否实现，而测试人员需要考虑的更多，所以也理解开发会说这样的话，但是为了更好的产品体验，多多提出来这类的问题，也是帮助开发进步的一个方式。双方沟通的多了，也习惯了双方的工作方式和思维模式，那么下一次出现这个问题的时候，会更快更好的解决。总之：一切站在用户的角度看问题。达成这样的共识，很多问题就不会是问题了。（但是最后还是没能说服他，第一向领导反映，第二做好沟通的记录，将来备注在测试报告里。）

“这块是别人负责的，我负责的部分没有问题”

解决方式：如果bug是由开发的项目经理来分发到程序员，那就是项目经理来面对这样的问题，而不是测试。当然，项目经理当然有项目经理的处理办法。可是，测试遇到这样的问题怎么办呢，把负责相关内容的开发都邀请到一个讨论组里，让他们自己讨论，这样更清楚，不必在测试这里中转。如果他们都觉得代码没问题，而我也有强有力的截图和真相，那就只有上交给上级领导，让他们来决定怎么解决。

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

关注我，让你的测试之路更简单~~~~