软件开发中需要专职的 QA 吗?

发布于:2021-10-25 02:18:53

导读:相信很多软件开发企业都有专职 QA。然而,这些专职人员能否发挥其本身价值?我们是否需要专职的QA?针对这些问题,本文作者提出了他的看法。



这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。对于不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴;如果你会去认真地深入思考,我也会高兴;如果你反对,没关系,可以讨论。

在此之前,我想先说明一下我观点里的这个“专职QA”是怎么定义的:



在我正在展开说明之前,我想先引用两篇文章。一篇是《
On testers and testing》(
点击查看中文翻译)。本文的作者Sriram Krishnan是一名程序员,曾在Yahoo和微软工作过,开发过很多软件,写过
一本书,并曾接受过
纽约时报的采访。本文是他的一篇博客。他在文章中表达了以下这几个观点:

另一篇文章是邹欣的《
现代软件工程讲义9 测试 QA 的角色和分工》。这是一篇很不错的文章。他在文章里提到了分工的必要性,比如第三方的鉴定机构。并且也指出了分工的一些问题,比如
画地为牢的分工、无明确责任的分工等等。这些问题直接命中了分工的要害。我隐约觉得,我和邹欣的很多观点是相同的,我们在内容上是相同的,只是形式上还有分歧。另外,我的观点太鲜明了,从而容易引起极端的理解。

你看,我们都同意,
Dev要懂测试,QA要懂开发,只不过分工不同。既然你中有我,我中有你,那就不要分彼此了,一起携手开发测试吧。另外,我个人觉得不懂开发的测试人员不可能测试得好。



我再说说我最糟糕的QA经历吧。之前我在一家公司工作,这家公司的QA部门只做测试。他们的leader觉得所有的test design和test 的过程都不需要Dev参与,他们是独立于Dev之外的部门,他们几乎不关心Dev的设计和实现。他们只关心能跑通他们自己设计的测试用例。但是去执行测试用例的时候,又需要Dev的支持,尤其在环境设置、测试工具使用、确认是否是bug方面,全都在消耗着Dev的资源。最让我感到绝望的是:
他们对任何线上的问题不负责,反正出了问题由Dev加班搞定

我有一次私自review他们的测试用例的时候,发现很多的测试用例这样写到:“Expected Result:Make sure every thing is fine”。
什么叫“Every thing is fine”?!而在测试用例设计的时候,没有说明测试环境是什么,没有说明测试数据在哪里,测试用例、测试数据、测试配置都没有版本控制,还有很多测试用例设计得非常冗余(多个测试用例只测试了一个功能),不懂得分析Function Point就做测试设计。

另外,我不知道他们为什么那么热衷于设计一堆各式各样的负向测试用例,而有很多正向测试用例没有覆盖到。为什么呢,
因为他们不知道开发和设计的细节,所以没有办法设计出高效的测试用例,只能从需求和表面上做黑盒

在做性能测试的时候,需要Dev手把手的教怎么做性能测试,如何找到系统性能极限,如何测试系统的latency,如何观察系统的负载(CPU、内存、网络带宽、磁盘和网卡I/O、内存换页……),如何做Soak Test,如何观察各个线程的资源使用情况,如何通过配置网络交换机来模拟各种网络错误等等,等等。

测试做得也不认真,大量的False Alarm,都是环境问题。比如:安装新版本后没有*舴瘢挥惺褂眯碌呐渲梦募缗渲玫鹊龋鹊取

在项目快要上线前的一周,我又私自查看了一下他们的测试结果,我看到5天的Soak Test 的内存使用一直往上涨,很明显这是内存泄露。这个情况发生在2个月前,但是一直都没有报告,我只好和我的程序员每天都加班到凌晨,赶在上线前解决了这个问题。但是,
QA部门的同学们就像没发生什么事似的,依然正常上下班。哎……

为什么会这样?我觉得有这么几点原因(和邹欣的观点一样):



