读书笔记：Google软件测试之道

平凡是一种态度，平庸是个人能力，平凡之人岂可平庸！（工作篇）

程序员的现状，以体力劳动者的身份参与软件生产活动。作为一软件工程师，或程序员，或码农，在工作n久后，多数会转岗。若坚持这个岗位，个人思考的路线包含三方面的提升：

• 技术维度：某方向技术深度提升、基于深度基础的技术广度认知

• 协同维度：周边岗位的部署与职责（如：集成、测试、资料、SE、其他开发）

• 组织维度：项目管理、技术管理、团队建设等

构建以技术为中心的个人信服力，以全面的视角、理解共赢的思维、协同运转的方式，影响甚至引导组织和周边的运转方式。达成稳定、完整、快速的产品发布，同时，技术能力、周边协同能力持续提升。

阅读《Google软件测试之道》正是基于此想法，学习并认知测试岗位。但这本书远远的超出了我的预期，它讲述了Google的测试定位、测试技术、测试思想、测试运营、测试组织等等，讲述的不仅仅是个岗位，是个测试系统案例。

收获1：岗位职责

之前，个人对于岗位的理解停留在招聘启事中，对应聘人员列出的各项岗位要求，而最终因为某些莫名其妙的原因被选中，干着和岗位要求不搭嘎的事情。在Google软件测试之道中，有“软件开发工程师SWE”、“软件测试开发工程师SET”、“测试工程师TE”

• SWE负责功能代码开发，但也需要编写测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试
• SET负责提供测试支持，其重心在可测试性和通用测试基础框架上，编写单元测试框架和自动化测试框架，关注质量提升和测试覆盖率的增加
• TE负责用户角度的测试，部分从事模拟用户的使用场景和自动化脚本或代码的编写上，是代表用户利益的产品专家

这里可以看到的是岗位职责明晰、角色关系明确，在实际工作中，因为岗位边界的原因，确实吃过不少苦头。一人身兼多职、职位变动是常有的事儿，梳理清楚每个点是个非常不错的方法，譬如：

1. 责任田主：负责某功能的规格解答、代码BUG处理、代码质量提升、新诉求分析
2. Story Owner：负责整体需求的分析与设计、分解任务、跟踪子任务的达成、负责整体交付
3. AR Owner：负责需求的实现设计与代码开发
4. MDE：跟踪部门技术动向、参加技术会议、提升团队技术能力、指导团队技术活动、帮助团队成员达成开发任务
5. ...

明确的岗位定义与职责、多岗位的配合方式，更有利于岗位的执行、岗位之间的交流、人岗匹配的技术能力的提升等。

收获2：基础设施

对于公开的模块，本人有个原则：要让他人使用某项技术，那这个技术必须唾手可得。

UT是个好东西，部门大力推崇，然而每次到C++ UT的时候，总会吃一鼻子灰。本为质量提升，但由于业务现有代码不具备可测试性，只落得个政治任务。《Google软件测试之道》此书中有很多理念与我之前的思考不谋而合，UT上便有一个点“SWE需要负责测试驱动设计、SET重心在可测试性并编写单元测试框架”，我认为这是代码可UT化的精髓，用我的语言来描述，要写UT，那必须：

1. 明确UT的作用与意义，梳理不同场景可UT的代码设计思路，写可UT的代码，测值得UT的函数
2. 存在项目组，提供基于产品的UT框架，并指导开发接入

盲目跟风而不考虑基础，不去经营基础设施，无论是对于个人还是对于团队，都有可能是画虎类犬的结果。

收获3：开发测试

在我们的组织中，有开发人员和测试人员之分，组织形态的划分使大家很容易误解，测试的事情应由测试管、开发的事情应由开发管，测试就应该点点点，开发就应该写写写，开发与测试形似交付与签收的关系。即使在全功能团队中，开发与测试也停留在交付与签收的关系中。这带来了两个方面的问题：

1. 团队角度：开发与测试间有组织墙，从业务理解、组织利益的角度两者都存在着隔阂，沟通效率、产品质量等都不是很好
2. 个人角度：开发不了解测试技术、能力，代码处于低质状态，难以成长；测试不了解编码，测试很容易陷入TE的部分角色活动，效率难以提升。若一个只会写写写，一个只会点点点，哪来的勇气去追求一份更好的工作

个人理解Google的角度，开发与测试（SWE、SET）最大的区别，通俗来说，开发关注开发框架、测试关注测试框架，代码设计、编写等能力无差；而业务测试（TE），是具备高度业务能力的产品专家，也需要具有一定的编码能力，业务测试是面向用户业务行为的测试，而不是代码bug或既定基础能力的测试。

在很多国内企业，没有这样的条件，但我觉着大家应该达到这样的程度：

1. 开发：在拥有一定编程能力的基础上，熟知常用的测试框架、测试理念、测试技巧，并掌握几例测试框架，与代码设计与编写相互印证。
2. 测试：掌握并熟练使用测试框架、测试理念、测试技巧，至少掌握一门脚本语言，可编程嵌入已有测试框架，并开发有自己的工具库

预期，在未来的很多领域，基础编程将会像打字一样，成为非软件岗位的招聘指标，因为独立定制、非核心、轻量级工具的开发与维护可能会给中小型企业带来极大的效率提升。而专业的程序员依然存在，但需要更高的技术水准或特定的技术领域。

收获4：预防bug而非检测bug

虽不知道在Google这句话的实施程度有多高，但其理念非常有意义。所以mark下。

收获5：活力

《Google软件测试之道》中提到Google人拥有20%的自由时间，可以参与自由项目，去尝试失败，而其中有部分项目给公司带来了巨大的价值。虽然我理解高层的言辞，从其岗位的角度只有50%的可信范围，而其中只有50%的人去真正实施了，但即使有1/4的员工去试错，也非常震撼。至少可以看到这个公司的韧性，相比公司间的借鉴和学习方式，这种方式给公司带来的最契合的成果，从而保持公司的活力与领先地位。

此处对于个人的收获，若职业中未能提供自由的试错空间，那需要攫取自由时间，去学习与试错。很多事情看到结果的时候就已经晚了。