《Google软件测试之道》——笔记（一）

        摘抄一些书中对笔者有触动的观点或想法，并附加笔者的感触、实际测试工作上的帮助与见解。

---

我一直这么认为，对于一个坏点子或考虑欠周的产品，即便再多的测试，也无法把它变成一个成功的产品。但如何测试方法不当，却会扼杀一个本来有机会成功的产品或公司，至少会拖慢这个产品的速度，让竞争对手有机可乘。

——序-Alberto Savoia 谷歌工程总监

        要让测试从瓶颈变成加速器。

        日复一日的质量债会让优秀的测试人员精疲力尽，每天都在不同的需求、项目上疲于奔命，使得测试人员做的工作总是事倍功半，测试成为了产品发布的阻碍。

当时的测试团队工作重点在UI的验证上，对视响应不同项目的测试需求，可以想象，这不是Google最闪耀的团队。

Google在项目快速发布方面的坚持，使得我面临两个选择，要么沿用这种劳动密集型的流程增加更多的人手，要么改变整个游戏规则，为了适应业界和Google发生的巨变，测试服务团队需要根本性的变革。

快速成长的用户群、不断积累的bug和糟糕结构的代码形成的技术债将会导致开发过程的崩溃。

——序-Patrick Copeland 谷歌测试和部署技术的架构师

         Patrick 认为，测试与开发不应该被割裂开，这不是两个单独的环节，应该重新定义测试团队。

我们引入“测试认证”，向开发团队提供咨询，帮助他们改善代码质量并尽早进行单元测试，我们开发工具指导团队进行持续集成，使产品一直保持可测试的状态。

我正式决定把团队名称改为工程生产力团队，这意味着开发人员负责测试，开发人员负责质量，生产力团队负责帮助开发团队搞定这两项任务。

——序-Patrick Copeland 谷歌测试和部署技术的架构师

        很多公司，测试人员不受重视，加班加点的完成手工测试，会自动化的人会逐渐成为开发，因为那个工资更高，更有影响力。Google工程生产力部门的奠基者客服测试偏见，拒绝个人英雄主义，在Google，测试人员已经与开发人员同工同酬，薪资待遇一致。（当然他们的招聘要求与测试人员素质也是很高的，Google工程生产力团队招聘是宁缺毋滥的，这点也会在书的正文中详细介绍）

---

        这是一本少有的能让笔者从序开始阅读的测试相关的书籍，文档的观点、思想、方法对于笔者的实际测试工作有很大帮助，笔者所在公司遇到的测试问题能在Google的测试发展史上找到对标的影子，整本书看下来，总能与笔者产生共鸣，激动！接下来，笔者会持续的分享一些书中的观点和想法。