Google软件测试之道（James Whittaker, Jason Arbon, Jeff Carollo）

[wittyResry]

引言

• 保证开发速度的同事，充分意识到质量的重要性。一个团队能编写出高质量软件的唯一途径是全体成员共同对质量负责，包括产品经理、开发人员、测试人员等所有人。我认为，达到此目标的最好方式是使测试人员有能力将测试变成代码库的一个实际功能，而测试功能的地位应该与真实客户看到的任何其他功能同等重要。所需要的能够实现测试功能的技能，也正是开发人员需要具备的技能。
• 这里是Google，如果你有想法，尽管去做就是。

  3.2 ACC（Attribute Component Capability）的指导原则

• 推荐使用间接的图表
• 不要把不重要的、无法执行的东西放进测试计划。
• 渐进式描述。测试计划是前面的延伸，以便使读者可以随时停止阅读并且对产品的功能有一个初步的印象。
• 指导计划者的思路。一个好的计划过程能帮助计划者思考产品功能以及测试需求，从而有条不紊地从高层概念过渡到可以被直接实现的低层细节。
• 最终的结果应该是测试用例。在计划完成的时候，它不仅要清楚地描述要做什么样的测试，并且还可以清楚地指导测试用例的编写。做出一个不直接指导测试的计划纯粹是在浪费时间。
• 最后一点非常重要：如果测试计划没有吧测试用例应该怎么执行描述清楚，就没有达到预先这顶帮助测试的本义。当你正好处于“完全了解需要编写哪些测试”这一点时，才算完成了测试计划。

  3.3 与GoogleDocs测试工程师Lindsay Webster访谈

• 从头到尾的理解产品。不管是整体的设计文档，还是主要功能的设计文档，我都会去看。只要有文档，就会去看。
• 在消化了这些文档之后，我开始关注项目的状态，特别是质量状态。我会去了解bug的数量、问题的分组方式、已经报告的bug类型、最长时间未处理的bug、最近一些bug的类型，还会看下修复比例。

[wittyResry]

1.2 角色

• 软件开发工程师（Software Engineer，简称SWE），他们的工作主要是实现最终用户所使用的功能代码。他们创建设计文档，选择最优的数据结构和整体架构，并且花费大量时间在代码实现和代码审核上。SWE需要编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等。SWE会对他们编写、修复以及修改代码承担质量责任。假设一个开发者不得不修改一个函数，如果这次修改导致已有的用例运行失败，或者需要新增加一个测试用例，他就必须去实现这个测试用例的代码，或者修复测试用例。开发工程师几乎将所有的时间都花费到了代码编写上。
• 软件测试开发工程师（Software Engineer in Test，简称SET）也是一个开发角色，只是工作重心在可测试性和通用性测试基础框架上。他们参与设计评审，非常近距离地观察代码质量与风险。他们可能编写单元测试框架和自动化测试框架。SET是为质量服务，SWE更关注客户使用功能的开发。
• 测试工程师（Test Engineer，简称TE）是一个和SET关系密切的角色，有自己不同的关注点——把用户放在第一位来思考，代表用户的利益。一些Google的TE会花费大量的时间在模拟用户的使用场景和自动化脚本或代码编写上。同时，他们会把开发工程师和SET编写的测试分门别类组织起来，分析、解析、测试运行结果，测试驱动执行，特别在项目最后阶段，推进产品发布。TE是真正的产品专家、质量顾问和风险分析师。

1.3 组织结构

• 开发人员和测试人员录属于同一个工程产品团队。而且开发和测试人员也汇报给同一个产品团队的管理者。不幸的是，资深管理者一般都来自于产品经理或开发经理，而不来自于测试团队。产品发布时，优先考虑的是功能完备性和易用性方面是否足够简单，却很少考虑质量问题。很多时候，质量不行就再发一个补丁包。

[wittyResry]

3.2.6 Google的测试领导和管理工作

• Google的管理更多的是激励。Google管理的核心是领导力和洞察力、协商、外部沟通、技术水平、战略规划、招聘和面试、完成团队绩效考核。Google的测试总监、经理和其他领导者都必须在充分信任工程师和确保他们不会发生重大事故或浪费时间之间寻找平衡。Google专注于投资大型的、战略性的方案去解决大问题，经理们有责任区避免开发重复的测试框架、或是投入在小型测试上，而应该鼓励宝贵的工程师资源用于更大型的测试执行和基础平台的建设。倘若没有这种监督，只靠20%的自由时间，很多测试工程师项目经常会半途而废、徒劳无功。
• Google测试工程团队可以用海盗船来做类比。测试组织里的工程师的天性就是自主驱动、自主定向——那么如何管理这些人呢？海盗船长无法通过强力来管理这群人。他们通常都不愁去处，才能显著，而船长是孤家寡人。他也不能只能靠金钱，因为这群海盗通常衣食无忧。他们真正的动力在于劫掠的生活方式和看到下一次收成的兴奋感。叛乱随时可能发生，因为Google的组织是动态者的。工程师甚至被鼓励频繁更换团队。如果这个船没有找到足够多的珍宝，或者活儿很没劲，工程师海盗就会在下一个港口弃船而去。作为一个主管，以为着你自己就是一个海盗工程师。和别人相比，你不过是稍微更加清楚地平线上有什么，附近有什么船，它们可能载着什么珍宝。要靠技术洞察力、令人兴奋的技术冒险、有趣的停靠港口来带领团队。在Google，工程经理即便在睡觉时都得睁着一只眼睛。
• Google有几种不同类型的主管和经理：技术负责人、技术主管、工程经理和总监。
  • 技术负责人：技术负责人出现在大型项目的大型团队里，有大量的SET和TE，他们参与解决共同的技术问题。他们是当你遇到技术或测试问题时要求助的人。
  • 技术主管：当技术负责人同时也被人们为相关工程师的经理时候，就被称为技术主管。这些人一般的高望重、能力卓著。通常一时间只关注一个项目。
  • 测试工程师经理：经常跨团队技术工作，他们负责共享跨团队的工具和流程，根据风险评估安排资源，并指导招聘和面试。
  • 测试总监：推动战略性、有时是转型性的技术架构或测试方法的实施。他们关注点在于怎样通过质量和测试区帮组业务。
  • 资深测试总监：只有一个，负责统一的职责描述、招聘、外部沟通和总的测试战略。他日常工作包括分享最佳实践，建立和推动大动作。