【杂谈】做一个不被开发鄙视的测试工程师

忙忙碌碌,不知不觉在新公司已经3个月了。尤其是最近一段时间,异常的忙,但是我仍然会抽出一定量的时间来做些开发。
以后成熟的话,打算输出一个手把手开发的系列,分享给更多的测试童鞋。

前几天跟群里一位小伙伴聊天,听到了一个关键词。相信这也是很多测试童鞋都有过的体会,感觉测试容易被开发鄙视,得不到尊重。

既然今天也没什么技术向的内容分享,那就随便聊聊吧,以一个入行3年多的测试小兵的角度,谈谈我的感受。

一、听听测试跟开发都吐槽对方什么?

1.来自开发的问候

由于忙于各种业务,所以认识了很多的开发童鞋。接触的多了,大家话题也就聊开了。因为他们也会跟不同的测试人员合作,所以我
偶尔就能听到开发对测试的一些吐槽。

“那XX,稍微有点不对,直接反手就是一个bug单,问都不问”;
“你这算啥,你没看那XXX,说问题就一张截图,无语”;
“哎,现在测试都不看数据库的么?前端的锅bug提给我干嘛?”... ...

不知道大家是否也曾经听到过类似的吐槽,我觉得场景很真实,我相信一定有测试人员是这样做的。别问,问就是我也曾...
【杂谈】做一个不被开发鄙视的测试工程师

其实对于上述的测试童鞋的表现,我觉得通常是2种情况:

  • 不知道怎么去定位bug,点出问题后只能全抛给开发自己去排查
  • 知道怎么定位,但是没有去进一步定位(太忙 或者 懒得动)

2.来自测试的问候

就是最近,我们组里新来了一位测试童鞋。虽然人家是新来的,但是履历还是非常棒的,在阿里、华为都待过。
然后晚会的时候就听到新童鞋吐槽楼上的xx开发,几个小功能居然能有十几个bug。
bug多就算了,最可气的是,被发现了bug还不承认,一会自己偷偷改了,再跟你说这功能没问题...
不知道你有没有遇到过这样的开发人员呢?

对于这位开发的表现,我觉得可能是这样的:

  • 专业能力差,bug多
  • 专业能力还行,不认真,没自测,没责任心
  • 人品不行,这个人做任何工作都可能会引起身边合作的人反感。
    【杂谈】做一个不被开发鄙视的测试工程师

二、我和开发的“恩怨情仇”

其实大家在日常工作中讲得就是一个“合作”,但是对于测试这份工作,你进行的顺利与否还是挺"看脸"的。

如果你测试的业务,对于的开发是一个自我要求高,技术能力很强的大佬,那么基本上你的case会跑的很顺利,有问题也很少。
反之,开发能力差还蜜汁自信,你就会很心累,各种测不通。

我的记忆里,我接触的到开发童鞋总体都还不错,起码沟通起来没有不愉快过。所以,通常来说,我跟这些开发相处的都不错,
自然就没有“无间道”了。

但是对于上面提到的那种“毒瘤”,自然也不能惯着。如果对方不自测,那我会去了解下为什么不自测。如果真的是因为太忙,那我觉得
也是可以给与一定的理解。
如果就是那种不自测,拿测试当“保姆”的,对不起,冒烟测试3次不过,打回不测了。把涉及到此需求的各方人员
都拉在群里,说明原因,开发自测后直接上线。

其实上面说的情况自然是我最不想看到的,但是这是因为对方实在可气,导致你的工作不能顺利进行,但是我相信大多数的开发童鞋还是很有
责任心的,大家都是一个诉求,功能没问题,如期上线。

三、我在工作中是怎么做的?

首先,我觉得测试的工作形式绝对不是一成不变的,还是要以适应当下的形式才行。

比如说我上个东家,虽说是个三线互联网公司,但是也是港股上市,业务稳定,大几千人。这样的公司通常很多流程已经比较规范了,比如从需求的
提出,到最终的上线,可以较好的按照比较标准的流程走下来,具体流程大家都知道,就不赘述了。

那现在的情况就不一样了,我现在的是创业型公司,处于C轮。需求多、测试人力不够(一直在招,合适的难找)、流程不规范,这些缺点都有。这时候
还用之前的那套显然啥都做不了了。

就拿最近负责的业务来说说,我在测试工作中通常会去做什么?

1. 需求急,短时间上线——关键词【沟通】

其实这种情况,在稳定和创业型公司都会遇到,只不过后者这种情况更多见。这时候,熟悉需求肯定还是首要的。不管你有没有直接参与需求的评审,都要
找涉及需求的直接人员进行有效沟通,注意是有效沟通。

