2012.4.13 微博热报:专职 QA 的必要性、团队规模

  • 侯伯薇

2012 年 4 月 12 日

话题:DevOps语言 & 开发架构文化 & 方法

@左耳朵耗子 在微博上提出一个问题和大家讨论:我们需要专职的 QA 吗?@sfumato 从 Instagram 被 Facebook 收购的事件中体会到一个道理:苦逼的团队做不出有爱的产品。进而提出关于团队规模的讨论。很多人在微博上参与到了这两场讨论之中,表达了各自不同的观点。

@左耳朵耗子问题来源于一篇文章:【我们需要专职的 QA 吗?】 这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴... http://t.cn/zOCEdW6

左耳朵耗子:真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事,自己的痛苦,你就不会有想要去改进的动机。没有痛苦,就不会真正地去思考,没有真正的思考,就没有真正的进步。—— 这句话同时适用 Dev 和 QA。

raptor_ca:开发人员需要接受测试方面的培训,Dev 需要有对最终质量负责的态度,而不是依赖于测试人员。如果专职的测试人员能够对团队和项目的质量提高有促进作用,那么他的存在也是有价值的,测试也是一个 skill。做了这么久的开发,正在看一本测试的书,感触是开发人员都应该具有测试的基本知识。

-tonghe-:基本赞同!作者并非否定测试,只是强调“Dev 要懂测试,QA 要懂开发”、“让 Dev 理解 QA,让 QA 理解 Dev”。有关“吃自己的狗食”,我还没想到外包企业会怎么操作这个。有关“线上测试”,包括用户体验,我认为需要专职角色。

老赵:感觉在基础问题上还是没有达成共识啊,比如这句话“如果一个人懂开发,为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?”,对方没说 QA 是二等公民吧?还有文章一开始写的:“我想说明一下我观点里的这个“专职 QA”是怎么定义的。1...。2、这些 QA 对于软件开发技术并不熟悉,甚至不懂。”,其实这也不是对方的定义啊。所以双方看似观点不同,但其实有相当部分是一致的……

小知不了了:虽说屁股决定脑袋,做开发的普遍看不起做测试的,所以才会有诸如此类的论调。从管理的角度看,第一把测试的工作剥离出来可以有效的降低人力成本,第二可以根据测试的结果评估开发团队的工作质量,免得一头独大不好管理。需不需要是老板说了算的。

frank_lipei:觉得不在于职位,而在于 QA 的自身能力、工作内容、专业偏重。分工是提升效率和专业深度的必然,但 QA 是处于结合部的角色,也需要去掌握 DEV 和 PD 的某些技能来帮助更好的进行质量保证。

程序员邹欣:大家由于经历和看问题的角度不同, 对 QA/Test 也有不同的理解, 或者误解。 我觉得 test 的角色还是挺重要的。 这里讲了一些常见的对 test 的误解: http://t.cn/SAT46G 很有意义的讨论, 我从楼主博客的评论中也学到了不少, 道理应该是越辩越明白。大牛人, 人品好, 什么流程和分工都能和平演变成最合适的形式, 把事情做好。同时说, 我们没有什么流程分工啊... 技术弱, 人品差, 则拘泥计较于各种形式, 分工, 矛盾, kpi. 不欢而散。 普通人的团队, 则在不断摸索学习中, 我属于这一类, 目前感觉还是要依靠各个给力 pm/dev/test 的合作才能成事。

乔梁 QL:可能有些公司主要考虑直接成本(因为直接成本最易衡量)。毕竟,在国内普遍来说,开发人员的成本要比测试人员高(不排除个别现象)。外包测试是一个非常典型的例子。

木子海波:从行业来看,传统软件行业,是必须的,不管是通用的桌面应用,还是一些行业软件;互联应用中,前端是需要的,客户端软件是需要的。在互联网 / 游戏后台服务,是可以不需要的,性能测试可以 QA 来做,也可以 RD 来做。所以,要不要 QA 不是绝对的,而是根据项目特点来决定的。

李一 LeeAce:我也一直认为,在软件开发的领域只有一个角色——程序员。什么 Q 啦 solution manager 啦,都是虚幻的。一方面,一个不测试自己代码的程序员、一个不懂得自己开发的代码的作用的程序员,不是好程序员;另一方面,剥夺了程序员的 Q 与 SM 自主权的组织,其实也是畸形的组织。

Wang_Hong_:需不需要专职的 QA, 这和产品对质量的要求,团队成员的能力范围,用户类型等相关,也是职责划分的问题。在这个案例中,从按时有效发布有质量的产品的角度出发,可以改进的点,1)RD 和 QA 共同研究需求,讨论设计要点和测试要点 2)共同讨论产品的可测性,创建自动化测试程序 3)QA 及时反馈产品的关键指标。

@sfumato微博上提到:Instagram 总共就 13 名员工,公司卖了 10 亿。。大家一点要相信一个道理:苦逼的团队做不出有爱的产品。。。@tinyfool 告诉我他没有成功管过超过 10 人的团队,那些整天想管大团队,想当管理层,想出规章制度,条条框框让底下人 FOLLOW 显示成就感的人,就只能做毫无亮点难于使用的东西。

西卡 _TUP:严重同意,创造力和想象力 & 才华不是苦逼出来的。

@左耳朵耗子: 非常赞同。这也是我的观点,有两种团队是没有创造力的,一种是人数众多的大团队,一种是流程厚重的团队。

ApeHills 许晋豪:光内容审查员就不止 10 人了,不过这个可以外包。 @tinyfool 带 10 个人做产品,那些想管大团队的带 1000 号人做审核,这样比较合适。

w1e3:重要是主导的人是怎么样的,与团队苦逼不苦逼关系不大。话说起来,当年苹果可真是一个苦逼的团队。

薄暮之光 Victor:轻公司的典范,有多大自由就会产生多大奇迹。

张晓磊 LanceZhang:坚决不带超过 15 人的团队,7 个靠谱的绝对强过 20 个不靠谱的 //@蛙蛙王子: 还是看人靠不靠谱,一个团队天天迟到,上班玩游戏,看网页,啥文档也不写,部门之间没有接口人,现网数据随便改,东西从来不测试,没有任何制度和流程,忙的忙死,闲的闲死,估计也成不了事。

@蛙蛙王子: 对,人其实就活个环境,好多事不是靠口号,制度,法律来促成的,环境好,气氛好,激情就上来了,事就成了,但人首先要自律才行,走毫无制度和流程的极端肯定不行,制度也是大家觉得好才拥护的,觉得不好可以反映,这是员工的。

叶开源:商业模式不同。参考 37signals。小而美是工程师文化的硕果。

推荐理由:瑞友科技 IT 应用研究院副院长。爱技术,爱生活。 关注应用平台研发,移动互联,领域驱动设计,动态语言,iOS... 喜欢的一句话:自反而缩,虽万千人,吾往矣。

DevOps语言 & 开发架构文化 & 方法