我是Dzreal,工作三年的测试开发工程师。以下是我在测试工作中不断总结实践的,测试工程师需要具备一些软实力。

 

先看目录:

一、情商

二、沟通

三、责任心

四、流程控制

五、风险意识

 

这个话题,我相信80%的工程师都不会特别重视,因为这个东西说起来很虚,技术上有那么多东西要学,哪有时间提升什么软实力啊!

 

真香警告:你到底硬不硬,不是你的硬实力决定的,而是你的软实力决定的。

 

 

假如你的技术能力很扎实,你到35岁乃至65岁之后都还有能力写代码;但是你的软实力不行的话,可能你到30岁之后,你就很难在这个行业进步了,你周边刚毕业的同事都在跟你做同样的工作,你又拿什么跟他们拼?你头发还剩多少?

 

在这里,我分享几个我亲身经历的小事,借此跟大家聊聊这个话题,大家也就当听听故事。行文不易,假如对大家有帮助、有共鸣的,欢迎 收藏/点赞/在看/分享。

 

一、情商

要听话,千万不要自大!

 

曾经因为自大,我给自己和团队挖了一个天坑!

 

记得就在毕业第二年的秋天,因为自己会写一些ui自动化的脚本,被划分到部门的自动化效能团队一起做一些测试工具。

 

在此之前,做过一些app的测试,觉得app的埋点测试,手工测试的话,耗费很多精力,但是因为埋点这块又一直出问题,就想做一个工具来“造福”业务测试的同事。

 

当时带我一起做这个项目的领导是刚入职的,对这块也不是很了解,也是硬着头皮跟我一起做这个工具了。

 

方案很快就定好了,采用app抓包的形式,将埋点数据进行拦截,转发埋点数据到测试平台,测试平台做埋点规则校验,再把结果报告展示到测试平台web页面上。

 

当时抓包工具是用anyproxy做二次开发,我在项目中主要负责前端采集埋点数据并转发http请求。后端是我的领导开发。

 

一开始,领导就嘱咐我说,前端的工具,做成命令行就行,越简单越好,做成可配置、可移植的,以后有可能的话,做成平台化的工具。

 

我当时真的很自大,真的要膨胀到爆炸了。没有明白设计为先的原则,也懒得去体会领导的用意,就自己开发自己的。

 

我心里只考虑到,团队的测试同学多是外包同学,给他们用命令行,多难用!考虑到易用性,当然做一个客户端界面(pyqt5),点点点就更方便啦!

 

我几乎通宵做了两个晚上,有一天代码提交出了问题,又修改到了后半夜,那时候真的是感觉很“充实”,做出来成果之后,还发朋友圈自嗨!

 

结果,到演示的时候,可谓瞬间爆炸啊……

 

因为客户端做的太臃肿了,中间出了不少交互的bug,简单的功能被我做得那么复杂,而且距离交付的时间也越来越近,领导瞬间都气炸了,会上直接就发飙了。

 

会后,我又得按领导的要求把功能砍到最精简的样子,当时感觉既挫败又委屈。

 

后来,工具还是交付并且推广了,但由于安装运行环境很麻烦,很多同事都不爱用,非但不能帮助业务测试的同学,还给他们造成麻烦,最后工具就没有推广起来

 

真的后悔自己因为自大,浪费了自己和大家那么多时间。

 

 

 

二、沟通

能群聊就不要单聊,能文字就不要语音!

 

刚开始进入互联网公司不久,我就接手了一个特别乌龙的需求。

 

这个项目,从活动运营,到开发,到测试,都是刚入职不久的新人。

 

一开始这个只是运营领导一句话的需求,没有产品经理跟进,没有经过需求评审,单纯就是口头沟通,就搞起来了。

 

我当时还是很负责任的,找当事运营也确认了很多遍需求,但是完全都没有意识到这样的沟通很低效。

 

没有沟通群,全靠口口相传;需求改了很多遍,但是需求文档一直是两行字的需求,全靠猜。

 

最后我们终于品尝到了因为沟通问题滋生的恶果!

 

由于我对需求的理解存在偏差,我给开发提了一个错误的“bug”,这个“bug”改完之后,直接使功能的实现背道而驰!甚至影响到了用户流量!

 

在提这个bug之前,我也找运营同学确认过bug的有效性,当时明明都确认这个“bug”是有效的。

 

但是出现线上问题之后,我却成了众矢之的,运营同事当场就“不承认”这个bug是找她确认过的,大家都一致认为这个bug就是我自己给自己“加戏”!

 

我真的感觉跳到黄河都洗不清了,我甚至拿不出任何证据给自己洗白,比窦娥还冤!

 

测试背锅真的很正常,但是我却因为沟通问题,背了我不该背的锅!

 

