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天。还有一个额外的好处，每个团队都有一个预先了解产品的成员。因此其他成员可以在他们的快速学习中受益。

第一天，Scrum团队负责已知问题直到QA团队发布了第一个bug。此外，两名探索性测试员能够在他们的测试中发现一些有趣的可能会转变为可再生bug的地方。两天后，第一个bug和问题修复好了。测试集的下一次迭代中对它们进行了再次测试和其他改进（主要是QA团队发起的）。每日Scrum中，QA团队的代理报告了他们团队的进步并按计划给QA团队带去了重要的信息。每次迭代后，两个QA团队的迭代持续时间各不相同。因此我们让快的团队重新测试我们已经修复并且在几次迭代前重新测试过的老bug。因为团队找到了一些（明显修复后重新安装的）老的错误，所以这个想法奏效了。

总结

QA迭代对于项目来说是一大成功。迭代的最后一天，PO 能够成功进行验收测试并发布产品。这轮QA迭代的结果是团队成功地大大改进了产品的质量。Scrum团队和QA团队了解团队合作的本质。QA团队受益于明确的接口，因为无论他们需要什么他们都能心平气和。无需花大量时间寻找正确的联系人，QA团队的任何问题就可以快速有效地得到回答。另一方面，因为团队间的这个接口，Scrum团队的成员大大减轻了他们的工作量。这样，QA团队只给他们相关的修订的信息，他们就可以专注于他们的工作。但是，我们低估了创建好的测试计划的最初版本以及在我们将bug提交给Scrum团队前过滤、评估、修改bug所需要的精力。但是我们仍设法解决这个问题，因为我们可以依靠QA团队，我们知道：在Scrum 团队中我们可以推迟重新测试，因为QA团队已经做好了。一切按计划进行的事对我们的PO（思想开明且有QA背景的人）都是一大称赞。她乐于接受任何建议和意见。在其他项目中，这个概念都必将需要和PO及其他利益相关者多多协商。此外，我们可以受益于向QA团队中支持我们的有才且积极的同事求助的能力。最后，我可以说：项目中的QA现在正稳步发展，产品也成功在市场上建好了。目前，有大量很好的可以在连续集成中进行的自动化测试。该QA迭代肯定对项目的成功产生了重要影响
版权声明：本文出自 SPASVO泽众软件测试网：http://www.spasvo.com/news/html/2015109143035.html

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。