找到需求的推进人,确定上线周期,提测时间,好规划测试时间,以及对于需求的一个测试重点分布。另外,还要把发现的一些风险点或者测试覆盖不到的地方
及时的抛出来,群策群力一起想办法。千万不要有阻塞点卡着 你不说出来,这样的话万一导致延期的话,锅可就是你的了。

2. 需求描述简单,不仔细——关键词【梳理】

这情况也是伴随着上述的情况而生,因为这种需求下很难有完整的需求文档描述以及原型图等等, 那么这个时候开发在设计的时候也可能考虑不全。那么,既然我
又不能直接撂挑子不管不顾,那我也只能尽我自己一份力,去帮着查漏补缺。

比如,最近的需求测试当中,我就要测试一个job接口,这个接口用来按照策略生成任务的,数据很重要,自然这个部分就是测试的一大核心重点。

重点需求重点对待,不仅要看功能页面上的展示,还要去查询各种表,去确定数据的准确性。
这个需求因为测试数据不好准备,在前期与开发沟通的时候,了解了涉及到的各种表之间的关系,自己去写sql造测试数据。

在验证结果的时候,我还会去查日志,一些关键点没有日志的话 提醒开发童鞋补上,方便验证。然后在一次次的测试中,再次梳理接口的处理逻辑。
看似正确的处理逻辑,当设计了足够多的场景数据去测试的时候,果然,发现了2除逻辑上的疏忽。

开发童鞋连赞发现的好,立马找来产品确认下是否需要补齐这个逻辑。

另外,在我查询各种表的时候,开发童鞋还反问我:“你还查库呢?我看很多测试都不查数据库的,挺好的”

3. 发现问题,如何更好的提bug——关键词【谨慎】

提bug,那肯定是我们工作中的一大重点内容了。发现问题,我觉得可以不用立即去提bug单,首先我会在我的case脑图后加标记,出现的什么问题。
然后再结合我的时间安排,觉得定位bug的深度。 最最最不济,你也要确定这问题是能复现出来的。

其实定位bug还是常用的那些方式,看请求,确认参数返回,查数据,看日志,依次来大概确定下是谁的问题,这时候你再提单会好一些。
当然了,肯定有一些我不能确定的问题,那么我可能会提给这个功能的最直接的那个人。

此外!!!还要多加一句:“这个问题可能不是你导致的,如果你发现不是你的问题,你直接将bug流转给对应的人就好”。

对应没时间写测试用例,这个事情也很经常了。我觉得这种需求下,在你熟悉大概情况后,可以边测边写,再不济的话,测试过的点和考虑到的场景务必要记录,
还有重要的沟通内容,截图等等,这是你工作细节的证明,也是你日后甩锅的证据。

4. 无意之中,“秀”一下你的代码

其实很多开发会鄙视测试的最直接的因素,就是测试不写代码。 我在上一家测试一个专项的时候,跟组里的高T开发合作过,结项的时候,他表示觉得我
是一个不错的测试,他觉得不会写代码的测试不能算做一个合格的测试。

其实这位大佬的言论在我看来还是有些偏激的,但是这确实就是代表了一部分开发的想法。

就包括我现在,在开发debug的空闲期,我也会打开我的编辑器去继续写一些有用的代码,有些开发看到后,会好奇的问:你在写什么代码呀?这个时候你就可以
扯一波了,千万不是吹嘘自己,表示你用代码在做一些有利于提效等等的事情,尽管你的开发水平不高,但是开发人员这时候还是会对你刮目相看,给你打上一个会
写代码的标签。

但是,我们别忘了,测试学习写代码,最终目的就是要去提效,提高工作效率,做一些对大家有意义的事情,让代码发挥出价值。千万不要本末倒置,为了写而写。

四、小结

思路比较杂乱,想到哪说到哪,最后点一下主题,如何不被开发鄙视。

首先,我觉得测试童鞋绝对不要妄自菲薄,其实你可以这样想一下,多数的开发人员天天的工作内容也是业务的CRUD,跟你的业务测试不会高到哪里去,如果你换了份开发
的工作做,你熟练后同样可以达到他们水平。 工作没有贵贱之分,互联网行业从业人员这么多,那是不是所有人都要去做开发?

再者,你的工作内容并不局限你的发展,你代码该学学,熟练了,简单的算法也可以搞一搞。千万不要满足于现状,这一点是最重要的,就算你投身其他行业,亦是如此。

最后,在测试工作中,扮演好你这个角色,做一个有责任心、谨慎、对团队有帮助的人,试问,这样的一个人,谁会看不起你?

以上都是我的个人愚见,欢迎大家分享一下自己的工作状态内容。

发表评论

相关文章