做一个靠谱的软件测试工程师还需要哪些技能：

+ 软技能

+ 沟通

+ 其他软技能

上一篇靠谱文章中写到的技能，称之为硬技能，可以这样说硬技能决定了你在职场道路上走多快，那么软技能就是决定了你能在职场上走多远，而对于软件测试人员来说良好的沟通是不可缺少的。

为什么沟通会成为软件测试人员必备软技能？

是因为软件测试人员不像开发人员可以少说多做，开发人员就算是沟通能力不高也能在职场中上升，但你一定会注意到在职场中一定是那些沟通能力强的开发人员上升特别快，如果上升了且沟通不咋的，那么一定是那类编码技术特别牛，缺一不可的开发人员，但这类开发人员只适合做事，不适合做管理。

如果你觉得你的技术也能让领导和伙伴忍受你的坏脾气，那么你可以不用想着怎么提高你的沟通能力。

不过我们始终是那一类普通的角色，所以提高你的沟通能力，避免做无效沟通也是我们的技能中必不可少的一部分。

那我们应该怎么提高自身的沟通技巧呢？

1.明确沟通的对象

与测试人员打交道一般来说只有二类人群：

一类是开发人员

与开发人员沟通最多的就是针对BUG，这是不是一个bug？如果是bug需要怎么改？什么时候能改好等等问题。

另一类是产品经理

与产品经理沟通主要是围绕需求，开发和测试对需求理解不一致时，找产品确认；对需求有疑问的，找产品咨询；这个需求本次迭代需不需要做，等等。

针对这二类人，其中又以与开发人员打交道最为居多，当然并不是说我们只与这二类人沟通，只是说相对别的团体，这二类沟通居多，有时我们也需要与项目经理、UI等沟通，只不过相对少一些。

2.有效沟通

沟通就是人对人说话，如果对方能理解，并且能解决问题，那么沟通就算有效。

沟通说起来简单，做起来却相对很难，与对方交流时，对方与你不在一个频道上，说这事扯到另外一件事上去了，有时真想仰天长叹，老天爷，请赐一个懂我的开发。

为什么在与其他团队交流时容易起冲突呢？

最近这几天正在成甲老师的《好好学习》，其中有这样一段话：

当我们感到自己的观点、尊严可能会受到挑战的时候，我们第一反应不是思考对方的挑战和质疑是否合理，而是：有人敢反对我，和他干，这时候，我们的习惯性防卫就产生了。 我们之所以会习惯性防卫，还有一个很重要的因素：我们会把别人对我们观点的质疑，理解为对我们自己的否定。换句话说，我们常常不自觉地把“我”和“我的观点/行为”绑定在一起。 比如，别人和我开会讨论时说：“成甲，你上次项目做得太烂了。”此时，我的第一反应可能不是去思考我的项目是不是很烂，他说得对不对；相反，我觉得他是在针对我、指责我，我就会回击：“胡说，你做项目才烂！”这样，我把别人对自己观点/行为的质疑理解为别人对我这个人的质疑，从而激发起自己的习惯性防卫。

想来，我们每个人都是这样，每当别人在跟我们说事时，我们自己总能将它上升到是对自身的攻击，而不能平心近气地就事说事。

比如，在测试过程中，遇到某个问题：

测试人员：XXX，这个地方你代码写得不对，有bug。

开发人员（心理已经开骂了）：不会的，在我的电脑上都是能实现的，没问题啊。

测试人员默默地再次测试，发现问题还是存在。

测试人员：XXX，这确实是一个bug，短信始终推送不成功

开发人员：不可能，你配置数据了没？

开发人员：你会不会测试哦？

测试人员：。。。。。。

面对这样的情况，开发和测试都认为自己是正确的，这从一开始就是敌对，如果碰到一个很自我的开发很容易就起冲突了，那如果碰到这类开发，我们应该怎样去沟通？

王豆豆经常使用的方法就是一问二试三确认：

一问

比如刚才那个短信推送不成功的场景，遇到这样的问题，首先找对应的开发确认。

