QA测试是否要看代码

以前有个RD同事问过我,为什么你做测试还要看代码,看代码干嘛!?

还有个RD在提测会议上当场说,QA不应该看代码,避免思维跟RD一样,那就测不出问题了(这个同学还是个准百度T7)……

必须得评价一下,对QA这样的认知应该是QA的职能存在一定误解。

假如需求在文档层面能描述清楚,功能实现的思路和细节在文档里写得明明白白,贴上关键代码及相关解释,当然可以省掉QA测试看代码的环节,只是RD习惯输出从简,或者并不了解QA的想法或工作方法。看代码的作用就是为了填补QA对细节实现上信息不对称的gap,有时这种gap会浪费QA长达几个小时的时间。举个例子:有些较为繁琐的嵌套判断逻辑,或者一些corner case,RD懒得在文档写得这么清楚,当QA测试到这里后看到程序表现在文档中没有说明,往往无法确认该现象是否符合预期,随之而来就是沟通的时间成本。

在实际测试中,真的经常碰到类似的情况,在测试过程中随着对功能理解的越发细致,会突然想到某个corner case,但是文档没有体现相关的处理逻辑,此时我一般会选择走读代码check是否有对应处理,找不到或者看不懂再问RD,这样对RD也会友好一些。

产品本身是由一个一个功能模块组成的,我们可以对产品的功能十分熟悉,在手上把玩自如,这是在黑盒层面上去理解一个产品,或许可以把玩出一些味道,明白产品为什么在功能和UI细节上如此这般设计、产品为什么能吸引用户留住用户、产品如何做选择来支撑它的发展壮大,又或者通过用户数据和指标的分析,找出用户增长点,这是pm的方式。

pm的方式对于技术人员是性不太通,产品的设计和产品的实现,总是会存在gap,这也就是为什么pm认为合理的需求有时候在技术实现上十分困难(技术也有技术债或历史包袱!)。要真真实实摸清产品,就不能只停留在宏观层面,得深入到技术层面。每一个功能模块,它在代码层面映射出来的是多个代码模块,不同的代码模块提供什么能力支撑,互相如何合作,甚至是产品技术选型的初衷和优劣势及其演进,这些都是理解产品生命周期的重要线索。同时在产品背后,支撑产品的一整套周边系统,要足够清晰,花的时间一点也少不得。

当然还是要补充一个观点,深入到代码,有时可以让我们掌握更多信息,但是有时又会让人陷入细节失去大局观,各有不同应用场景。

我觉得上面这个理由已经足够支撑QA去看代码了,如果是真的想好好融入到这个产品的建设中去添砖加瓦,而不是单纯的【我只是来打工】的心态。

最后,QA很多时候就是充当一个打破规律的人,拿着一些奇奇怪怪的case和问题去挑战RD的脾气🤣,有些代码实现本身就导致corner case无法修复,看代码来提前只细问题有没有可能被修复,可以大大降低RD心态爆炸的概率。或者自己就可以找到修复方案给RD提点意见,蹭蹭蹭在RD心中提高一下地位,还是不错的~

打赏
  • 版权声明: 本博客所有文章除特别声明外,著作权归作者所有。转载请注明出处!
  • Copyrights © 2017-2022 Zingphoy Han
  • 访问人数: | 浏览次数:

一块钱一个俯卧撑 O_O

微信