敏捷测试推进工作笔记（一）

【从这篇文章开始，我打算在本专栏中记录本人在组织中推进敏捷测试的工作过程，这篇文章描述的是从 5 月到 8 月共 3 个月内的主要工作。在两个月的时间内，我们初步决定了发展方向，在敏捷测试的氛围建设方面都有了一些进展。2 个月中主要的工作是：团队改造，工具体系搭建，建立了初步的开发和测试的尊重和良性互动，开始在少数项目中使用自动化测试建立更好的反馈机制和提升效率】

2011 年 4 月，我离开了原来的团队，加入了一家 200 人左右的互联网创业公司（以下简称 H 公司）并担任该公司的 Engineering VP 职务。我负责的团队包括一个产品开发团队，测试团队和其他两个团队。离开一个成熟的敏捷环境，进入一个新环境，我期望能够使用敏捷方法让这个新公司的开发和测试部门能够有更好的生产率和更好的工程师驱动的文化。从 6 月份至今，我已经在组织内推进了一些与敏捷相关的行动，从结果上看，敏捷的意识和氛围的确向前推进了一些。当然，在我看来，创造一个更接近敏捷的环境是手段而非目的，因此，这一系列的笔记仅用来尽可能忠实的记录我在这个组织中推进敏捷测试的方式，以及这些推动带来的改善。

H 公司是一个以 social game 开发和发布为主要业务的公司，在我刚加入的时候，H 公司的测试团队有 15 人，几乎全部成员都没有什么技术背景，采用的测试方式是典型的手工测试。团队使用 Testlink 工具管理用例和测试执行，使用 Bugzilla 系统进行缺陷跟踪，自行开发了提测系统用于管理测试提交。测试人员分布在各项目团队中，每个项目有 2-4 名测试工程师，测试工程师的主要工作方式是被动接受测试任务，按照开发工程师指定的测试范围进行手工验证。显然，这是一个国内企业典型的传统测试团队，测试团队成员充当“发现问题的最后一个环节”，以黑盒和手工测试的方法对应用进行验证。

Socail game 这个是一个竞争非常激烈的行业，对 social game 来说，快速更新和快速发布往往是一款游戏能否成功的关键之一。因此，对 H 公司来说，快速发布的能力非常关键。通常，开发工程师可以在一周内完成 3-4 个新功能提交，但由于测试工程师需要在多个平台和多个浏览器上对应用进行测试，结果测试往往成为产品发布的瓶颈。从开发工程师和产品的角度来看，测试时间太长；而如果为了缩短测试时间而仅将测试范围定义在新功能上，测试中又会遗漏不少问题，导致结果不理想。在这种状况下，测试工程师越来越忙，却完全不能真正在提升产品质量方面发挥作用。

显然，H 公司的测试团队采用的传统测试流程和方法在这类要求“快速”的企业中很难适应，除非对测试团队的行事方式与测试文化进行一个彻底的改造，测试团队很难在组织中发挥重要的作用。

敏捷的推进先从团队开始

团队在敏捷中的重要性不言而喻。团队是由个人组成的一个集体，在我看来，决定团队的水准的，自然是团队中的每个个体，如果一个团队中的成员根本就不具备帮助达到这个团队目标的能力，再有能力的领导，再好的愿景也是白扯。因此，首先需要的是从人入手改造这个团队。这个团队中的成员几乎都没有很好的开发和编码背景，要求他们从开发的角度理解测试、理解生产率和推进自动化是不可能的事情。对他们来说，对自动化的理解很可能就是找个工具录制一下，形成脚本，然后简单的维护一下脚本。而我期望推进的是，建立一支真正能够真正与开发形成良性交互，能够帮助推动整个组织的生产率和产品质量的队伍。考虑到整个公司的现状，大规模的替换测试团队的成员是不现实的，因此，在测试团队之外，我们新成立了一个 Tools/Automation 的组，这个组的目标是推进整个组织的自动化，从生产率上帮助建立自动化框架（不仅仅是测试自动化，而是整个组织的自动化和生产率）。这个组的每个成员都由我自己担纲招聘，虽然到目前为止这个团队只有四个人，但由于每个人的编码和测试经验都比较不错，更重要的是，他们都是爱折腾，对结果负责，愿意推动事情发生的人，因此，到目前为止他们在推动敏捷测试环境方面发挥了主要的作用。