王豆豆：XXX，给用户发送短信，需要在哪里配置数据么？从哪个表里面取用户的手机号？

开发人员：需要在系统管理界面配置一个定时任务，定时触发发送短信任务，用户的手机号从user表中取。

如果是聪明的开发会将配置界面截图发给测试，如果遇到不聪明的，那就直接问他要。

二试

根据开发说的操作，在测试环境上配置，并且去查相关的表，确实表中的数据是否正确存储？值是不是取正确了？

配置和查表完成之后，就再次测试，确定结果。

为什么会做这样一个操作？目的就是为了防止是自己没有配置数据或是测试环境的问题而引起的BUG，从而避免开发人员觉得测试人员不够专业。

三确认

如果经过前面二个步骤，BUG还是出现，这时可以找开发确认了。

王豆豆：按你刚才说的配置了，为什么短信还是没有推送成功？查看了定时任务已经执行了，你看下。

同时附上配置的截图，定时任务和bug出现的截图（相关的截图)。

大多数的开发这时都会想是不是代码出bug了，检查一下。

所以按上面几步执行，基本都不会出现冲突，有问题改问题，没问题也不会造成开发和测试双方纯洁的友谊，哈哈。。。

上面这种场景是针对需求很确定，开发在实现需求时出现的问题，测试人员在与开发确认问题时的沟通手段。

另一种情况是需求不确定，开发和测试对同一个功能有争议，比如开发觉得可以这现在实现，测试觉得可以做得更好。

比如，以下这个场景：

王豆豆：XXX，搜索条件中的申请时间少了默认时间，建议加上。

开发人员：。。。。（开发人员甩不甩你）

如果碰到这种情况，开发不愿意改，觉得可有可无，而测试人员从用户体验性方面考虑又觉得一定需要，那这个时间千万不要和开发争吵，直接去找产品经理确认，产品经理说需要，那开发人员一定会改，如果产品经理说不需要，作为测试人员也不必纠结这这个问题。

一般来说在沟通中做到以下几点：

1.需求不确定，找产品经理确定

2.BUG不能确定是否需要修改，找项目经理/测试经理/开发经理确定

3.确定的BUG，直接提缺陷管理平台

4.不确定是否BUG，先找开发人员确认，确认的步骤可以试下一问二试三确认

特别是针对某BUG，开发人员不愿意修改的情况，千万不要和开发人员直接起冲突，但也不能听开发人员说这个不重要，不需要修改这些屁话，直接发邮件找上级确定是否需要修改，在邮件中写清楚从测试角度这个bug为什么必须要修改？如果不修改会造成什么问题等情况。

这里其实是一个面试题：

当你提出一个BUG时，面对开发人员不愿修改，这时你会怎么处理？

答案就在前面，需要自己总结和归纳。

最终，不管这个bug是不是要被修复，都需要记录到缺陷管理平台，只有记录在这个平台上，才算是你对这个测试点有测试到，如果后期这个地方真出现问题了，你说你测试过，但开发说不需要修改，这时就口说无凭，谁又会相信你呢？

在项目中经常会开一些讨论会，其实就是撕B大会和甩锅大会，沟通技巧和前期留下的做事痕迹（邮件）就变得很重要了，当然我们做这些并不是为这一刻，而是这些做事方法也是专业的体现。

沟通作为测试人员重要软技能之一，测试人员一定要学会进行有效地沟通，在沟通中既要坚持自己的观点，又要听取其他人员的意见，避免冲突，始终坚守沟通是为了解决问题，而不是个人与个人的PK赛，最终能将问题完美解决，而又不损同事情谊。

经常听人说测试人员在项目团队中没有发言权，其实测试人员并不是没有发言权，而是需要你在发言的时候需要提出有理有据的理由，有实际的解决方法，这样其他团队的人员才能信服，才能提高项目质量，从而体现测试人员的价值。

今天写的测试人员的沟通软技能，软件测试人员想做软件测试工作必须还需要掌握其他的软技能，欢迎大家告诉王豆豆你经常使用的软技能还哪些？