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

　　【从这篇文章开始，我打算在本专栏中记录本人在组织中推进敏捷测试的工作过程，这篇文章描述的是从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的组，这个组的目标是推进整个组织的自动化，从生产率上帮助建立自动化框架(不仅仅是测试自动化，而是整个组织的自动化和生产率)。这个组的每个成员都由我自己担纲招聘，虽然到目前为止这个团队只有四个人，但由于每个人的编码和测试经验都比较不错，更重要的是，他们都是爱折腾，对结果负责，愿意推动事情发生的人，因此，到目前为止他们在推动敏捷测试环境方面发挥了主要的作用。

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

　　自动化推进

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

　　为项目建立自动化的构建环境和持续集成环境

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

　　建立初步的代码质量体系

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

　　自动化测试

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

原文转自：http://www.ltesting.net