关于QA角色

楚门的世界

前两天,有个同事离职了,照常发了离职邮件。虽然不认识,但他邮件里描述的离职原因,却让我印象深刻。

大意是说,有天在下班的公交车上,突然想到自己的高考志愿是随意填的,专业是调剂的,工作是随大流找的,所以希望在60岁前,能找到一个领域或一个事物,是自己感兴趣的,那就不算是个失败者。
于是辞职。
邮件最后以《楚门的世界》经典独白「早安午安晚安」结尾,看完这封邮件,我感触颇深。

是啊,我也一样,大学、专业、工作都不是因为喜欢才选的,也没有什么感兴趣的事情,一切按部就班,只是为了谋生。就像一个自己人生的旁观者,和楚门一样,被无形禁锢着。

做QA的这几年

大学、专业已经是过去式,无法改变。而工作,我的确开始迷惑了。

做QA三年,这个职业,一开始,虽然并不是因为喜欢或者感兴趣才做,但对于它在客观意义上的存在价值,还是认同的。我认同是需要这么一些人,专门利用测试方法论或工具,去「维护」软件质量。

后来,我逐渐发现,开发和测试是分不开的,不会开发的QA,在很多细节上插不上话,很难从代码角度给出建议,有时候还要向开发请教怎么测试,处境尴尬。所以,只通过纸上谈兵的方法论,和现学现卖的自动化测试工具来干活,已经不够看了。

而且近几年,开发人员对测试的关注也在不断提升,通过一些敏捷实践,比如TDD,或者一些代码检测工具,很多问题在早期就被识别和修复,纯粹的测试已经很难发现问题,不得不说,这是行业的进步。
自动化测试也逐渐为开发人员所重视,对比QA,他们可以更快的搭建自动化框架,写出更简练、稳定性更好的自动化测试代码。

至此,QA的处境就就更尴尬了。

QA的行业现状

既然无法在测试阶段发现问题,自动化测试也没开发做得好,为了证明自身存在的价值,只能不断扩大影响范围,所以才会有「测试左移」、「测试右移」这种概念和方法论出现,让测试去搞需求、去写代码、去做数据分析,总之,什么都可以干。

这就是现在测试行业/QA角色的现状,通过拜读前公司大佬熊节的 一篇文章 ,里面关于软件开发实际上就是个建模过程的描述,我深以为然,而下面的描述更让我深思:

编程的目标是建立与需求描述的模型一致的代码模型,所以写一堆代码不管对错丢给别人去测试这种行为,是编程的工作没有做完。
这就是现实。
人肉回归测试员的存在,仅仅是因为有很多程序员没有做好自己的本职工作,在人力资源便宜的时代,硬拉人来擦屁股,这是一种逆时代潮流的职业。
时代潮流的方向,一定是人力资源越来越贵,一定是自动化程度越来越高,所以人肉回归测试员的命运一定是被淘汰。

虽然说的是「人肉回归测试员」,但我觉得,整个测试行业都是这样。
测试本就是编程工作的一部分,是程序员的活,但很多公司为了赶进度,导致程序员只能赶工把代码写完,没时间搞测试,本末倒置。

说白了,测试这个职业的出现,只是因为国内的软件行业,并没有重视测试在编程过程中的重要性而导致的,而现在,随着行业的进步,测试已经被逐渐重视起来了。

所以我看到,很多项目已经不需要专职的QA了,而是直接由开发来做测试,其实这才是正确的做法,可能也是未来的行业方向,但这样一来,QA们该何去何从呢?

寻求答案

为了找到这个问题的答案,我参考了很多大佬的文章,比如:

但还是没有解答我的困惑,这些文章依然在讲方法论、布道,并没有直面测试行业本身,还是在说测试要左移、右移,要去分析需求,要写代码,要从全程把控质量。。。
并给出了测试人员的职业方向,也是我曾以为的职业方向:

下一步?

没有答案,下一步该怎么办呢?

现在来看,QA角色的存在价值我已经不认同了,我现在认同的是熊节大佬在 另一篇文章 中讲到的:

要写出好软件,很简单,你的人得编程,得会编程,得知道怎么写好代码。

想让不会编程的人把软件做出来,想让不知道怎么写好代码的人把软件做好,这个梦,我们这个行业已经做了三十年了。

软件质量要好,bug要少,很简单,两个词:测试驱动开发,持续集成。

核心就是一件事:写代码的人,要把代码写好,写高质量的、有单元测试覆盖的代码。 除此之外,一切想让不知道怎么写好代码的人把软件做好的梦想,都只是梦想。

总结:要做好软件质量,只能让写代码的人把代码写好。
而我,不是那个写代码的人,也不知道怎么把代码写好,又是以什么立场去保证软件质量呢?
这显然是不合理的。

所以,为了自己的饭碗,QA们得先开始写代码,做好测试自动化,然后学习怎么写好测试代码,脚踏实地的从「人肉回归测试员」过渡成「测试开发」。如果以后,已经不需要专职的测试来保证质量,那么想继续待在这个行业,除了转角色,没有别的办法,毕竟技术岗位,talk is cheap.