敏捷测试中理想的测试组织

　　近些年，在软件项目中非常流行一个词——敏捷。大大小小的项目，通常都包含着"敏捷"这个关键字。其实敏捷本身是一种优化的思想，是软件工程发展到一定阶段后的产物。面对风云变幻的市场，都希望迅速响应市场或客户的变化。但如何真正在项目中做到敏捷，除了方法论之外，还有各种外部条件的制约。而现实是很多研发团队只注重了方法论的学习，而没注意组织结构应该如何变化才能适应敏捷测试的需要。有的人可能会说，敏捷强调的不是人人都应该是开发和测试吗?但这只是在理想情况中。真实项目中，肯定还是存在测试和开发的分工的。所以本文想谈谈在敏捷测试中，我们的测试组织应该如何建设，才能合理将工作进行分工，充分发挥组织内部每个人的长处。即在敏捷测试环境中，我们应该用什么样的人，去做什么样的事，才能获得最大的效率。

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

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

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

　　图 1. 敏捷开发组织架构图

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

　　Unit/Component 测试(负责人：开发人员)

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

　　回页首

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

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

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

　　回页首

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

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

　　回页首

原文转自：http://www.ibm.com/developerworks/cn/rational/r-cn-agiletestorganization/