让合适的人去做合适的事--敏捷测试中理想的测试组织(李 欢, 软件工程师, IBM)

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

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

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

在一本比较著名的讲解敏捷测试实践的书《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
分析要求测试人员具备良好地沟通和理解能力，能够将客户表达出来的或者潜在的客户需求转换为我们的用户"故事"和业务逻辑的描述，供开发人员进行参考。系统测试就不说了，大家都很了解，需要对被测系统有深入全面的了解所以在这几个测试类型中，是对测试工程师能力的一个综合考验，虽然没有涉及到代码以及自动化，但必须要求测试经验丰富，测试方法掌握扎实，对业务精通的人员来进行。

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

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

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

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

图 2. 自动化测试周期图



回页首
总结

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

一、就是实现了我刚刚说的那个原则：让专业的人去做专业的事。这句话说起来简单，但如果我们无法理清敏捷测试中的各种测试类型，需要什么样的测试能力，我想这个原则是很难实现的。太多测试中一做自动化就要求所有的人都去学习编程，学习工具，对于没有这方面兴趣的人来说，这简直就是痛苦得要命的过程，何必呢？如果他擅长于测试理论，熟悉产品业务和需求，那就让他去做探索性测试，让他去分析 user-story 或者是系统测试。只要测试组织者或者团队建设者真正清楚了测试的需求，那我相信他就不会大而全地要求每个人都是每一方面的专家。

二、招聘的时候可以更加有的放矢。我的组织中需要完成什么样的任务了，我就去招什么样的人 . 现在很多企业的招聘广告上都会写：要有自动化测试的经验，有编程经验，会脚本，精通测试理论等等。这样大而全的要求会带来什么样的后果？你对人家的要求多，那他必然要价就高，那企业白白浪费大把金钱去招了一些能力强但不适合的人进来，从而实际效率得不到提高，而且很可能招不到合适的人。测试团队里面缺的就是做探索性测试的人，为什么一定要他具备自动化测试的经验呢，为什么要他有编程能力呢？完全没必要。再比如我现在有几个经验比较丰富的测试工程师做探索性测试了，但
BAT 和 Regression 没多少人做，那我完全可以招没什么经验的实习生进来，又好用又不贵，何乐而不为呢？如果觉得要做一套测试框架，也没必要要求人家有很深的测试背景，懂得多高深的测试理论，只要开发功底扎实，那一定就符合需求了。

参考资料

学习

访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。

订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。

获得产品和技术

下载更多免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。

获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。

讨论

加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

访问 developerWorks 社区上的
敏捷开发小组，在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。