敏捷是怎样改变测试管理的

Roden 与 Williams ： 我们会半开玩笑的问道，这会成为谁的问题呢？如果我们采取所有管理都是有害的这种强硬的观点，那么从组织的角度来看，我们就要问一问，专门为测试设立一个经理究竟有什么价值？它到底是有用的还是纯属浪费，或者更实际点说，设立这一角色所带来的价值能否超过它所带来的负担（即暂时的浪费），直到最终可以完全撤消这一角色为止？

从某个测试经理的角度来说，如果我们表示这一角色没有继续存在的必要，或者说必要的测试经理角色数量减少了很多，那么长期来看这确实会为成为某种问题。短期来看，问题可能主要在于那些在敏捷环境中工作的测试经理的期望。在严格实践敏捷方法的公司中，至少他们会发现，需要他们所从事的工作的类型与他们在传统软件项目中熟悉的工作类型有着根本性的不同。

Scrum中并没有定义测试经理这一角色，但它也没有定义项目经理的角色，这些职责大部分转交给产品负责人了（似乎他们没有足够的事情要做，一切都可以概括为“负责产品”）。而在实践中，尤其是在大型组织中的大型项目群中，通常会设立项目经理、项目群经理以及项目组合经理，他们将填补这一缺口，并帮助Scrum实现大规模化。

因此，真正要回答的问题是，实践敏捷的组织是否需要在特性开发团队之外设立某个角色，专门从事与测试相关的工作？如果他们确实需要这一角色，那么这一角色究竟是什么？什么时候设立他才是合适的或实用的？他的工作范围及规模又是什么？

Roden 与Williams ：在我们看来，敏捷测试经理这一说法本身就是不恰当的。敏捷团队中的测试人员本身就不需要什么管理，因此“经理”这一职位应当被彻底丢弃。那些团队同样也会承担传统的测试经理一职所承担的很大一部分测试管理责任，注意，测试管理与测试经理是不同的。

我们应当将角色与功能进行分离，这一角色的定义对于许多人来说可能还不够清晰，这或许是对敏捷方法对测试的变更的误解所造成的。团队能够在多大程度上了解这一角色，并有效地开展工作，以及需要多久才能达到这一层次，这是一个有趣的挑战。而对于“敏捷”方法及其混合应用的大量不同的实现方式则是另一个挑战，在这种场景下很难断言某个特定角色的定义。

现在我们了解了这一角色可能遇到的问题，那么我们的观点是：这一角色应当跨多个团队工作，他的功能性体现在对测试进行支持、助理以及教导，同时逐渐增加实践和技术的思考方式以及工具应用技能。关键在于建立正确的测试文化、对人们进行指导教育、并且从实践中证明团队应当如何保证测试对敏捷的支持。

这一角色的工作并非将编写长篇大论的测试策略、繁重的测试计划文档、测试时间表，或是举行长时间的bug分类会议作为每天的工作内容，也不是时时刻刻盯着测试人员，要求他们递交测试进度报告。如果你在敏捷环境中工作时还整天做这些事，那么要么你的工作环境完全不是敏捷的，要么至少你在这个环境中待的时间还不够长。这句话听起来有些严厉，但我是有意这样的。这并不是说传统项目中的测试经理的工作经验对于敏捷方法不起作用，它的实用性确实是存在的，但也会遇到极大的挑战。只是说在“敏捷”背景中，这些事情不应该占据任何人，包括聪明绝顶的测试经理的宝贵时间！！

Roden ：我的职业生涯发展路线差不多就是这样的。虽然我之前从事的是探索性测试及类似于验收测试驱动开发的实践，但我在传统项目中也有许多年的经验。

我有幸协助参与了一些敏捷项目，那些项目在测试上遇到了困境。在经过一段时间的指导工作之后，我发现那些团队需要的不是管理，而是教导。他们需要努力尝试在更短的时间内进行更多的测试，专注于测试正确的任务，并掌握正确的技术，而实现这些需要心态上的巨大转变。因为它主要是关于行为的转变，因此与执行计划、分配任务以及跟踪团队状态等并没有多大关联。实际上，这些行为与团队的授权与自组织的期望效果是完全对立的。

Roden 与Williams ：实现敏捷的一个主要前提是允许团队的自组织及完全跨职能，因此团队之外的每个人的目标都是尽力支持这一目标的实现。由咨询和教练职能来提供这种支持是非常合适的做法。

那些正在实现敏捷测试并开始从事教练工作的测试经理可能已经发现，他们从进行教练工作中所获得的乐趣完全不比其它类型的工作来得少。我们曾经多次亲眼看到许多人担任了各种不同的教练角色。有些人直接转变为Scrum Master或敏捷教练，但他们还是将测试作为专业技能的主要领域。

