|
第四周我们要结束测试，包括 Confirmative 的测试部分和 Investigative 的测试。在迭代验收之前团队要通力合作解决各种能够解决的问题，保障 Backlog 的如期完成。这里有一个问题值得再次提出来和大家讨论，或许曾在敏捷项目中的许多人也都遇到了，那就是出现了一些质量缺陷没有来得及在迭代退出前完全解决的现象。那是不是说明测试不能够退出呢?笔者的回答是“不”。迭代的验收时间即是迭代退出时间，也是测试团队必须退出的时间。在实施中，我们将这些来不及解决的质量缺陷分成三类，一类是“希望能够解决”的质量缺陷，这部分未解决质量缺陷将要成为新一轮迭代的“将做事宜”，甚至可能作为新一轮迭代的需求做到 Backlog 里。第二部分是“必须解决”，这部分因为直接关系到最基本，最关键的功能，这样的质量缺陷必须被立刻解决，否则就必须承认本次迭代的失败了。第三部分是“不再重要的” 质量缺陷，这部分质量缺陷可以因为技术的不可实现，对客户产生较小的影响或者考虑到不久因为代码重构，这样的问题不在存在的理由，经过团队和 STAKEHOLDER 的批准可以置成“推迟解决”，待日后解决或者定义到产品的版本说明文档中。项目管理者联盟
结束语club.mypm.net
在本文中，我们承接了敏捷测试最佳实践系列文章的第一篇，将前文的敏捷原则融入到敏捷测试的实践活动中来。本文所讲的实践围绕“人”和“过程”两个重点展开，指出敏捷活动的主体仍然是“人”，是“敏捷团队”。笔者给出了一种基于 Scrum 敏捷开发模式下的敏捷测试团队组织结构。接着，讲述了这支团队的敏捷测试“过程”。因实践本身是对原则和方法的具体定制，不同的实施背景，敏捷活动的具体表现形式各异。所以，本文始终倾向于提供给您一个可以借鉴的并已经实施成功的敏捷测试“过程和方法”，并与您分享实践经验。项目管理培训 项目管理者联盟
|