从那时起,只要是未经过需求评审的一句话需求以及没有详细文字版prd的需求,我都不接;只要是需要我测试的需求,我都会主动拉群,有事都在群里沟通,不再单聊。

 

后来,再也没有出现过这类的问题。

 

 

 

三、责任心

责任心是测试工程师的底线!

 

我在找工作面试过程中,有一个问题被问到过很多次:“你印象最深刻的bug是哪一个?”

细细想来,我碰到过的bug,绝大部分都是显而易见的bug。

 

我还经常抱怨:“开发的代码怎么写得这么烂,连主功能都没走通!能写出这些bug,都不是技术问题了,真的就是态度问题!”。

 

但就是这么简单的bug,在我们的团队里,还是会时不时流露到线上!线上的问题,你能怪开发么?这就是测试工程师责任心的问题!

 

试想假如你负责的项目,线上出现这么“沙包”的主流程都过不了的问题,你再怎么辩解“测试环境中明明是好的啊”,都显得好苍白无力啊!最尴尬的是,线上出问题之后,你再在测试环境中尝试复现,竟然还稳定复现~

 

嗨!兄弟,这就是漏测!

 

相信开发兄弟的水平就是对自己作为测试工程师的责任心的侮辱!

 

自己写过测试用例,一定要经得起用例评审;自己写的测试用例,再怎么恶心都要一条一条执行完毕!不要拿环境问题和测试时间紧迫当自己漏测的借口!

 

你一年干得再出色,出现一两个线上bug之后,所有出彩的地方都会被掩盖,责任心就是测试工程师的底线!我们要时刻坚守住自己的底线。

 

四、流程控制

要敢于对不合理的流程说不!

 

以前手工测试app埋点时,有一个不合理的流程是:测试完埋点之后,还要手写一份测试报告,把抓包的数据填充到测试报告中,然后再写一份邮件,抄送给BI部门。

 

维护这个测试报告的成本十分高,起码占用了50%的测试时间,完了这个测试报告发给BI部门,但根本没人会看!

 

这个测试报告的作用,可能就仅仅是测试人员完成埋点测试的“打卡”操作,并不能给埋点质量的提升带来任何帮助!

 

我当时按这个流程测了2个版本之后,再也忍受不住这种恶心的流程。

 

 

我当即找到了BI的负责人,沟通取消这个流程,因为这个流程对于测试人员来说就是一种羁绊,我们只专注于写这个测试报告,却忽略了测试埋点的意义,总感觉时间不够用,但是埋点测试的质量又得不到提高。

 

后来,经过妥善沟通,我们取消了这个测试报告,我们终于可以不用再忍受这个恶心的流程!

 

从此,埋点的测试不再只是为了完成任务而完成任务,我们可以花费更多时间去验证埋点的数据格式和埋点策略,埋点测试的质量和效率得到很大的提升。

 

五、风险意识

问题越早发现,风险越小!发现bug,一定要提交bug单留存并追踪到底!

 

之前有一个项目需要和别的团队进行合作,我在测试环境中发现了一个非本版本功能改动的bug,当时凭借经验,以为是合作团队的改动引发的问题,并且当时我自己的测试需求还忙得不可开交,就当了回甩手掌柜,把问题丢给合作团队的测试同事去跟进了,然后我就不管了,也没有提bug单。

 

没想到那个测试同事当时休假了,事情一直得不到妥善解决。

 

凭借经验,我也仅仅以为是环境或者账号的问题,也并没有重视这个问题。

 

等这个同事回来的时候,时间已经接近发版了,这时才发现这个问题根本不是他们的问题,而是我们连接他们服务的时候,这个版本的传参有问题,但是由于我并不知晓这个改动。

 

我发现这个问题,一没告知我们的开发,二没提交bug单,除了我和合作部门的测试之外,其他人对这个bug都不知情......导致这个bug差点就流露到线上去。

 

现在想想都还后怕!

 

任何bug,不管多小,都要bug单留存,并且要追踪到底!

 

▼▼▼

 

分享的几个我测试生涯中的案例,也是想强调软实力(情商 + 沟通 + 责任心 + 流程控制 + 风险意识)的重要性,其实还有诸如管理能力、演说能力也都包含在软实力里面,具备这些软实力能让你在职场走得更远!

 

延伸阅读:写给工程师的十条精进原则

https://tech.meituan.com/2018/08/16/10-principles-for-engineers.html​

 


长按识别下方二维码关注公众号

关注我的微信公众号【测试开发Guide】,

 

回复「java」:即可获得java经典学习资料(我花200元买的),带你轻松入门java编程。

回复「python」:免费获取「python入门」高分好书,业余时间偷偷变牛逼。

回复「面试」:24个常见的测试面试题,你一定不想错过。