陈皓：我们需要专职的QA吗?(2)

　　我的观点

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

　　● 充分授权和信任(Empower team members)

　　● 各司其职，对项目共同负责(Establish clear accountability and shared responsibility)

　　我的观点是，理论上正确，操作上太虚了。这就像我们国家喊的“为人民服务”的口号一样，没有具体的方法，根本无法落实。

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

　　1) 开发人员做测试更有效

　　● 开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。

　　● 开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及Soak Test 等。

　　● 开发人员知道怎么测试是最有效的。开发人员知道所有的function point，知道fix一个bug后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。

　　很多开发人员只喜欢写代码，不喜欢做测试，或是他们说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。

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

　　2)减少沟通，扯皮，和推诿

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

　　● QA 做的测试计划，测试案例设计，测试结果，总是需要Dev来评审和检查。

　　● QA在做测试的过程中，总是需要Dev对其测试的环境，配置，过程做指导。

　　● QA总是会和Dev争吵某个问题是不是BUG，争吵要不要解决。

　　● 无论发现什么样的问题，总是Dev去解决，QA从不fix问题。

　　● 我们总是能听到，线上发生问题的时候，Dev的抱怨QA这样的问题居然没测出来，

　　● QA也总会抱怨Dev代码太差，一点也不懂测试，没怎么测就给hand over 给QA了。

　　● QA总是会push Dev，这个bug再不fix，你就影响我的进度了。

　　● 等等，等等。

　　如果没有QA，那么就没有这么多事了，DEV自己的干出来的问题，自己处理，没什么好扯皮的。

　　而一方面，QA说Dev不懂测试，另一方面Dev说QA不懂技术，而我们还要让他们隔离开来，各干各的，这一点都不利于把Dev和QA的代沟给填平了。要让Dev理解QA，让QA理解Dev，减少公说公有理，婆说婆有理的只站在自己立场上的沟通，只有一个方法，那就是让Dev来做测试，让QA来做开发。这样一样，大家都是程序员了。

　　3)吃自己的狗食

　　真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。

　　在我现在的公司，程序员要干几乎有的事，从需求分析，设计，编码，集成，测试，部署，运维，OnCall，从头到尾，因为：

　　● 只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。

　　● 只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……

　　● 只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。

　　所以，真正的工程师是能真正明白软件开发不单单只是coding，还更要明白整个软件工程。只明白或是只喜欢coding的，那只是码农，不能称之为工程师。

　　4)其它问题

　　● 关于SDET。全称是Software Development Engineer on Test。像微软，Google， Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少，在Amazon是非常少的。那么像这样的懂开发的专职测试可以有吗?我的答案是可以有!但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序员分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?所以，SDET在实际的操作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。

　　● 如果你说Dev对测试不专业，不细心，不认真，那么我们同样也无法保证QA的专业，细心和认真。在Dev上可能出现的问题，在QA也也会一样出现。而出了问题QA不会来加班解决，还是开发人员自己解决。所以，如果QA不用来解决问题，那么，QA怎么可能真正的细心和认真呢?

　　● 如果你说不要QA的话，Dev人手会不够。你这样想一下，如果把你团队中现有的QA全部变成Dev，然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效?你有没有发现，在重大问题上，Dev可以帮上QA的忙，但是QA帮不上Dev的忙。

　　● 第三方中立，你会说人总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是Dev交叉测试呢?你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。

　　● 磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。

　　● 你可能会说吃狗食就是个笑话，因为如果是我，我把干烂的事，就离职走人了，让别人去吃我的狗食。这个在现实中的确会发生，也是很现实的。但是想一想，你为什么在一开始让他把事干烂了?另外，如果你的团队在设计评审和代码评审里没有把好关，让某人把事给干烂了，那么这个人的离职带来的问题还是这个团队来扛，于是整个团队都在吃自己的狗食，挺公平的。痛苦过一次，你的团队下次怎么干了，就不敢乱招人了，就不敢随意评审代码了，就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。

原文转自：http://www.ltesting.net