先交代一下写作背景：这二年在软件项目中非常流行一个词——敏捷。大大小小的项目，通常都打着敏捷的旗号招摇过市，有自我感觉良好的，有感觉很坑爹的，也有更多的公司是为了利益，披着敏捷的外衣，却做着浮躁的事。其实我觉得敏捷本身是一种很好的思想，是当软件工程发展到一定阶段后必然出现的事。面对风云变幻的市场，谁都想自己身手矫健，迅速响应市场或客户的变化。但如何真正在项目中做到敏捷，却不是想得那么容易，除了方法论之外，还有各种外部条件的制约。而现实是很多研发团队只注重了方法论的学习，而没注意组织结构应该如何变化才能适应敏捷测试的需要。就像人类的进化史一样，大脑在逐渐变得发达和更加善于思考，但如果手脚不能进化到可以独立行走，把双手解放出来劳动，那人类根本也就走不到今天。有的童鞋可能又想说了，敏捷强调的不是人人都应该是开发和测试吗？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)之后，我们接下来就可以根据所要做的这些事的特点，再去甄选合适的人去完成它。这里需要注意的一个原则是：尽量发挥每个人的特长，让专业的人去做专业的事，杀鸡用牛刀或者杀牛用匕首都是不可取的。我先给出具体的组织架构图，再来看看为什么安排这些人去做这些事。

 

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

Unit/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测试的工程师提供有力的帮助。

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

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