10.读google测试之道有感

时间:2023-12-10 15:25:02
一)读google测试之道有感。
10.读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%。