BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 侯伯薇 关注 0 他的粉丝 发布于 2012年4月13日. 估计阅读时间: 8 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

@左耳朵耗子 在微博上提出一个问题和大家讨论:我们需要专职的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。小而美是工程师文化的硕果。

关于QA的必要性以及团队的规模,你的意见如何?欢迎加入讨论。

推荐微博@池建强

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


欢迎读者关注@InfoQ官方微博,推荐热门话题,可私信@InfoQ,同时请您说明推荐理由。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT