作为一名软件测试工程师，我们的角色可以算是“战场上的后勤”，战役的胜败和所有团队人员都息息相关。但是难免碰到战役失败后，很多团队互相推脱的局面，而测试人员就是所有团队中的弱势群体，自然是首当其冲的背锅侠！相信你在做测试时肯定听过下面这些话吧：
“哪有这么多测试时间，你加快点测就完了”
“这么明显的bug居然没测出来，这关我们开发什么事”
“出现这么多bug，你当时怎么测的啊”
“仔细核对下需求，这个不是bug”
“这么低级的bug你都测不出来吗？，你到底怎么做测试的？”
“这么明显的bug都没测出来就让我们上线了”
“研发时间不够，你压缩一下测试时间”
“你测出问题要第一时间和我们反应啊，谁会每时每刻盯着禅道去看刚提的bug啊”
我相信很多测试猿听到这些话都会被气的直哆嗦，脾气爆一点的恨不得立马吵架，干架。所以研发团队里谁最受伤，我说测试第二，谁敢说第一？
但是在生气之余，我们得反思一下自己是否有地方需要改进，尽量减少精神内耗的发生。你要相信世间之事总有应对之法，如果你工作感觉很累，那肯定有什么地方需要改变了。就像我之前提到的，测试人员除了需要埋头苦干的“智商”，更需要点“情商”在所有团队成员之间斡旋，既要将测试工作做好，也要保障自己的利益。我从事测试八年之久，形形色色的研发人员见得太多了，发生的摩擦次数当然也比走过的桥多，但我始终相信方法总比困难多，今天就给大伙分享一下个人心得。
下面列出几个比较常遇到的沟通问题，结合具体情景，给出具体对策：
“哪个用户像你这么操作？”
相信很多测试小伙伴老被开发这样吐槽，但是如果我们真的顺着开发去测试了，那我们测试存在的意义何在？
解决方式：
开发一般只注重需求的实现即可，而测试人员要始终站在用户的角度思考问题，在测试过程中，我们不妨将用户想象成一名“老人”。老人可能对于很多浅显易懂的功能都是不会用的，所以我们测试时对易用性就要特别关心。但是用户具体对哪里陌生，用起来费事，我们不可能完全知道，所以只能尽可能地去覆盖到位。当然我们也不必过分担心，毕竟用户也是成年人，且对该系统比外行人会更了解。
但是一开始开发肯定还是一根筋地把需求实现就完事了，所以我们得在平时就给他们灌输用户至上的理念，让他们多想想用户的难点，也是给他们自己后期减少麻烦，何乐而不为？我相信开发在你强大的PUA攻势下，肯定会有所改变，双方沟通的多了，也习惯了双方的工作方式和思维模式，那么下一次出现这个问题的时候，会更快更好的解决。即使开发不耐烦，测试也要多多提出来这类的问题，这是帮助开发进步的一个方式。
总之：一切站在用户的角度看问题。达成共识很多问题就不会是问题了。
（如果你中了头彩遇到个硬茬，说啥他都不听，那你可以第一向领导反映，第二做好沟通的记录，将来秋后算账也是维护自己利益的好证据。）
“你这提的bug根本无法复现”
解决方式：
如果你经常遇到开发说这样的话，那么你得好好检讨一下自己了。首先检查自己提交的bug描述是否简洁，正确，易懂，重点是否突出，复现步骤是否精准，复现的概率；
如果你觉得你自己已经做到了这点，开发还是说这种话，那么你可以跟他当面沟通，看看是哪里还需要改进，哪有有什么误会；
如果你发现自己做的已经足够好，开发还是抛出这样的话，那么你可能需要将具体的bug给到相关人员，特别是上级去看了，以证清白了！
“需求没规定的怎么能算bug”
我以前遇到过一个bug，在一个OA系统登录界面上，注册时用的大A开头的用户名注册的，结果用小a输入依旧可以登录，这就是典型的未作大小写区分导致的。提了bug给开发，开发却回到：“用户没有要求做大小写区分，所以这不用管”，这可能是客户默认的应该有的功能，只是未写到需求中，开发就以此为借口。诸如此类的bug会有很多，所以这就很考验测试人员的经验和坚持。
解决方式：
如果遇到这类问题，首先要参考市面上主流的产品或者系统是什么样的基本功能，如果和主流的有区别那就要加以注意了。其次呢如果自己无法确定是否要提这样的bug，可以让PM或者产品来做决定，即使他们否定了你的建议，你还是得做好记录以防他们事后甩锅。
“这不是代码问题，需求就这么定的”
解决方式：
所有的需求都是人定的，既然是人定的，肯定会存在异议的地方。如果测试人员发现某处需求设置的不合理，是可以找需求人员了解清楚，为什么这么定，然后进一步和需求探讨，再看他们怎么决定。如果你能讲得有理有据，我想先需求一般能被说服，当然很多时候是测试不太了解客户需求，反而被需求说服了哈哈，这当然也是好事。
但是如果遇到有些需求比较强势，既说不出道理，也听不进测试的话，那这种情况你可以先找领导协商一下，如果领导也偏向于需求，那只能作罢了，但还是那句话，你得把这个沟通结果和这个发现的bug记录到禅道等缺陷管理工具中，以后也有证可查！
“你这个bug是其他人负责的，我这边的都是正常的”
相信很多测试的小伙伴会经常发程序猿甩锅的现象，如前端推后端，后端推前端。作为测试人员夹在中间反而感到尴尬，仅凭测试人员有限的开发知识又不可能准确知道具体是谁的bug，这该如何是好呢？
解决方式：
遇到此类情况如果去找PM定夺，当然是很快能解决的，但是如果次数多了就显得我们测试很业余了。那该怎么办呢？其实很简单，只要把开发拉到一个讨论组，把具体问题在讨论组里说一下，让他们自己认领，如果还是有问题没人认领或者互相推脱，那就只能将该bug记录下来，并和PM第一时间反馈，这样该bug即使出现在在客户面前，你都是有理的。
现将软件测试人员如何避免成为“背锅侠”总结为以下几点：
避免“背锅”是软件测试人员日常工作中非常重要的一项任务。以下是一些建议：
1.明确责任和任务：
在项目初期，确保测试人员与项目团队一起明确测试任务和责任。明确测试的范围、目标、计划以及各自的角色，避免在后期因为责任不清晰而产生问题。
2.参与需求评审：
积极参与需求评审，确保对需求的理解一致，避免由于需求不清晰或理解偏差导致的问题。
3.提前介入项目：
尽早介入项目，确保在需求和设计的早期阶段就开始测试相关工作。这有助于早期发现和解决潜在问题。
4.详细记录测试过程和结果：
在测试过程中，详细记录测试用例、执行过程、环境配置以及测试结果。通过详细的记录，可以追溯问题的来源，避免因为信息不足导致的责任争议。
5.及时报告问题：
发现问题后，及时向开发团队和项目管理人员报告问题。不要将问题留存在测试环节，及时沟通问题有助于避免问题扩大化。
6.合理评估测试时间：
在测试计划中合理评估测试时间，确保有足够的时间进行全面的测试。过于紧张的时间安排可能导致测试遗漏或质量不足。
7.建立良好的沟通渠道：
与开发团队、产品经理和其他团队成员建立良好的沟通渠道。开放式的沟通有助于及时了解项目进展和发现问题。
8.定期进行进展汇报：
定期向项目团队和管理层汇报测试的进展情况，以及已经发现的问题和解决方案。及时的进展汇报有助于项目团队全面了解测试工作。
9.主动学习和提升技能：
持续学习新的测试工具、技术和方法，提升自己的测试技能。通过不断提升技能，能够更好地应对各种测试挑战。
10.参与项目总结和复盘：
在项目结束后，参与项目总结和复盘，分析测试中发生的问题，提出改进意见。这有助于总结经验教训，为下一个项目做好准备。
11.谨慎接受任务：
在接受任务时，要理性评估自身的能力和项目的风险。谨慎接受任务，避免因为无法完成任务而被迫承担责任。
12.与团队协作：
与团队成员保持良好的协作关系，共同解决问题。团队的合作和协同努力有助于项目的成功。
通过上述建议，软件测试人员可以更好地规避责任风险，确保测试工作的质量和有效性。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
