基于DAD方法的IBM敏捷开发过程中的敏捷管理(2)

　　为了减少测试工具Z将无法有效地执行应用程序的回归测试的风险，我们将在即将到来的迭代中使用它。

　　风险评估实际上是一个持续的过程，而不是一个只发生在特定的时间的过程。至少，你应该在迭代或一个里程碑抵达时评估风险。重新聚焦迭代目标时重新评估风险，尤其是:

　　消除掉已经完全缓释、不在存在的风险

　　寻找、发现那些新近引入的风险

　　重新评估的风险值和重新排列的风险列表

　　如果可能的话，请每周都重新审视你的风险清单，看看他们都发生了什么变化。让最靠前的十大风险可以在整个项目过程中保持足够的曝光度、可见度，并坚持采取、执行风险应对的计划和行动。通常，你应该将风险状态评估报告附加到你的周报、月报(如果有)的简报中去。

　　监控和管理测试(Monitor& Control Test) - 既然是敏捷方法，为什么还需要监控和管理呢?我前面说过，在企业环境适当的纪律和度量是有帮助的。就如我们所看到的DAD方法中，构建迭代的质量管理和测试工作经由核心团队和独立测试团队负责，而且显然在不同时期(迭代、软件生命周期的不同阶段)均有不同的测试关注点。为了使得测试工作条理清晰、资源充分利用、团队目标的适时调整需要从全局测试的角度基于规划;为了在测试工作中赢得宝贵时间和准确的调整测试策略，我们需要对测试工作进行监控和管理。

　　测试工作量的监控 – 这个任务的重点是对于测试工作的进展状态、测试工作工作量、测试状态监控，以提高测试有效性为目的适时调整。应该评估你的工作是否是适当的质量，而且它是完全够用，且后续将利用它作为质量评价工作。如果可能的话，使用检查表，以验证质量和完整性是否足够好。

　　图3. 随时更新的测试进展状态报告

　　寻找积极的迹象，如发现缺陷的稳定，持续率，或随着时间的推移持续增加或减少的规律。寻找尖锐波峰和波谷的出现点，这表明测试团队可能会遇到的政治、过程、协作方面的压力，我们需要适时给出支持和问题的解决方案。

　　看看缺陷闭合的趋势。确定当下情况这里有没有测试关闭待验证不足的问题，或者开发修复问题不充分性的问题。量化和分析， 因为开发者标记缺陷为“不可再现(Notreproducible)”来关闭问题的趋势，和分析问题的严重程度。分析缺陷因为“代码按设计工作 (work as design)”被开发者关闭的数量和趋势等。请注意，在这些问题凸显的时候，关注是否因为过度的开发工作量、或者因为害怕审查他们的工作而采取的行动所致。您也应该分析的缺陷确认趋势，分析修复缺陷又再次引入新缺陷至后续版本中的问题。总而言之，从趋势分析可以得到发现团队工作效率降低、个别队员超负荷工作和藉此改善团队协同的机会。

　　测试覆盖范围监控 – 这个任务的重点是对于迭代、版本测试工作的覆盖范围、测试组织充分的监控;以及判断跨迭代的独立测试团队与迭代内团队自主测试的配合是否恰好充分，测试的增量计划是否满足了增量型开发持续增长的需求。

　　测试覆盖有功能点覆盖、也有配置和测试环境的覆盖，有效的了解测试的覆盖程度需要类如RQM(Rational Quality Manager)这样的工具，帮助设计测试覆盖规划，以及监控测试实际覆盖状况。

　　图3. 设计最佳的覆盖面和最高效的执行路径

　　将度量测试覆盖率的公式集成如工具，例如RQM，RTC，可以回答“测试完成了%多少?多少设计的测试案列还没有被测试过?多少需求和功能点还未和相应的计测试用例关联?”最为常用的测试覆盖度量矩阵是“单元测试的代码覆盖率”。.

　　任何有计划的测试任务至少基于描述过的一个测试覆盖策略。覆盖策略指导着测试者的测试用例设计。基于需求的测试覆盖率可能已足以产生测试完整性的量化评定了。例如，如果所有的性能测试的要求已被确定，然后所有测试执行的结构可以关联需求，则很可能得到性能测试要求的75%已被验证的结论。

　　类似的，如果基于代码的覆盖技术被应用。这种类型的测试覆盖率就可能足以说明系统的白盒测试覆盖率，这也是目前大多数企业和企业所认可的。

　　这两种测试覆盖的策略可能需要人为干预，而最佳的方式我认为是通过系统自动化抽取数据形成报告，尽量避免引入人为因素最为科学。

　　测试工作个人仪表 – 个人仪表盘首要的工作是让个人在工作中以最小的代价了解自己的工作进展、合理安排自己的工作。个人仪表盘的是以人为本、团队自我管理的初衷来设计的，将质量和测试监控的度量指标和个人仪表盘的视图规则联系起来，个人就能够更有纪律的完成自己的工作，配合团队和项目的整体进度。每个人也非常清楚自己工作对整体所产生的影响，了解自身的价值，帮助建立自我认同感。

　　图3. 测试者根据团队规则和个人意愿设计的个人仪表盘

原文转自：http://www.ltesting.net