在和某个想上敏捷研发管理的客户交流过程中，发现客户存有一种认识，即团队的研发管理模式从传统的管理方式，迈入新的敏捷研发管理的模型，只是研发模型的变更，团队还是同一个团队。角色定义要变化么？很多时候，客户会觉得不用啊，还是原来的开发团队，还是继续做开发，只不过快速响应需求，然后开daily standup meeting就好了。这里其实存有误区。

一个Agile 开发团队，常常可由开发人员、外派测试人员、用户体验设计师等组成。

用户体验设计师的加入，还是比较容易理解的。通过更早的将用户的体验意见向开发团队进行反馈，能促进开发团队在实现产品时，更好的理解产品设计文档。同时，加入的用户体验设计师，在Sprint过程中，还可以对开发团队每日交付的daily release进行必要的客户模拟测试，以持续改进需求。这里提到了用户体验设计师的测试，那Sprint过程中，是否需要其他测试人员的加入呢？加入的人员，又如何管理开发过程中的质量管理呢？

首先，我们说Sprint过程中，需要测试人员加入开发团队。加入的测试人员，来源于测试大本营团队，这些人员我们称之为“流动的QA”。下面是关于“流动的QA”的定义及重要工作。

流动的QA：推荐1-2名测试人员加入开发团队，加入的测试成员主导测试工作，测试结果直接影响剩余工作时间。流动的QA，通常会有2个办公室，一个在QA大本营，一个在开发部门。流动的QA，与Sprint过程有关的重要测试工作包括；

在Sprint开始前，根据分配到Sprint中的Story（需求实现分配的具体实例），来创建生成测试用例。测试用例是需求的具体质量标准。 Sprint过程中，测试人员将设计好的测试用例，紧密地与开发任务相关联 开发和测试合作，完善并创造测试用例，达成有质量保证的开发结果 在Sprint中，需求以Story的形式分配到Sprint中。Story通常包含一组已分类的开发任务。TechExcel 的DevSuite工具为我们展现了Sprint、Story和开发任务的层次结构。

通过Story，我们可以很容易的找到基于需求，创建生成的具体测试用例。然后我们来看，测试人员如何将设计好的测试用例，紧密地与开发任务相关联，从而指导具体的测试过程呢？通过下面这张图，我们可以直观的看到相互间的关联关系。

在TechExcel的DevSuite产品中，通过QA Test Co-owner Event ，很好的表达了这样的关系。

QATest Co-owner Event是一种QA测试协同子任务，它作为开发任务的一部分而存在，是一种具体的测试任务单。每个QA Test Co-owner Event可以将测试用例与开发任务相链接，它的描述信息里包含了具体的测试步骤，并且每个QA Test Event有自己的负责人和状态。通过QA Test Co-owner Event，我们可以让敏捷团队遵循需求的质量标准，指导开发过程中的具体产品测试。 QA Test Event的测试结果，直接影响开发任务的剩余时间。

继续来看“开发和测试合作，完善并创造测试用例，达成有质量保证的开发结果”。如何来理解“Sprint过程中……完善并创造测试用例……”？

敏捷开发中，质量的管理常常遇到以下的情况。

Product Owner常常问：“测试用例能在Sprint开始前，能基于需求定义完整的测试用例么？”

QA Leader：主要根据需求的颗粒度，需求表达的完整，细致，则在Sprint前定义完整测试用例的可能性越高。从而更好的将测试用例，用于开发任务的具体测试指导。在开发完成后，达成有质量保证的开发结果。

Product Owner再问：但往往需求总是在变化，而且很多时候，需求无法一次性完整表达，需要随着开发的进展，从而让敏捷过程的所有参与者，来不断理解需求的表达。那这种情况下，是否意味着开发任务的测试指导是存在不够全面的。因为确实很难在Sprint开始的时候，就完整定义表达所有的测试用例？

QA Leader：这个，我们会尽量在测试部门增加测试每日例会，随着需求原型开发的进度，不断让测试部门在测试空间，创建维护新的测试用例。并重新将测试用例通过QA Test Event关联到开发任务。

Product Owner继续问：开发团队如果在实际开发过程中有新的测试点发现，我们如何管理这部分“过程智慧”，完善测试用例？

QA Leader：这个一般让开发团队告诉测试人员，再由测试人员到“测试空间”进行维护操作，再关联到开发任务。

Product Owner：虽然可行，但总觉得很繁琐，也不够好，很容易习惯性的丢失这部分的过程智慧。

QA Leader：…… ……

如果您的团队也遭遇了相同的场景，该如何改进原有的过程呢？而现实的敏捷开发项目中，确实存在开发过程中，开发和测试一起执行测试的时候，除了引用定义好的测试用例以外，还存在不断完善并创造新的测试用例的过程；e.g. 当发现了一个BUG的时候，应该立即为这个BUG增加一个测试用例。

TechExcel的DevSuite92系列，很好的回答了这个疑惑。通过QA 测试协同子任务

为开发任务，关联已存在的测试用例； 完善并创造新的测试用例

通过以上的介绍，我们对一个敏捷开发团队的人员组成，有了新的认识。同时Sprint过程，介绍了开发、需求与质量如何进行整合，并通过具体管理工具的场景落地，加深了效果。

那在敏捷开发团队中，包含了流动的QA角色，是否就完成了敏捷开发与质量管理的完全整合呢？在文章的最后，我们留一个小小的疑问。是否需要对Sprint，进行质量管理的扩展呢？以下哪些观点是正确的

好的Sprint开发过程应当保证产品完全没有缺陷 缺陷在Sprint开发过程中应当被发现 缺陷在Sprint开发过程结束后被发现 缺陷应只分配到以后的Sprint中加以修复 缺陷应当在当前Sprint中全部被修复 缺陷应该尽快被修复 欢迎大家提出新的想法。