在测试中还有一些高级角色，他们更倾向于以教练为导向。他们可能不会是责任更大的测试主管之类的角色，而是进行教导优秀敏捷测试实践的角色，并且通常会跨多个团队工作。但这里还存在着一个问题，即这些角色是否只是一些短期的角色，一旦团队及团队实现了完全自治后就没有存在的必要了。等到实现了完全自治之后，这一角色可以选择加入其它团队，转变他的工作角色，或是选择离开。

Roden 与 Williams ：测试管理的价值在于，它能够让团队在越来越短的产品周期中也能够对产品的质量满怀信心。测试就是对于所选择的解决方案的各种风险的信息评估。在一个非常紧张的时间范围内找到足够的实用信息是一件非常具有挑战的任务，需要考虑并完成多种不同类型与级别的测试。

打个比方，使用一种适当的手工/探索性测试与自动化测试混合的测试方法就不是一个容易得出的结论。需要做的是为团队提供支持，选择适当级别的自动化测试，同时与他们结对设计并执行基于测程（session）的测试主题（charter）。这些工作对于由多个不同工种成员组合的团队向敏捷测试的思想转变带来的帮助是无价的。

除此之外，那些通过测试驱动交付的实践（实例化需求，或行为驱动开发）提升了测试的价值，测试不再仅仅是“确认我们所创建的解决方案是否像预期那样运行”，而是尝试从一开始就“以正确的方式创建正确的产品”。

（比方说）实例化需求教会了我们在创建任何功能之前先清晰地指明：为了要让某个功能通过验收，具体需要完成怎样的功能。这一工具带来的价值在于产生共识、消灭可能会导致返工的含糊之处、以及对于该特性的具体行为的大量细节描述。

能够在整个组织中通过这些方式传授与教导实践，会使测试的价值得到难以置信的放大，因此能够通过最少的工作得到最多的实用信息。

这里所说的只是一些具体的示例，一般而言，测试经理所做的任何工作，只要是能够帮助团队设计适当的测试方案、技能或是实践，都是有益的。而当这些工作能够跨越大量的团队之后，所带来的益处也将持续放大。

Roden 与 Williams ：在敏捷环境中，大多数测试管理活动依然需要以某种形式完成，尤其在我们所考虑的是对测试的管理，而不是对测试人员的管理的情况下。但这些活动中有很大一部分的性质、形式以及时间必须作出重大的改变。

我们曾经多次为由20至40个人组成的大型小组进行某种练习，以检验对你所提出的问题人们最常见的答案是什么。参与者要列举出传统测试管理中所有的任务，随后我们要求参与者将每个任务分别放到各个区间内，一个区间标记为“在敏捷中不需要它”，一个标记为“应当由特性开发团队负责”，一个标记为“应当由团队之外的角色负责”。之后我们又加入了一个新的区间，标记为“或许需要团队外部的力量推动”，表示在初始阶段需要某些外部的刺激来支持团队。

练习的结果总是很有趣的，不同的人（或是不同的角色）有不同的意见，这是意料之中的。打个比方，特性开发团队的成员可能会抗议说，测试经理所考虑的某些任务应当由团队之外的角色负责。不过，几乎每一次练习之后，团队的成员们都会意识到，他们必须进行的活动比他们之前所想到的要多出许多。此外还有一些相对新的活动，如果将这些活动完全交给团队负责，那么可能会造成一些从组织的角度来看非常昂贵的决策。

像测试的设计、自动化、执行、维护以及调试等活动基本没有任何争议，它们都划给了“由团队负责”这一区间。而像工具开发、培训、指导、职业规划、预算控制、招聘、评估乃至策略等活动，它们的职责对应就没那么清晰了。

Roden 与Williams ：通常具有更高自治性的团队会开始掌控并探索各种选择，例如选择最适合的工具，以及开展培训等等。能够做到这一点是件很好的事。

不过，如果我们的规模达到了一定程度，在一个部门或组织内，对一个单一团队及其环境进行局部优化，而以其它资源作为代价，那么这种权衡或许并不公平。因此，如果我们最终打造了上千种不同的工具以及技术，需要购买大量的授权、进行繁重的版本管理、并且最重要的是要让我们的技能跟上需要，这种结果对于整个组织来说并不一定是个明智的选择。

