确保团队执行“足够的”测试覆盖面是非常困难的，尤其是对敏捷开发团队来说。对于初学者而言，一个开发Sprint中要完成多少的质量保证工作才够呢？我们知道，敏捷的标准是在开发Sprint结束的时候要完成一个可交付的产品。那么这是什么意思呢？这意味着软件不能有严重的商业缺陷，不会丢失数据，不会奔溃，同时没有功能性缺陷阻碍基本功能的使用。虽然这个标准提供了一个很好的指引，但大部分敏捷团队实际中都对这个标准做了或多或少的限制。我们提供以下6个技巧，帮助确保你执行“足够的”测试。

1. 为开发Sprint设定一个终端用户可以接受的质量标准，并且这个标准对于团队是可管理的。有时候，所谓“可接受”意味着你需要交付一个 Alpha/Beta质量水平的软件。软件本身可能含有缺陷，但如果终端用户得到了足够的功能，那么它仍然可能是可接受的。其他情况下，终端用户则可能会 要求交付一个如“防弹衣”一样可靠的软件。所以根据用户的需求来调整你的计划。
2. 考虑将开发过程划分包含开发Sprint 和发布Sprint。然后设定相应的质量标准。开发Sprint 中主要关注对新功能的开发实现；发布Sprint 则主要关注缺陷的修复，从而使软件满足发布的质量要求。
3. 为开发任务和Story 引入工作流程。流程中设定含有 “QA审查” 状态，在开发任务或Story 进入到完成状态前，必须经过“QA审查” 这个状态，并完成必要的工作。这个状态的使用将确保每个开发工作都得到适量的QA测试。
4. 为开发任务设定可以通过 “QA评审” 的质量标准，并坚持按照标准来执行。不要让截至日期马上就要到来了，成为轻松绕过QA测试过程的借口。不要担心进度往回赶，必要的时候甚至可以授权QA测试人员有权利停止发布。此外，开发人员和测试人员应当共同负责验证测试用例和测试结果。
5. 让负责Story 或开发任务的开发人员为QA团队演示他们完成的工作，并示范他/她是如何根据定义的QA测试用例，完成的测试。当基本功能验证通过后，QA团队应进一步对完成的开发工作进行测试。
6. Sprint 周期内的QA验证测试和QA回归测试是有所区别的。Sprint 周期内，敏捷团队的首要职责是完成有质量保证的开发任务。很多时候，即使定义了最高等级的质量标准，Sprint 开发完成后的产品仍有可能存在缺陷。尤其是当新的功能可能会对系统的其他部分产生影响的时候。这也是为什么在开发Sprint 周期外，需要进行回归测试以保证整体质量。