敏捷方法中内建了许多传统的测试管理活动，随着人们对敏捷团队特性，例如自组织、角色的模糊化以及技能的多样性的期望，测试管理的性质也随之改变了。我们必须回答的问题是，在高效的敏捷组织中，测试经理这一角色是否还有存在的必要？这一角色一直以来所从事的这些活动又是如何被剥夺的呢？
按照Tom Roden和Ben Williams的说法，敏捷测试管理的关键在于建立正确的测试文化、对人们进行指导教育、并且通过实践表明团队应当如何保证测试对敏捷的支持。不过，这几点都不是传统的测试管理特性，因此，在敏捷组织中测试经理这一角色不应继续存在的论点就变得更为突出了。
在敏捷测试日荷兰2015大会上，Roden与Williams在演讲中谈到了测试管理的变革。他们展现了测试经理这一角色是怎样转变为团队的推动者，而不是团队的管理者。在管理方式与责任上的变化也意味着敏捷团队将进行多种传统的测试管理活动，这也使得测试经理这一角色产生了巨大的变化。此外，在敏捷方法中应当将测试策略作为一种活动的文档，它是活动的、保鲜的、并且随着团队以及使用它们的人一起成长的。
小编有幸采访了Roden与Williams，采访内容涉及了测试经理的角色、敏捷测试管理的重要性以及它能够带来的价值、敏捷测试管理的各种活动、测试经理应当如何为敏捷进行自我准备，以及在敏捷方法中测试经理所采取的不同测试策略。
小编：像Scrum这样的敏捷方法并没有提到在瀑布式项目中常见的测试经理这一角色。在你看来，这会不会成为一个问题？
Roden 与 Williams：我们会半开玩笑的问道，这会成为谁的问题呢？如果我们采取所有管理都是有害的这种强硬的观点，那么从组织的角度来看，我们就要问一问，专门为测试设立一个经理究竟有什么价值？它到底是有用的还是纯属浪费，或者更实际点说，设立这一角色所带来的价值能否超过它所带来的负担（即暂时的浪费），直到最终可以完全撤消这一角色为止？
从某个测试经理的角度来说，如果我们表示这一角色没有继续存在的必要，或者说必要的测试经理角色数量减少了很多，那么长期来看这确实会为成为某种问题。短期来看，问题可能主要在于那些在敏捷环境中工作的测试经理的期望。在严格实践敏捷方法的公司中，至少他们会发现，需要他们所从事的工作的类型与他们在传统软件项目中熟悉的工作类型有着根本性的不同。
Scrum中并没有定义测试经理这一角色，但它也没有定义项目经理的角色，这些职责大部分转交给产品负责人了（似乎他们没有足够的事情要做，一切都可以概括为“负责产品”）。而在实践中，尤其是在大型组织中的大型项目群中，通常会设立项目经理、项目群经理以及项目组合经理，他们将填补这一缺口，并帮助Scrum实现大规模化。
因此，真正要回答的问题是，实践敏捷的组织是否需要在特性开发团队之外设立某个角色，专门从事与测试相关的工作？如果他们确实需要这一角色，那么这一角色究竟是什么？什么时候设立他才是合适的或实用的？他的工作范围及规模又是什么？
小编：你们能否分享一下对于敏捷测试管理较高层面的观点？
Roden与Williams：在我们看来，敏捷测试经理这一说法本身就是不恰当的。敏捷团队中的测试人员本身就不需要什么管理，因此“经理”这一职位应当被彻底丢弃。那些团队同样也会承担传统的测试经理一职所承担的很大一部分测试管理责任，注意，测试管理与测试经理是不同的。
我们应当将角色与功能进行分离，这一角色的定义对于许多人来说可能还不够清晰，这或许是对敏捷方法对测试的变更的误解所造成的。团队能够在多大程度上了解这一角色，并有效地开展工作，以及需要多久才能达到这一层次，这是一个有趣的挑战。而对于“敏捷”方法及其混合应用的大量不同的实现方式则是另一个挑战，在这种场景下很难断言某个特定角色的定义。
现在我们了解了这一角色可能遇到的问题，那么我们的观点是：这一角色应当跨多个团队工作，他的功能性体现在对测试进行支持、助理以及教导，同时逐渐增加实践和技术的思考方式以及工具应用技能。关键在于建立正确的测试文化、对人们进行指导教育、并且从实践中证明团队应当如何保证测试对敏捷的支持。
这一角色的工作并非将编写长篇大论的测试策略、繁重的测试计划文档、测试时间表，或是举行长时间的bug分类会议作为每天的工作内容，也不是时时刻刻盯着测试人员，要求他们递交测试进度报告。如果你在敏捷环境中工作时还整天做这些事，那么要么你的工作环境完全不是敏捷的，要么至少你在这个环境中待的时间还不够长。这句话听起来有些严厉，但我是有意这样的。这并不是说传统项目中的测试经理的工作经验对于敏捷方法不起作用，它的实用性确实是存在的，但也会遇到极大的挑战。只是说在“敏捷”背景中，这些事情不应该占据任何人，包括聪明绝顶的测试经理的宝贵时间！！
小编：你们刚刚提到，测试经理也可以担任一名教练，对于这一点能否给出一些示例呢？
Roden：我的职业生涯发展路线差不多就是这样的。虽然我之前从事的是探索性测试及类似于验收测试驱动开发的实践，但我在传统项目中也有许多年的经验。
我有幸协助参与了一些敏捷项目，那些项目在测试上遇到了困境。在经过一段时间的指导工作之后，我发现那些团队需要的不是管理，而是教导。他们需要努力尝试在更短的时间内进行更多的测试，专注于测试正确的任务，并掌握正确的技术，而实现这些需要心态上的巨大转变。因为它主要是关于行为的转变，因此与执行计划、分配任务以及跟踪团队状态等并没有多大关联。实际上，这些行为与团队的授权与自组织的期望效果是完全对立的。
Roden与Williams：实现敏捷的一个主要前提是允许团队的自组织及完全跨职能，因此团队之外的每个人的目标都是尽力支持这一目标的实现。由咨询和教练职能来提供这种支持是非常合适的做法。
那些正在实现敏捷测试并开始从事教练工作的测试经理可能已经发现，他们从进行教练工作中所获得的乐趣完全不比其它类型的工作来得少。我们曾经多次亲眼看到许多人担任了各种不同的教练角色。有些人直接转变为Scrum Master或敏捷教练，但他们还是将测试作为专业技能的主要领域。
在测试中还有一些高级角色，他们更倾向于以教练为导向。他们可能不会是责任更大的测试主管之类的角色，而是进行教导优秀敏捷测试实践的角色，并且通常会跨多个团队工作。但这里还存在着一个问题，即这些角色是否只是一些短期的角色，一旦团队及团队实现了完全自治后就没有存在的必要了。等到实现了完全自治之后，这一角色可以选择加入其它团队，转变他的工作角色，或是选择离开。
小编：测试管理在敏捷中的重要性体现在哪里？它能够带来怎样的价值？
Roden 与 Williams：测试管理的价值在于，它能够让团队在越来越短的产品周期中也能够对产品的质量满怀信心。测试就是对于所选择的解决方案的各种风险的信息评估。在一个非常紧张的时间范围内找到足够的实用信息是一件非常具有挑战的任务，需要考虑并完成多种不同类型与级别的测试。
打个比方，使用一种适当的手工/探索性测试与自动化测试混合的测试方法就不是一个容易得出的结论。需要做的是为团队提供支持，选择适当级别的自动化测试，同时与他们结对设计并执行基于测程（session）的测试主题（charter）。这些工作对于由多个不同工种成员组合的团队向敏捷测试的思想转变带来的帮助是无价的。
除此之外，那些通过测试驱动交付的实践（实例化需求，或行为驱动开发）提升了测试的价值，测试不再仅仅是“确认我们所创建的解决方案是否像预期那样运行”，而是尝试从一开始就“以正确的方式创建正确的产品”。
（比方说）实例化需求教会了我们在创建任何功能之前先清晰地指明：为了要让某个功能通过验收，具体需要完成怎样的功能。这一工具带来的价值在于产生共识、消灭可能会导致返工的含糊之处、以及对于该特性的具体行为的大量细节描述。
能够在整个组织中通过这些方式传授与教导实践，会使测试的价值得到难以置信的放大，因此能够通过最少的工作得到最多的实用信息。
这里所说的只是一些具体的示例，一般而言，测试经理所做的任何工作，只要是能够帮助团队设计适当的测试方案、技能或是实践，都是有益的。而当这些工作能够跨越大量的团队之后，所带来的益处也将持续放大。
小编：在敏捷开发中能够进行怎样的测试管理活动？又由谁来完成它们呢？
Roden 与 Williams：在敏捷环境中，大多数测试管理活动依然需要以某种形式完成，尤其在我们所考虑的是对测试的管理，而不是对测试人员的管理的情况下。但这些活动中有很大一部分的性质、形式以及时间必须作出重大的改变。
我们曾经多次为由20至40个人组成的大型小组进行某种练习，以检验对你所提出的问题人们最常见的答案是什么。参与者要列举出传统测试管理中所有的任务，随后我们要求参与者将每个任务分别放到各个区间内，一个区间标记为“在敏捷中不需要它”，一个标记为“应当由特性开发团队负责”，一个标记为“应当由团队之外的角色负责”。之后我们又加入了一个新的区间，标记为“或许需要团队外部的力量推动”，表示在初始阶段需要某些外部的刺激来支持团队。
练习的结果总是很有趣的，不同的人（或是不同的角色）有不同的意见，这是意料之中的。打个比方，特性开发团队的成员可能会抗议说，测试经理所考虑的某些任务应当由团队之外的角色负责。不过，几乎每一次练习之后，团队的成员们都会意识到，他们必须进行的活动比他们之前所想到的要多出许多。此外还有一些相对新的活动，如果将这些活动完全交给团队负责，那么可能会造成一些从组织的角度来看非常昂贵的决策。
像测试的设计、自动化、执行、维护以及调试等活动基本没有任何争议，它们都划给了“由团队负责”这一区间。而像工具开发、培训、指导、职业规划、预算控制、招聘、评估乃至策略等活动，它们的职责对应就没那么清晰了。
