测试不能成为导致创新和开发过程变慢的阻碍。质量从来不仅仅是测试人员的问题，在Google，每个写代码的开发者本身就是测试者。
1）质量不等于测试
质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。当开发过程和测试一起携手联姻时，即是质量达成之时。
2）角色
软件开发工程师（Software Engineer, SWE）,他们的工作是实现最终用户所使用的功能代码。SWE会对他们编写、修复以及修改的代码承担质量责任。
软件测试开发工程师（Software Engineer in Test，SET），他们的工作重心在可测试性和通用测试基础框架上。
SWE关注于功能性或性能性代码，而SET关注于质量提升和测试覆盖率的增加。SET写代码的目的是可以让SWE测试自己的功能。测试工程师（Test Engineer,TE）把用户放在第一位来思考，代表用户的利益。他们会把SWE和SET编写的测试进行组织、分析、解释、测试运行结果，推进产品发布。TE是真正的产品专家、质量顾问和风险分析师。
SWE和SET主要是模块级别与功能级别的测试。TE则关注于用户角度的测试，另外确认开发在测试方面的工作是否到位。
3）组织结构
测试团队是独立存在的部门，是与专注领域部门平行的部门。测试团队，会根据不同产品团队的优先级、复杂度等进行比较后，分配测试人员。这样可以保证测试人员方便在各个团队推广测试技术，并让产品团队无权降低测试人员的招聘要求。另外，Google对于在某个产品中工作满18个月后的测试人员，可无理由自愿转岗到其他产品。
4）爬、走、跑
Google从来不会在一次产品发布中包含大量的功能，实际上，在一个产品的基本核心功能实现之后，就立即对外发布使用，然后从用户那里得到真实反馈，再进行迭代开发。为了发布beta版本，一个产品要经历一系列的内部版本验证。
金丝雀版本：每日构建，产品相关的人才会安装这个版本。
开发版本：每周构建，该版本具有一定的功能并通过了一系列的测试，该产品下的所有人会要求安装这个版本。
测试版本：差不多每月构建，该版本通过了持续测试，比较稳定，公司内部可使用，一些想早合作的外部合作伙伴也会使用这个版本。
beta或发布版本：对外发布的第一个版本，通过了内部使用和所有质量考核的一个版本。
5）测试类型
小型测试，用于验证一个单独函数或独立功能模块的代码是否按照预期工作。主要是SWE实现，也会有少量的SET参与。
中型测试，一般会涉及两个或两个以上模块的交互，尝试解决的问题是，一系列临近的模块互相交互时，是否如预期那样。在开发早期，主要是SET驱动这些测试的实现，SWE深度参与；在开发后期，TE会通过手动方式或自动化执行这些用例。
大型测试，涵盖三个或更多功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数小时或更长的时间才能运行完成。关注点在于所有模块的集成，更倾向于结果驱动。三种工程师均会参与到大型测试中。
关于自动化与手动测试，当然更倾向于前者。如果能够自动化，并不需要人脑的睿智与直觉来判断，那就应该自动化。Google甚至把开bug和日常的手动工作都自动化实现了，例如，如果自动化用例运行失败，会直接找到最后一个Commit的人，并给此人发一封邮件，并开一个bug来记录。
总而言之，看完第一章，对文章中的一些理念与操作所震惊到了~
