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