左耳朵耗子的文章《我们下需要专职的QA吗？》，还是引起了各种风波。 就我个人来讲，我非常赞同他的抱怨。注意是抱怨，并非是观点。就观点来讲，其实真的是婆说婆有理，公说公有理。就目前IT行业来讲，还真说不清楚。就他的抱怨来讲，就国内来讲。是的，的确 ，很多
公司
都存在他说的这样的情况。甚至更甚。我自己从一家小公司做起，自己深有体会。在这里，我可以很负责的说，如果之前的一家公司不是因为我的存在，那么左耳朵耗子几乎说的所有现象都会存在。
不过这里我要说一点的是，
测试
们，不要说别人看不起测试。我曾经在weibo上面就写到过，中国的测试之所以被别人看不起，根本就是因为测试自己在看不起自己。
由于文章太长，我就逐个进行评论自己的看法了。
我有一次私自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，只能从需求和表面上做黑盒。
Monkey：前半段，我不想评论什么。我只能说写这种test case的tester太过肤浅，用我话来讲，根本就还不如那些实习了一个月的tester。当然，在我以前公司也发生过这类情况。不过这类情况一般都是发生在第一次做测试的人的身上。至于左耳朵公司怎么会出现这样的人，我个人比较匪夷所思。关于后半段，其实作为一个测试，几个case测试一个point这个在现实生活中没有办法避免的。不知道开发和设计细节，我只能认为是一种沟通上面的不当，测试应当就在设计的时候参与到项目中，并且很是很好的去design case。就如左耳朵说的，并非只是单纯的看着文档，跑着黑盒。不过这里有一点我必须要说的是，测试真正需要的是一个有好的想法，好的设计case的思路，以及很好的用户体验的这样一个人。因为在我看来，黑盒和白盒只不过是方式不同，其主要还在于case本身。
1）
开发人员做测试
Monkey：关于这点，我作为一个测试，不可否认。是的，在很多场景或者很多需求上面开发人员做测试的确相比测试人员更加有效。国内的测试普遍代码基础较差，有很多几乎就没有代码基础。对于这样的局面，比如我们写某个api的功能测试，又或者写一个查看对象生命周期的测试，这类我敢打赌来讲，就一个项目的dev来讲肯定比该项目的QA写来的得心应手。
但是仅仅限于一些基本功能的保证。dev无法保证一个系统性的 全面测试，就如我上一段说了，我不care是dev或者QA去做测试，而是设计case这样一个人是不是真的想法全面，是不是真的设计的好，是否真的会从一个用户的角度去设计。左耳朵所说的，QA要懂代码，这点我不得不说，我很赞同。并非要让 QA去品尝自己做出来的产品失败 或者有bug是什么滋味。而是只有懂的了，才能够真正的从逻辑上面去分析测试路径，分析测试方向。这样才不会让别人感觉到只是片面的黑盒测试罢了。
我始终不明白，为什么不做开发的QA会比Dev在测试上更专业？ 这一点都说不通啊。
Monkey：就刚刚进入测试行业的人来讲，肯定会反驳。但是左耳朵说的也并不完全对，不会做开发的QA只不过不能成为优秀的QA，但是和做测试的Dev没有可比性其实。
2）减少沟通，扯皮，和推诿
Monkey：其实就这点，所有公司任何一个测试team和dev team都有出现左耳朵说的现象。怎么说呢，其实dev本身不是只为了coding，QA本身不是只为了测试求测试。如大家真心都是为了把产品做好，各种扯皮，抱怨都会减少。其实基本上来说，国内很多测试和dev的素质（不是说做人的素质）就职业的素养来讲还是不够高。这个是一方面，另外一方面来讲，好的流程一种好的沟通方式也可以大大减少左耳朵说的这类问题。原本我是想建议说可能以后可以有一种
职位
就是开发和测试并存的。但是后来想想，不对。我还是不赞同两者混淆起来做。两者除了思维相差太大之外 ，其花精力以及方向都是不一样的。不可能让同一个人或者同一个team去完成。
3）吃自己的狗食
Monkey：这点我无条件的完全同意，并且非常同意。
关于SDET。全称是Software Development Engineer on Test。像微软，Google， Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少，在Amazon是非常少的。那么像这样的懂开发的专职测试可以有吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样的程序员分工合理吗？把程序员分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET在实际的操作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。
Monkey：我以前认识MS里面的SDET。比例在微软里面还是蛮多的。我同意不懂开发的人成为不了真正意义上面优秀的测试。但是并非一定要让懂开发的测试去做开发。或者说两者兼做。
我不说什么开发是创造，测试是破坏这种理论大话了。我来说实际的，实际上面，测试是一种全面性的工作，虽然任何一个测试不可能让产品没有bug。但是也需要无限接近于这个目标。一个人的精力是有限的，我们需要测试是因为一个真正意义上面优秀的测试人员肯定比一个真正意义上面优秀的开发人员想的更多（并非更全）。
我一直认为测试的思维是第一 ，其余所有的只不过是测试实施的手段不同罢了。但是就测试而言，黑盒测试用例的设计，白盒测试框架的搭建，架构，api的封装。包括各种压力测试，回归测试，性能测试，用户体验测试，更甚的有单元测试，coverage测试等等。这一系列要在一个项目中做好并非是容易的事情。往往测试会用各种不同的 方法去达到一个目的，这个就如同测试会有N条测试用例去覆盖一个功能点一样。这个从 dev或者旁人的角度来看的确可能是一件荒唐的事情，但是测试往往是一种摸索，是一种创新，是一种比较的过程。这样在日积月累之后，case会被精简，方法会被改进 ，效率会被改进，bug也会相应的减少，上线之后的问题也会逐步减少。当然一个真正好的测试应该告诉dev，某些类应该怎么写，某些方法应该怎么写，某些逻辑应该怎么做保护。dev和QA相辅相成才能够各取所需，一起提高，不是么？
以上，所有的 观点都是建立在一个有真正测试sense的QA，一个真正知道要做什么的QA的基础上面。其实目前很多的局面的造成就是因为测试自己不知道要做什么，对于产品对于测试都没有激情所造成的。这类测试根本就不配 做测试。说实话，长此以往，第二个抱怨的，第三个抱怨的都会跳出来。到时候就如同狼来的故事一样，谁也不会相信测试。
在此，我向陈皓表示敬意。
Ye
