我们需要专职的QA吗?

openkk 10年前
     这个文章必然是有争议的,我在我的    <a href="/misc/goto?guid=4958185560036269721" target="_blank">微博</a>上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴,如果你反对,没关系,可以讨论。    <p></p>    <p> 在此之前,我想说明一下我观点里的这个“专职 QA”是怎么定义的。</p>    <ol>     <li>其是很多公司成立的专门做测试的技术人员,仅测试不开发。</li>     <li>这些 QA 对于软件开发技术并不熟悉,甚至不懂。</li>    </ol>    <p> 我经历过一些公司都有专职的 QA 团队(专职的测试人员),自从上个公司我的开发团队在一个项目上被 QA 部门搞得一团糟,我越来越怀疑专职 QA 存在在意义。我的观点不一定对,但请让我鲜明地表达一下——我觉得是不需要全职的 QA 的,甚至不需要 QA 这一专职角色或部门,因为,不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得 Dev 应该应该是做测试最合适的人选,这必然是未来的趋势 (因为我已经看到了中国程序员的进步,相比起 10 年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。</p>    <p> 在我正在展开说明之前,我想引用两篇文章:</p>    <p> <strong>两篇文章</strong></p>    <p> 一篇是  “<a href="/misc/goto?guid=4958330048410010503" target="_blank">On testers and testing</a>”(<a href="/misc/goto?guid=4958336453001742703" target="_blank">中文翻译</a>),本文的作者 Sriram Krishnan 是一名程序员,曾在 Yahoo 和微软工作过,开发过很多软件,曾被纽约时报<a href="/misc/goto?guid=4958330045199715072" target="_blank">报道</a>,写过<a href="/misc/goto?guid=4958330046025349256" target="_blank">一本书</a>,本文是他的一篇博客。他在文章中表达了这几个观点——</p>    <blockquote>     <p>大多数的开发团队并不需要一个独立的测试角色。即使要有,那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的 非死book,还是 30 年前最初的 NT 团队,很多伟大的产品都是出自没有或很少测试人员的团队。</p>     <p>开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”,那你需要更好的程序员。</p>    </blockquote>    <p> 另一篇文章是邹欣的“<a href="/misc/goto?guid=4958336455281893858" target="_blank">现代软件工程讲义 9 测试 QA 的角色和分工</a>”,这是一篇很不错的文章。他在文章里提到了分工的必要性,比如第三方的鉴定机构,<strong>并且也指出了分工的一些问题,比如,画地为牢的分工,无明确责任的分工,等,这些问题直接命中了分工的要害</strong>。我隐约觉得,我和邹欣的很多观点是相同的,我们内容上是相同的,只是形式上还有分歧。另外,我的观点太鲜明了,从而容易导向极端的理解。</p>    <p> 你看,<strong>我们都同意,Dev 要懂测试,QA 要懂开发,只不过分工不同,既然你中有我,我中有你,那就不要分彼此了,一起携手开发测试吧</strong>。(另外,我个人觉得不懂开发的测试人员不可能测试得好)</p>    <p> <strong>我的故事</strong></p>    <p> 我再说说我最糟糕的 QA 经历吧,这个公司的 QA 部门只做测试,他们的 leader 觉得所有的 test design 和 test 的过程都不需要 Dev 参与,他们是独立于 Dev 之外的部门,他们几乎不关心 Dev 的设计和实现,他们只关心能跑通他们自己设计的 test case。但是去执行 Test Case 的时候,又需要 Dev 的支持,尤其在环境设置,测试工具使用,确认是否是 bug 方面,全都在消耗着 Dev 的资源,最扯的是,他们对任何线上的问题不负责,反正出了问题由 Dev 加班搞定。</p>    <p> 我有一次私自 review 他们的 test case 的时候,发现很多的 test case 这样写到 – “Expected Result:Make sure every thing is fine” ,WTF,什么叫“Every thing is fine”?!而在 test case design 的时候,没有说明 test environment/configuration 是什么?没有说明 test data 在哪里?Test Case、Test Data、Test Configuration 都没有版本控制,还有很多 Test Case 设计得非常冗余(多个 Test Case 只测试了一个功能),不懂得分析 Function Point 就做 Test Design。另外,我不知道他们为什么那么热衷于设计一堆各式各样的 Negative Test Case,而有很多 Positive 的 Test Case 没有覆盖到。为什么呢,因为他们不知道开发和设计的细节,所以没有办法设计出 Effective 的 Test Case,只能从需求和表面上做黑盒。</p>    <p> 在做性能测试的时候,需要 Dev 手把手的教怎么做性能测试,如何找到系统性能极限,如何测试系统的 latency,如何观察系统的负载(CPU,内存,网络带宽,磁盘和网卡I/O,内存换页……)如何做 Soak Test,如何观察各个线程的资源使用情况,如何通过配置网络交换机来模拟各种网络错误,等等,等等。</p>    <p> 测试做得也不认真,大量的 False Alarm,都是环境问题,比如:安装新版本后没有重启服务,没有使用新的配置文件,网络配置,等等,等等。</p>    <p> 在项目快要上线前的一周,我又私自查看了一下他们的 Test Result,我看到 5 天的 Soak Test 的内存使用一直往上涨,很明显的内存泄露,这个情况发生在 2 个月前,但是一直都没有报告,我只好和我的程序员每天都加班到凌晨,赶在上线前解决了这个问题。但是,QA 部门的同学们就像没发生什么事似的,依然正常上下班。哎……</p>    <p> 为什么会这样?我觉得有这么几点原因(和邹欣的观点一样)</p>    <ol>     <li>给了 QA 全部测试的权力,但是没有给相应的责任,</li>     <li>QA 没有体会过软件质量出问题后的痛苦(解决线上问题的压力),导致 QA 不会主动思考和改进。</li>     <li>QA 对 Dev 的开发过程和技术完全不了解,增加了很多 QA 和 Dev 的沟通。</li>     <li>QA 对软件项目的设计和实现要点不了解,导致了很多不有效的测试。</li>    </ol>    <p> <strong>注:我无意在这里贬低 QA 的能力工作。只是我看到了 QA 因为没有参与开发的一些现实问题。</strong></p>    <p> <strong>我的观点</strong></p>    <p> 邹欣对于分工出现的问题给出了两点解决方法:</p>    <blockquote>     <ul>      <li>充分授权和信任(Empower team members)</li>      <li>各司其职,对项目共同负责(Establish clear accountability and shared responsibility)</li>     </ul>    </blockquote>    <p> 我的观点是,<strong>理论上正确,操作上太虚了。这就像我们国家喊的“为人民服务”的口号一样,没有具体的方法,根本无法落实。</strong></p>    <p> 我无意在这里贬低 QA 的工作,我也无意因为这个事走向另一个极端。但是,我在现在公司的经历,还有很多新兴公司的做法,<strong>我越来越觉得软件开发,真的不需要专职的 QA,更不需要只写代码不懂做测试的专职的 Dev</strong>。观点如下:</p>    <p> <strong>1)</strong> <strong>开发人员做测试更有效</strong></p>    <ul>     <li>开发人员本来就要测试自己写的软件,如果开发人员不懂测试,或是对测试不专业,那么这就不是一个专业的开发人员。</li>     <li>开发人员了解整个软件的设计和开发过程,开发人员是最清楚应该怎么测试的,这包括单元测试,功能测试,性能测试,回归测试,以及 Soak Test 等。</li>     <li>开发人员知道怎么测试是最有效的。开发人员知道所有的 function point,知道 fix 一个 bug 后,哪些测试要做回归和验证,哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。</li>    </ul>    <p> 很多开发人员只喜欢写代码,不喜欢做测试,或是他们说,开发人员应该关注于开发,而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量,需要证明自己的开发成果的质量。<strong>开发人员如果都不知道怎么做测试,这个开发人员就是一个不合格的开发人员</strong>。</p>    <p> 另外,<strong>我始终不明白,为什么不做开发的 QA 会比 Dev 在测试上更专业? 这一点都说不通啊</strong>。</p>    <p> <strong>2)减少沟通,扯皮,和推诿</strong></p>    <p> 想想下面的这些情况你是否似曾相识?</p>    <ul>     <li>QA 做的测试计划,测试案例设计,测试结果,总是需要 Dev 来评审和检查。</li>     <li>QA 在做测试的过程中,总是需要 Dev 对其测试的环境,配置,过程做指导。</li>     <li>QA 总是会和 Dev 争吵某个问题是不是 BUG,争吵要不要解决。</li>     <li>无论发现什么样的问题,总是 Dev 去解决,QA 从不 fix 问题。</li>     <li>我们总是能听到,线上发生问题的时候,Dev 的抱怨 QA 这样的问题居然没测出来,</li>     <li>QA 也总会抱怨 Dev 代码太差,一点也不懂测试,没怎么测就给 hand over 给 QA 了。</li>     <li>QA 总是会 push Dev,这个 bug 再不 fix,你就影响我的进度了。</li>     <li>等等,等等。</li>    </ul>    <p> 如果没有 QA,那么就没有这么多事了,DEV 自己的干出来的问题,自己处理,没什么好扯皮的。</p>    <p> 而一方面,QA 说 Dev 不懂测试,另一方面 Dev 说 QA 不懂技术,而我们还要让他们隔离开来,各干各的,这一点都不利于把 Dev 和 QA 的代沟给填平了。<strong>要让 Dev 理解 QA,让 QA 理解 Dev,减少公说公有理,婆说婆有理的只站在自己立场上的沟通,只有一个方法,那就是让 Dev 来做测试,让 QA 来做开发</strong>。这样一样,大家都是程序员了。</p>    <p> <strong>3)吃自己的狗食</strong></p>    <p> 真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——<strong>如果你不能切身体会到自己干的烂事,自己的痛苦,你就不会有想要去改进的动机</strong>。<strong>没有痛苦,就不会真正地去思考,没有真正的思考,就没有真正的进步</strong>。</p>    <p> 在我现在的公司,程序员要干几乎有的事,从需求分析,设计,编码,集成,测试,部署,运维,OnCall,从头到尾,因为:</p>    <ul>     <li>只有了解了测试的难度,你才明白怎么写出可测试的软件,怎么去做测试的自动化和测试系统。</li>     <li>只有自己真正去运维自己的系统,你才知道怎么在程序里写日志,做监控,做统计……</li>     <li>只有自己去使用自己的系统,你才明白用户的反馈,用户的想法,和用户的需求。</li>    </ul>    <p> 所以,<strong>真正的工程师是能真正明白软件开发不单单只是 coding,还更要明白整个软件工程</strong>。只明白或是只喜欢 coding 的,那只是码农,不能称之为工程师。</p>    <p> <strong>4)其它问题</strong></p>    <ul>     <li><strong>关于 SDET</strong>。全称是 Software Development Engineer on Test。像微软,Google, Amazon 都有这样的职位。但我不知道这样的职位在微软和 Google 的比例是多少,在 Amazon 是非常少的。那么像这样的懂开发的专职测试可以有吗?我的答案是可以有!但是,我在想,<strong>如果一个人懂开发,为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?</strong>所以,SDET 在实际的操作中,更多的还是对开发不熟的测试人员。还是哪句话,不懂开发的人是做不好测试的。</li>    </ul>    <ul>     <li><strong>如果你说 Dev 对测试不专业,不细心,不认真</strong>,那么我们同样也无法保证 QA 的专业,细心和认真。在 Dev 上可能出现的问题,在 QA 也也会一样出现。而出了问题 QA 不会来加班解决,还是开发人员自己解决。所以,如果 QA 不用来解决问题,那么,QA 怎么可能真正的细心和认真呢?</li>    </ul>    <ul>     <li><strong>如果你说不要 QA 的话,Dev 人手会不够</strong>。你这样想一下,如果把你团队中现有的 QA 全部变成 Dev,然后,大家一起开发,一起测试,亲密无间,沟通方便,你会不会觉得这样会更有效?你有没有发现,在重大问题上,Dev 可以帮上 QA 的忙,但是 QA 帮不上 Dev 的忙。</li>    </ul>    <ul>     <li><strong>第三方中立,你会说人总是测不好自己写的东西,因为有思维定式</strong>。没错,我同意。但是如果是 Dev 交叉测试呢?你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟,他们还不合格。没关系,只要吃自己的狗食,痛苦了,就会负责的。</li>    </ul>    <ul>     <li><strong>磨刀不误砍柴功</strong>。如果你开发的东西自己在用,那么自己就是自己天然的 QA,如果有别的团队也在用你开发的模块,那么,别的团队也就很自然地在帮你做测试了,而且是最真实的测试。</li>    </ul>    <ul>     <li><strong>你可能会说吃狗食就是个笑话,因为如果是我,我把干烂的事,就离职走人了,让后来去吃我的狗食</strong>。这个的确是这样的,但是想一想,你为什么在一开始让他把事干烂了?另外,如果你的团队在设计评审和代码评审里没有把好关,让某人把事给干烂了,那么这个人的离职带来的问题还是这个团队来抗,于是整个团队都在吃自己的狗食,挺公平的。痛苦过一次,你的团队下次怎么干了,就不敢乱招人了,就不敢随意评审代码了,就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。</li>    </ul>    <ul>     <li><strong>关于自动化测试</strong>。所谓自动化的意思是,这是一个机械的重复劳动,我想让测试人员思考一下,你是否在干这样的事?如果你正在干这样的事,那么,你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动,总有一天都会被机器取代的。</li>    </ul>    <ul>     <li><strong>关于线上测试</strong>。我们都知道,无论自己内测的怎么样,到了用户那边,总是会有一些测试不到的东西。所以,有些公司会整出个 UAT,用户验收测试。做产品的公司会叫 Beta 测试。无论怎么样,你总是要上生产线做测试的。对于互联网企业来说,生产线上测试有的玩A/B测试,有的玩部分用户测试,比如,新上线的功能只有 10% 的用户可以访问得到,这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。</li>    </ul>    <p> 好吧,我暂时写这么多,我会视大家的讨论再补充我的观点的。</p>    <div id="come_from">     来自:     <a id="link_source2" href="/misc/goto?guid=4958336456078420426" target="_blank">coolshell.cn</a>    </div>