邹欣对于分工出现的问题给出了两点解决方法:

我无意在这里贬低QA的工作,我也无意因为这个事走向另一个极端。但是,我在现在公司的经历,还有很多新兴公司的做法,让我越来越觉得软件开发,真的不需要专职的QA,更不需要只写代码不懂做测试的专职的Dev。
观点如下:
1、开发人员做测试更有效


另外,我始终不明白,为什么不做开发的QA会比Dev在测试上更专业? 这一点都说不通啊。



想想下面的这些情况你是否似曾相识?

一方面,QA说Dev不懂测试;另一方面Dev又说QA不懂技术。而我们还要让他们隔离开来,没有沟通。
我们应该让Dev理解QA,也要让QA理解Dev,减少公说公有理,婆说婆有理的现象出现



真正优秀的开发团队都是要吃自己狗食的。
这句话的意思是:如果你不能切身体会到自己糟糕的开发成果带来的痛苦,就不会真正地去思考;没有真正的思考,就没有真正的进步。

在我现在的公司,程序员要干几乎所有的事:需求分析、设计、编码、集成、测试、部署、运维、OnCall。因为:






关于SDET(全称是Software Development Engineer on Test)。像微软、Google、Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少。那么像这样的懂开发的专职测试可以有吗?我的答案是可以有!但是,我在想,如果一个人懂开发,为什么只让其专职做测试呢?这样分工合理吗?把程序员分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?所以,SDET在实际的操作中,更多的还是对开发不熟的测试人员。如果你说Dev对测试不专业、不细心、不认真,那么我们同样也无法保证QA的专业、细心和认真。Dev遇到的的问题,QA可能也会遇到。而出了问题QA不会来加班解决,还是开发人员自己解决。所以,如果QA不用来解决问题,那么,QA怎么可能真正的细心和认真呢如果你说不要QA的话,Dev人手会不够。你这样想一下,如果把你团队中现有的QA全部变成Dev。然后,大家一起开发,一起测试,亲密无间,沟通方便,你会不会觉得这样会更有效?你有没有发现,在重大问题上,Dev可以帮上QA的忙,但是QA帮不上Dev的忙。第三方中立,你会说程序员总是测不好自己写的东西,因为有思维定式。没错,我同意。但是如果是Dev交叉测试呢?你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟,他们还不合格。没关系,只要吃自己的狗食,痛苦了,就会负责的。 磨刀不误砍柴功。如果你开发的东西自己在用,那么自己就是自己天然的QA;如果有别的团队也在用你开发的模块,那么,别的团队也就很自然地在帮你做测试了,而且是最真实的测试。你可能会说吃狗食就是个笑话,倘若换成我,项目做得不好,就离职走人,让后来者去吃我的狗食。这个的确是这样的,但是想一想,你为什么在一开始不提醒他?另外,如果你的团队在设计评审和代码评审里没有把好关,让某位程序员蒙混过关,那么这为程序员离职后带来的问题还是要由你的团队来解决。于是整个团队都在吃自己的狗食,这很公*。痛苦过一次,你的团队就不敢随意招人、不敢随意评审代码、不敢让某位员工只做一块东西了。而这最终还是没有逃脱吃狗食的范畴。 关于自动化测试。这是一个机械的重复劳动。我想让测试人员思考一下,你是否在做这样的事?如果你正在做这样的事,那么,你要思考一下你的价值了。但凡是重复性比较高的机械性劳动,总有一天要被机器所取代关于线上测试。我们都知道,无论自己内测的怎么样,到了用户那边,总是会有一些测试不到的东西。所以,有些公司可能会做用户验收测试(做产品的公司会叫Beta测试)。无论怎么样,你总是要上生产线做测试的。对于互联网企业来说,生产线上测试有的玩A/B 测试,有的玩部分用户测试。比如,新上线的功能只有10%的用户可以访问得到,这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。

相关推荐

最新更新

猜你喜欢