前文介绍了成功的持续集成之团队规划实现聚焦客户的验收标准，本文将继续介绍在软件测试时如何处理含糊定义，以及如何树立对测试价值的兴趣。

处理含糊定义

准备规划或设计会议时，至少要提前一天发出测试原型数据并在会上介绍它。做好准备，要对每一个故事的测试计划进行讨论，这样才能影响设计，并以可测试的方式记录验收标准。

如果可能的话，要聚焦测试原型于可受团队控制的具体工作流身上。故事刚刚创作出来的时候，细节往往是含糊不清的。在我的团队里面，不明确本身就会引起讨论。这也是讨论验收标准的重要时刻。大多数开发者对于在软件设计好之前考虑测试或验收标准会有顾虑，但是实际上这是吸引其注意力和获得输入的最有效时刻。没有开发者的输入，想要验证测试计划覆盖了所有的功能是很困难的。

一旦当前的测试数据包含有那类测试，就会开启另一个团队对话。该团队可确定哪一类测试对于每一种功能来说最有价值。如果测试员对测试类型和目标进行了深入思考，就能引领对话，在审核测试目的时吸引必要的开发者参与。这些目标则成为了预期的结果，反过来往往又会变成验收标准。

树立对测试价值的兴趣高的

要想从验收标准中获得明晰性和价值，一个有效的方法是制定原型测试计划。格式没关系，因为它依赖于测试员的喜好以及开发者想阅读什么。确保测试原型简明且有组织。在讨论测试和验收标准时，要想使参与者的讨论离题，再也没有比一份组织紊乱的演示更快的方式了。要精心准备，充满信心地以有条理的方式介绍原型测试计划。如果交流漫无目的，听众也会困惑。

在一个持续集成环境里，测试员需要预先计划，脑子里要有个原型计划去实现来自开发方的最有效的参与。计划要简明、有价值，但首先，要争分夺秒。不要浪费时间，测试员计划测试时要把功能的内容展示出来，并且让团队在讨论时起草验收标准。

主动预先制定测试计划，以简单、易用的格式让测试员和开发团队一起参与。测试员需要积极参与所有开发阶段并通过启动或建立设计讨论来影响设计。以原型的方式将测试想法摆出来。这样可以迅速、直接，并把来自开发的必要输入引进来。测试员成为设计团队的一部分，而团队了得到了有效的基于工作流的验收标准，这提高了软件对的质量并改善了用户体验。