某些中央化的决策对于组织整体来说是有益的，尤其是专注于某些能够为全体人员提供良好服务的决策，同时允许某些例外的情况，只要这些例外情况能够证明它符合组织的规范，并且能够为某些情况做出一些灵活的变通。我们的意思是，不要强制让每个人都去使用完全相同的工具，仅仅因为他的工作内容看起来具有一定的相似性。如果确实存在一些符合规定的理由，那么应当考虑允许存在一些不同的方式。但要基于它们在经济效益方面的理由允许这种区别的存在，而不是基于收藏癖综合征（magpie syndrome）的理由（意即按照个人的理想追逐新的、酷炫的技术）。

Roden 与Williams ：首先需要说明的是，当我们提到测试策略的时候，我们所指的是在某个特定背景下，某个特定团队或部门所长期采用的测试方法。这种策略涵盖了他们的原则、流程、设计和实现的方法，并且实现了多种不同类型与技术的测试、自动化、风险覆盖、查看质量以及类似的行为。

在过去，测试策略经常会表现为长篇大论的文档，以表现出某位测试经理对于测试以及产品的全部知识。在测试策略编写完成之后一段时间之内，它们会一直摆在那边供人翻阅。而不久之后就会被放到书架上，随后就被人彻底遗忘。

即使是文档化的测试策略，在敏捷团队中还是有用武之地的。通常需要对测试有非常广泛与深入的知识，才能驱动良好的行为，而这通常是属于测试经理的领域。这里的诀窍在于，要将测试策略作为一种活动的文档，它是活动的、保鲜的、并且随着团队以及使用它们的人一起成长的。这就意味着要保持测试策略的简明、实用、适用，并且以某种格式和媒介进行编写，它鼓励经常人们经常使用它，并且在工作内容变动时对其进行扩展与修正。

这方面的一个示例是下面所显示的敏捷测试原则。这里是一组传送我们的测试思想的原则集，它们具有足够的通用性，能够在多个团队中进行应用，并且能够对底层的细节进行调整，以适应每个团队的背景。

Roden 与Williams ：上面的原则是由一个简单的测试策略演变而来的，它基本上是由一些核心团队对工作的思考结果，以及我们的测试自动化框架中的一些wiki页面与文档扩展而来的。通过采取某种轻量级的策略，团队只需进行几个小时的沟通就能够达成一致，然后将它作为一个活动的文档进行演变。

举例来说，我们所合作过的一个团队采用了一些简单的原则，例如完成就意味着通过验收测试、实行集体体测试自主权，以及采用经验测度（empirical measurements）。该团队对基准线的回归测试工作量、生产环境中的bug数量以及生产力进行衡量，以及参考一些无形的指标，例如项目干系人的信心。该团队的文化鼓励他们拥有整个交付流的自主权，因此他们所采取的策略中所体现的原则带来了意义深远的结果。

对UI进行自动化、以一种通用的领域语言进行表达（BDD）、对这些指标的变化进行衡量，并且让每个人都对添加与维护测试集负责，这些做法产生了深远的影响。随着时间的推移，不断有新的因素加入整个策略，例如结对、测试设计原则、使用实例化需求方式达到更好的协作式用户故事的沟通。因此团队的理解与学术知识都得到了成长，并且保持实践的活动性与保鲜度。而在许多测试策略中都忽略了这些内容。

以下是这个项目的实证数据，该项目的第一次发布（比起原计划的八个月时间推迟了两个月）中包含了150多个bug，繁重的回归测试成本也在提高。而从第二个周期结束之后，他们采取了一种敏捷测试实践，你可以清楚地看到这一行为所带来的影响：

Roden 与Williams ：对于那些打算改变现状，选择进入敏捷环境的测试经理来说（如今我们问及这个问题时，做出这一选择的数量占据了压倒性的领先），他们需要了解几件事。在测试管理中获得的一些技能，例如对于不同的人以不同的方式进行信息交流，可能会导致他们逐渐转向教练或Scrum Master的角色，而远离某个特定的、专职的测试角色。

为了支持团队通过敏捷测试取得成功，测试经理需要学习大量的不同知识。虽然这些技能是关于测试的，但对于简洁的资讯提供与风险管理的需求也仍然存在，而对于它们的应用方式可以是千差万别的。

测试经理需要花上一段时间以理解哪些活动依然是有价值的，以及如何支持特性开发团队拥有某些活动的自主权（可以设立专职的测试人员，也可以不设立）。这能够帮助测试经理避免某些陷阱，即长时间地抓住某些不必要的任务不放手，或是某些会抑制敏捷团队的独立与自组织性的东西。

找到那些团队需要支持，以及需要专业知识辅助的活动，并设法让团队学习并提高他们的技能。通过这些工作，那些最成功的测试经理能够转变为更实用的组织变更代理人以及推动者。