除了建立新的团队外，提高原有团队的招聘标准是另一个手段。虽然各个项目组在新功能更新频繁的情况下，不断的要求增加新的手工测试工程师，但在我的坚持下， “新进入的测试工程师必须要求具有一定的编码技能和知识背景”这一条要求还是能够得到满足。当然，项目组缺人的问题是必须要解决的，因此我主要依靠在项目中可以明确看到结果的逐步的自动化测试推进让项目组意识到依靠自动化测试解决他们的问题比依靠手工测试有效得多。此外，在整个团队中不断要求和灌输“测试价值”的理念，使得开发和测试工程师都能认识到单纯的以“发现缺陷”为目标的测试文化是很难在现有环境中产生价值的。

自动化推进

这里所说的自动化，并非仅仅意味着“自动化测试”。诚然，自动化测试是敏捷测试的基础，但采用自动化技术让产品发布自动化、让不同层次的测试都存在执行的基础，这样才可以将开发和测试工程师纳入到敏捷测试的同一阵营中来。

1. 为项目建立自动化的构建环境和持续集成环境
   每个项目最少需要有自动化的构建环境和持续集成环境。哪怕持续集成中仅包含一个测试用例，持续集成也至少可以让整个开发组织能够建立基于反馈（持续集成结果）的开发方式。而自动化的构建环境则允许开发和测试之间的协同工作变得简单，且减少了构建过程中出错的可能。能够用于建立自动化的构建环境和持续集成环境的工具非常多，这里就不再赘述具体过程。

2. 建立初步的代码质量体系
   高 质量的代码是高质量软件的基础。除了对产品的测试外，从源头开始控制代码的质量对促进和提高产品质量也非常关键。Code Review 是极好的进行代码质量控制的手段，基于 H 公司的 svn 代码库，我们通过钩子，加上开源的一些 Code Review Dashboard 工具建立了一套强制的 Code Review 流程，要求所有代码必须经过 Code Review 后才能被 check in 到代码库。另外，Code Review 系统中集成了静态代码检查工具，Reviewer 在评审代码的时候可以直接看到提交代码的静态检查结果报告。

3. 自动化测试
   敏 捷测试中，自动化测试是必不可少的重要环节。但是，在组织中推进自动化测试并不是一件轻松的事情。首先，如果组织的测试目标已经被固定成了“尽可能发现最多的缺陷”，如果开发工程师、甚至测试工程师自己已经习惯了把发现缺陷和工作时间当成自己唯一的评价标准，在这种情况下推动自动化测试，结果不言而喻。

组织首先要有自己明确的自动化测试可达成的目标。在我的理解中，自动化测试的最大贡献在于两个：1，让全体工程师（测试和开发）都可以成为测试的执行者和设计者，让验证可以在尽可能小的周期内发生（快速反馈）；2，自动化测试不以流程为中心，可以持续演化并适应快速的需要。对 H 公司来说，显然，通过自动化测试可以达成的，与团队期望最契合的目标应该是“通过自动化测试尽可能在短的测试周期内达到更高的覆盖率”。因此，在我们的自动化测试推进中，该目标成为了自动化测试需要达成的最首要的目标。

对于任何应用来说，从技术角度来看，最好的自动化测试都应该是在产品设计时引入可测试性，这样可以在不同层次上对应用进行验证。但如果对一个已有产品已经比较固定，且很难对其进行大规模重构的组织来说，对这些已经固定的产品进行重构以便于自动化测试的开展显然是不现实的。在自动化推进时，我们并没有把自动化测试建立在革命，而是革新的基础上。虽然我本人是坚定的大规模 UI 自动化的反对者，但在对 H 公司的产品（游戏类应用）进行了详细了解，以及对开发过程进行了详细了解后，我还是不得不承认，在现阶段，使用主要基于 UI 的自动化测试是更适合 H 公司现状的方式。目前我们选用的自动化测试工具是 Sikuli 工具，基于该工具设计了一套适合 H 公司游戏产品的自动化测试框架，通过 mock 本地环境等手段，目前 UI 自动化测试的稳定性可以达到 95% 以上，对于游戏的测试是一个很好的提升手段。

其他

以上就是我们在 3 个月内为敏捷测试推进工作进行的改进。不得不说，到目前为止，这才是在前进的道路上迈进了一小步。真正的组织级的敏捷需要持续建立更好的沟通、建立自承诺的团队，以及持续改进。不管怎样，在这 3 个月的时间内，我们通过这些工作，测试团队的氛围开始发生了变化，开发工程师开始愿意配合测试团队，为其提供更好的测试接口，所有的测试成员都开始意识到交付价值比交付 bug 重要…… 这是我们向敏捷推进的一小步，但相信是坚定的一步。

接下来的一段时间内，敏捷的核心价值观仍然是指导我们的法则，持改变的勇气，不断检讨，不断优化；保持简单，把资源投入到最值得提高的地方；建立更好的沟通方式，更好的信任与尊重，相信一段时间后，我们能看到接下来的仍然坚定的下一步。

感谢张凯峰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。