先交代一下写作背景：这二年在软件项目中非常流行一个词——敏捷。大大小小的项目，通常都打着敏捷的旗号招摇过市，有自我感觉良好的，有感觉很坑爹的，也有更多的公司是为了利益，披着敏捷的外衣，却做着浮躁的事。其实我觉得敏捷本身是一种很好的思想，是当软件工程发展到一定阶段后必然出现的事。面对风云变幻的市场，谁都想自己身手矫健，迅速响应市场或客户的变化。但如何真正在项目中做到敏捷，却不是想得那么容易，除了方法论之外，还有各种外部条件的制约。而现实是很多研发团队只注重了方法论的学习，而没注意组织结构应该如何变化才能适应敏捷测试的需要。就像人类的进化史一样，大脑在逐渐变得发达和更加善于思考，但如果手脚不能进化到可以独立行走，把双手解放出来劳动，那人类根本也就走不到今天。有的童鞋可能又想说了，敏捷强调的不是人人都应该是开发和测试吗？OK，我不反对，但我们不是活在童话世界中，你的理想有多丰满，现实就有多骨感。在真实项目中，肯定还是存在测试和开发的分工的。所以本文想谈谈在敏捷测试中，我们的测试组织应该如何建设，才能合理将工作进行分工，充分发挥组织内部每个人的长处。再说直白点就是，在敏捷测试环境中，我们应该用什么样的人，去做什么样的事，才能获得最大的效率。

当考虑团队的组织结构的时候离不开两点考虑：要做什么事和要什么样的人去做这些事。其实很多人对敏捷测试并不太熟悉，甚至不知道谈到敏捷测试，我们究竟指的是哪些测试，要怎么做才能使测试敏捷起来。所以我们先来看看第一个问题：要做什么事，也就是说当我们谈到敏捷测试时，我们究竟谈了些什么。

在一本比较著名的讲敏捷测试实践的书《A Practical Guide for Testers and Agile Teams》中，明确将敏捷测试的所有测试类型划分为了四个象限的测试，按照测试内容来分，可以主要分为面向技术（Technology-Facing）和面向业务（Business-Facing）的测试。在面向技术的测试中，主要包括我们熟悉的Unit/Component测试，PSR（Performance， Security， Reliability）测试，Usability测试等等。而在面向业务的测试中，主要包括手动的探索性测试，User-story和系统测试，以及自动化的BAT和回归测试等等。由于这里所讲的测试类型的特点都会跟什么样的人去做有很大的联系，所以在接下来的部分我再详细讨论各种测试的特点。

OK，知道了敏捷测试究竟在做什么，也就是它所指的范围（Scope）之后，我们接下来就可以根据所要做的这些事的特点，再去甄选合适的人去完成它。这里需要注意的一个原则是：尽量发挥每个人的特长，让专业的人去做专业的事，杀鸡用牛刀或者杀牛用匕首都是不可取的。我先给出具体的组织架构图，再来看看为什么安排这些人去做这些事。

先来看看面向技术的测试。为什么是面向技术呢？因为这些测试类型都是需要深入到代码级或者是需要工具去实现的，而且跟具体的业务逻辑和业务流程关系不大。

nit/Component测试（负责人：开发人员）

这部分的测试应该由开发人员自己去完成。原因很简单，谁最清楚代码的结构和代码逻辑？开发人员。我们完全不必专门安排所谓的白盒测试或者单元测试工程师去帮开发去完成这些事，这些是他们应该完成的事，往大了说就是每个人都应该为质量负责。而且，特别是在测试驱动开发的模式中，我们更是绝对不能让测试人员越俎代庖地去做这些事，那样做是得不偿失的。因为如果不是由开发人员自己去写的测试代码，那么到时出了错，要想debug或者是找rootcause的话，将会花费更多的代价。所以记住在测试驱动开发模式下，开发和测试那块根本就没测试人员什么事，作为测试人员大可不必想着一定要读懂代码才牛，从老板或者是组织管理者的角度看的，那简直就是浪费钱，测试人员应该做的是，如何更好地帮助开发去理解需求，也就是敏捷中常说的user-story，以及如何设计测试来验证产品是否真正完成了这个user-story，接下来面向业务的测试中还会说到这点。

PSR以及各种“ility”测试（负责人：相关测试类型专家）

性能、安全性以及各种用户体验啊，易用性健壮性测试对产品的重要性不言而喻，而这些测试类型往往又是非常专业的，复杂性程度相当高。要想做好，不仅仅是会用一点工具，会录制下脚本，或者是懂看代码就能实现的。它要求测试人员不仅对工具使用非常娴熟，更重要的是要深入了解系统架构以及系统所运行环境的具体情况，如桌面程序，在安全性方面往往跟系统本身的安全性紧密相关，要求测试的人对所在的系统也要了如指掌，web程序，性能瓶颈更是跟系统软硬件，所用协议等密切相关，没有对这些相关方面有系统地把握和学习，根本做不好。所以如果是组织内部有条件，可以由专门做这些非功能性系统测试的专家或者资深工程师负责这些类型的测试，才能得到比较理想的测试效果，不然最大的可能性就是走走过场而已，得不到实际的效果。

再来看看面向业务的测试。面向业务的测试是大部分测试人员所熟悉和了解的，但测试工程师也有好几种类型，初级的，高级的，做自动化的，做手动的，该如何按照不同的测试类型来进行分配？

ET/User-Story/System测试（负责人：有经验的/高级测试工程师）

