10.读google测试之道有感

（一）读google测试之道有感。

 

 

 

1、这样的测试改革必须是整个公司的统一一致的行为，需各个部门的全力配合经过相当一段时间的沉淀才能完成。要看公司的企业文化。

 

2、手动测试的人员将体验测试化，体验测试是只能在人的参与下完成。这部分TE会减少，但不会消失。

 

3、增加SET的职位只是辅助了SWE的单元测试，但是符合SWE条件的人不好找，即使找到了，待遇要大于等于SWE，测试部门中凭空增加了一个高成本的职位，老板能接受？

 

4、TE的角色负责，用户体验测试、自动化脚本测试。但是在敏捷的快速迭代下，需求不断改进的情况下，自动化测试是否适合，能不能持续下去？维护成本呢？

 

5、这种测试方式的改革，是否能真正的提高效率？还是只有在google那样的企业背景同企业文化下才有可行性。

 

6、测试不等于质量。

 

7、另外，这本书一直在提First Class Citizen，令我想起James在其演讲中问的一个问题：“在座的，有人的工资比开发高的不？一样的？低30%？”结果只有少数人说是差不多，大部分人都是低30%。
一个工种是不是First Class Citizen除了在工资上可以看得出来，在平时讨论时也可以看得出来。在我这个行业，讨论技术细节和如何实施，那一定是跟测试无关的，且很多人不屑于跟测试讨论。为啥呢，问code不懂code，问需求又不如需求人员。
为了让测试的人能够只能批判开发写的代码和需求的问题，Patrick在招聘人的时候，要求一定要懂代码，懂需求而不是随便会按电脑就算是会测试了。WTF，这个世界估计就google能干这种事情了。
看看测试的现状，有多少公司不是因为开发工资比较高，怕他们浪费时间在测试上而请测试工程师的？连Joel on Software的作者在n年前的文章(http://www.joelonsoftware.com/articles/fog0000000067.html，参见最后一条。文章虽是十几年前写的，但是现状区别不大，测试的工资是高了点，但还是比开发低不少。)都说了，这可是便宜一堆钱的选择啊！也难怪现在越来越多的测试被外包给印度人。唉。

还有，在国内的现状，开发人员的自己的开发工作已经被逼到了极限，自己的开发任务都被老板逼的要上吊了，还有时间给你做单元测试？更别提其他的集成、系统测试了。他本身就极其排斥这项工作。

 

8、谁都知道做单元测试在一个软件的生命周期中的重要性，但是为什么大多数公司选择不做？

核心就是成本问题：

1）留给开发人员的时间本来不多，加班加点的干还干不完，怎么能有时间去写Unit test，如公司硬性规定一定要写，那也是糊弄。

2）即使是开发时间允许，写单元测试一定会使开发周期延长，至少公司老板是这样认为的。这样的成本boss能不考虑节省吗？

3）SET同TE这两个工种要求太高，一般没有好的公司待遇和企业文化、工作氛围，这样的人找来后也是会选择离开，因为这样的人根本不用担心找不到工作。

 

9、EP 是 Engineering Productivity 的缩写，工程生产力的意思，这个团队，就是给整个大技术团队，甚至整个公司提高工作效率的。通俗直白的说，就是一个工具团队。因为工欲善其事、必先利其器，不要小看工具团队，某些程度上来讲，一个产品随着市场的变化可能很快凋亡，而一个好的工程工具，生命力要强得多，比如，开发语言其实就是最基本的工程工具了。那么，对一个公司，或者说交付团队来讲，怎么衡量工程生产力的高低呢？这个衡量方式其实就决定了「EP团队」的工作方向。我们自己定义的工程生产力从低到高的定义是这样的：1）质量，这是最基础的指标，什么都不行，也要保证质量过关，否则一个产品连生存的可能都没有。2）同等质量水平下，追求速度。质量过关了，就要看迭代速度了，你比竞争对手快，你就能活下来。3）同等质量和速度下，工程师的幸福感。如果质量也过关了，速度也快，但是大家过得很苦，天天加班，重复劳动，看不到未来，这也不行。幸福是什么？对我们来说，就是不被反复的简单问题所困扰，该自动的都自动，自动不是说一定快，但是一定省心，这里的幸福就是省心，有精力去关注更多的有意义的事情，而不是每天处理简单重复的问题。4）同等质量和速度，也有幸福感，再看成长。工程师们有没有感受到成长？不断的解决问题或开发产品，感受到的是重复劳动还是成长？其实前三点都做到了，第四点一定是有的。

 

10、自动化测试是怎么配合现在的软件快速迭代敏捷开发的？自动化的内容是什么？

 

11、google转岗机制不错，可借鉴。

 

 

google的产品质量管理有其前瞻性，国内已经知道的好像豌豆实验室的模式就是套用的google的模式。

但是，要达到谷歌的效果还是有难度的，甚至不太现实。但是我们可以部分吸收。

总结了一些读书笔记：

1、这样的测试改革必须是整个公司的统一一致的行为，需各个部门的全力配合经过相当一段时间的沉淀才能完成。要看公司的企业文化。

2、手动测试的人员将体验测试化，体验测试是只能在人的参与下完成。这部分TE会减少，但不会消失。

3、增加SET的职位只是辅助了SWE的单元测试，但是符合SWE条件的人不好找，即使找到了，待遇要大于等于SWE，测试部门中凭空增加了一个高成本的职位，老板能接受？

4、TE的角色负责，用户体验测试、自动化脚本测试。但是在敏捷的快速迭代下，需求不断改进的情况下，自动化测试是否适合，能不能持续下去？维护成本呢？

5、这种测试方式的改革，是否能真正的提高效率？还是只有在google那样的企业背景同企业文化下才有可行性。

6、测试不等于质量。

7、谁都知道做单元测试在一个软件的生命周期中的重要性，但是为什么大多数公司选择不做？

核心就是成本问题：

1）留给开发人员的时间本来不多，加班加点的干还干不完，怎么能有时间去写Unit test，如公司硬性规定一定要写，那也是糊弄。

2）即使是开发时间允许，写单元测试一定会使开发周期延长，至少公司老板是这样认为的。这样的成本boss能不考虑节省吗？

3）SET同TE这两个工种要求太高，一般没有好的公司待遇和企业文化、工作氛围，这样的人找来后也是会选择离开，因为这样的人根本不用担心找不到工作。

8、自动化测试是怎么配合现在的软件快速迭代敏捷开发的？自动化的内容是什么？

9、google转岗机制不错，可借鉴。

10、测试即开发，开发即测试。

11、吃自己的狗食。

12、预测不久的将来，测试群体的待遇会大于等于开发群体。

13、我们做不到google的整体完成的山寨，但是我们可以做google的旗舰版、国内版、就是精简版也不错啊。

14、不过现在搞探索性测试的热度大量回升，一些公司也逐渐把探索性逐渐作为体验测试的主要部分，google的投入大于20%。