Martin Uhlig在德国德累斯顿的Saxonia系统公司担任测试顾问。自学习商业信息以来，他一直对敏捷软件开发和敏捷方面的当前动向很感兴趣。他做过物流，媒体，和产品开发领域的不同项目。这也包括了他担任测试员和产品所有者的敏捷项目。
　　情况
　　敏捷环境中的开发员和测试员肯定对下列情况很熟悉。一个团队已经进行了很久的工作，但是他们没有专业的测试员。结果，质量要求被忽略了。但是现在——在产品发布前——一切都会变好，团队有额外的测试员支持了。今年年初，我被任命为一个测试员流动量高的Scrum团队的测试员时，我陷入了相似的情况之中。除了开发员已经建立的单元测试，并没有自动化测试。但是随着产品发布的时间越来越近，团队必须做出各种关于产品变化的短期决定。我们不得不用快速可靠的方式找到一个测试产品功能及其非功能准则的方法。为了在项目的这个阶段开始集成测试和UI测试的自动化，我们需要一个手动解决方案。
　　想法
　　与我们的产品所有者（PO）合作，我们创建了一个概念以组织一个只用于测试，修复和再测试的纯粹的质量保证迭代（QA Sprint）。这轮迭代中并没有安排特写。我们该如何在这么短的时间内测试整个产品呢？即使有九名测试成员，也不太可能在两周的迭代内运行测试以达到令人信服且能提供信息的结果。毕竟有必要通过测试覆盖不同的软件配置。但是我们很幸运能得到五名同意支持我们测试的测试员和开发员的特殊帮助。所以我们的人员充足。但是该如何管理所有这些人呢？一开始很明显：团队不能简单地扩充。14个团队成员（加上Scrum专家）没有办法创建一个有效的迭代计划或每日Scrum，且整个团队都必须进行重新组织。这并不是一个有效的解决方案，算只对迭代也一样。这样，我们不得不另想他法集成额外的测试员。但是哪种办法行得通呢？答案很简单——我们需要更多团队！但是一个新的Srum团队不会突然出现，尤其对于一轮迭代来说。因此，我们不得不将Scrum团队和QA团队分开。Scrum团队，由以前的团队组成，应该像平时一样用佳的Scrum团队的方法做基本工作。但是为了加强Scrum团队，我们需要额外的测试员，但是因为上述原因不能让他们加入Scrum团队。因此我们不得不创建两个实质上自己组织但不是SCRUM团队固定一部分的团队。这些QA团队一直重复运行既定的测试集。Scrum团队的测试员完成并迭代改进了测试集。QA团队的工作与Scrum团队的工作被严格分开以避免降低Scrum团队的性能。因此团队需要一个接口来过滤信息的交流，以避免信息泛滥（尤其是只有实际bug，没有重复等）。
　　Scrum团队自身要专心再现并解决bug。我们决定在团队间使用接口。团队分开的例外是每日Scrum会议。除了Scrum团队，每个QA团队的一个代理人给他们的当前状态。改善该计划，这样团队能更好地平衡。Scrum团队的开发员之一去了QA团队和他们一起测试。这样每个QA团队有三个成员，包含一个负责测试执行的经验丰富的测试员。此外，Scrum团队有两个相对而言较新的成员，他们没有充分地训练过，无法快速有效地修复复杂软件的bug。除了测试集和bug再现，这些同事还要进行探索性测试。总之，我们的后计划是：由两个QA团队进行一系列测试。这些测试包括所有的积极的和重要的负面的测试用例。每个团队都要进行不同的产品配置。QA团队的测试是由Scrum团队两名新开发的探索性测试支持的。Scrum团队内的六名开发员处理bug修复和部署。这样，两个团队建好了，他们支持Scrum团队，对Scrum团队的自组织（见图1）没有大的负面影响。偏向开发的开发员和测试员间的非典型性比率不成问题，因为PO有很多待解决的早存在的问题，足够让开发员在报告第一个bug前忙个不停。

　　图1. 两个支持Scrum团队的QA团队。两个团队间的交流由固定接口和代理（蓝色的）负责。

　　实施
　　对于Scrum团队，QA迭代开始时和其他迭代一样，只除了一点：迭代计划比通常要短。迭代计划中PO只呈现了一些已知问题。迭代中，PO和Scrum团队的测试员评估了QA团队发现的bug并按优先顺序将它们加入Scrum的迭代储备中。除了Scrum团队的迭代计划，QA团队还有一个启动会议。它们接到指令运行来自测试集的积极的和消极的测试用例并记录bug。整个测试集执行完（持续时间大约是2天）之后，由团队的印象检查和改进。后，通过再次测试当前版本的bug修复来完成测试集。在这之后，测试集能够在QA团队的下个重复中执行了。这样，两个QA团队每次重复总有相同版本但不同配置的产品了。因为QA团队的每次重复刚装上新的版本，软件的安装和更新机制由PO和Scrum团队的测试员重复测试。为了感谢和激励QA团队，我们使用一些游戏化概念的元素。比如，我们为关键的bug设立一些奖项或为发现了多bug的团队发一些小礼物。启动是QA团队的官方开始。对于测试集的第一个完整的执行，他们需要的正是假定的2天。还有一个额外的好处，每个团队都有一个预先了解产品的成员。因此其他成员可以在他们的快速学习中受益。