在敏捷测试中，这几种测试的重要性也是不言而喻的。像探索性测试在敏捷测试中，甚至超过了系统测试的重要性，是敏捷测试面向系统和业务的核心测试类型。探索性测试的特点是测试人员可以事先对被测系统没有任何的了解，通过一边学习一边测试，快速地在有限时间内根据优先级最大限度地发现系统中存在的问题，所以说效率非常高。当然，同时对测试人员的要求也就非常高。它可以没有测试用例，但一定有很多引导测试人员思考的test idea，只有测试人员自身经验非常丰富的情况下，他才有可能根据最少的线索，猜测最有可能发现bug的地方。并且快速学习和总结能力是个不可或缺的条件，这就注定了只能由经验丰富的高级测试工程师才能hold住。User-story分析要求测试人员具备良好地沟通和理解能力，能够将客户表达出来的或者潜在的客户需求转换为我们的用户故事和业务逻辑的描述，供开发人员进行参考。系统测试就不说了，大家都很了解，要做好需要对被测系统有深入全面的了解。所以在这几个测试类型中，是对测试工程师能力的一个综合考验，虽然没有涉及到代码以及自动化，但必须要求测试经验丰富，测试方法掌握扎实，对业务精通的人员来进行。

BAT/Regression（负责人：初级测试工程师）

估计没人会反对我们在项目里要最大限度地利用自动化测试来开展BAT和regression测试，这是由自动化测试的特点和对ROI的考虑来决定的。敏捷测试中不可避免地要用到自动化测试，不然一切敏捷都是扯蛋了。而要想提高自动化测试的复用率和降低维护的难度，我们最好能够考虑根据业务更多地使用测试框架，将业务逻辑、测试数据和测试脚本高度解耦，例如使用关键字+数据驱动的混合型框架。这里实际上为什么说BAT和regression只需要没什么测试经验的人去做呢？实际上前提条件就是我们要合理利用框架，像关键字框架等等，用这些框架的人不需要去学习编程，他们只需要能够利用已有的关键字根据测试的需要去组合测试用例即可。所以并不是每个做自动化测试的人都必须具备编程能力的，他们在没有太多测试经验的情况下，做探索性测试是不合适的，但他们可以利用这些关键字练习和设计测试用例，又可以帮助组织执行自动化测试，充分发挥他们应该有的价值，同时自身也可以得到提高。

Test framework development（负责人：自动化测试开发工程师）

测试框架的应用在敏捷测试中也是举足轻重的，因为它涉及到自动化测试的复用性和可维护性的问题。脚本的复用性低和维护性差往往成为很多组织自动化测试失败的根本原因。辛辛苦苦开发的测试脚本不能复用，一点小小的功能改动都涉及大批脚本的改动，实在是伤不起。而不管是利用现成的测试框架，如robot或者是自己根据产品的需求开发的测试框架，其本身实际上都是一个完整的开发项目，所以需要负责框架开发的人非常熟悉软件设计方法和扎实的编程技能，这样的要求通常只有对技术狂热爱好的人才有可能达到。他们可能不需要太关心产品业务层面的东西，那不是他们关注的重点。他们需要的产品方面的知识往往可以从其他测试人员那里了解到，这就足够了，如需要开发哪些关键字，都可以由其他人告诉他们即可。他们应该关心地如何使得测试框架本身可以灵活适应产品需求的变化，如何提高框架的复用性。所以归根结底就是对编程和程序设计方面的要求较高，他们具备这些能力后，可以专门关注测试框架方面的工作，从而为BAT和Regression测试的工程师提供有力的帮助。

当然，这只是在敏捷测试中一种较为理想的测试资源的组织安排模式。它的前提是我们现在有所有这样的一些人，那么我们就可以把他们安排到他们最擅长的测试类型中去。这样做的意义主要有以下两点：

1、就是实现了我刚刚说的那个原则：让专业的人去做专业的事。这句话说起来简单，但如果我们无法理清敏捷测试中的各种测试类型，需要什么样的测试能力，我想这个原则是很难实现的。我见过和听过太多测试中一做自动化就要求所有的人都去学习编程，学习工具，对于没有这方面兴趣的人来说，这简直就是痛苦得要命的过程，何必呢？如果他擅长于测试理论，熟悉产品业务和需求，那就让他去做探索性测试，让他去分析user-story或者是系统测试，没必要吊死在自动化这一棵树上。只要测试组织者或者团队建设者真正清楚了测试的需求，那我相信他就不会大而全地要求每个人都是每一方面的专家。 2、招聘的时候可以更加有的放矢。我的组织中需要完成什么样的任务了，我就去招什么样的人。现在很多企业的招聘广告上都会写：要有自动化测试的经验，有编程经验，会脚本，精通测试理论等等等等。这样大而全的要求会带来什么样的后果？你对人家的要求多，那他必然要价就高，那企业白白浪费大把金钱去招了一些能力强但不适合的人进来，从而实际效率得不到提高，而且很可能招不到合适的人。比如测试团队里面缺的就是做探索性测试的人，我为什么一定要他具备自动化测试的经验呢，为什么要他有编程能力呢？完全没必要。再比如我现在有几个经验比较丰富的测试工程师做探索性测试了，但BAT和Regression没多少人做，那我完全可以招没什么经验的实习生进来，又好用又不贵，何乐而不为呢？如果觉得要做一套测试框架，也没必要要求人家有很深的测试背景，懂得多高深的测试理论，只要开发功底扎实，我想那一定就符合你的需求了。我突然想起一句广告说得非常对：只选对的，不要贵的。

当然，我这里只说出了我的一点想法，欢迎更多的看官童鞋们一起分享你们的经验，分享创造价值嘛。如果喜欢敏捷测试的朋友可以看看我文中说的那本敏捷测试实践的书，网上有英文版的下载，相信会对大家有好处，呵呵。