通过将持续集成引入到开发周期中，项目经理有可能可以减少软件缺陷和开发周期时长。然而要想实现这两种好处，需要团队为每一次新提交的代码建立并遵守合适的验收标准。需要由项目经理来确保开发者和测试人员在每次新的开发项目开始时都去收集所需的细节信息。

持续集成是敏捷软件开发方法实践的一部分。它可以改善发布的效能、生产力及可靠性，确保企业以更快的节奏提供更优质的软件。开发者集成代码的频率往往很高，有时候以天记甚至更频繁，而不是在漫长的开发周期结束后才进行。每一次代码提交都会触发一连串基于预设验收标准的自动测试。集成代码生成得越频繁，缺陷就越早暴露。

开发者在将新代码合并进代码库时发现缺陷是很常见的事情。缺陷往往会在新软件提交给软件测试团队之前就被发现和修订。总体而言，软件质量会得到改进，因为缺陷很早就被发现，不会被挂在缺陷报告系统中等待制定优先处理清单或者被最终用户发现。

快速的发布和部署周期未必能改进质量，如果验收规范和测试未加以规划或讨论的话。在一个快节奏的开发环境里，增加更多的测试是件困难的事情，无论测试类型是人工还是自动化都是如此。问题不在于测试的方法，相反，问题往往出在忽略了验收标准的规划。

根据故事制定验收标准提供了一种轻量级的需求，简单、直接，具体，且可测试。细节不会完全提供，因为它们会受基于开发者新发现的变更或设计变更的影响。开发者和测试员需要足够多的细节才能在团队内开始设计讨论以便启动编码和测试规划任务。用户故事的目的是提供这一细节。为每一个故事增加验收标准还确保了质量在开发和测试时仍保持在前列。

开发团队、产品经理及测试员之间的设计沟通能产生出可测试的验收标准。软件测试员可通过鼓励聚焦于含糊的故事描述并建立对测试价值的兴趣来改善开发团队对验收标准的讨论。

通过团队规划实现聚焦客户的验收标准

作为软件测试团队的一员，你应该积极参与所有的规划和设计会议。办法之一是看看已准备好的现有的用户故事，然后编写一个包括验收标准在内的测试原型。用可接受的方式提出测试工作流和故事。用电子表格、矩阵或文本建立预期让最终用户遵循的所有工作流的测试场景。要写一段概要，说明测试目的是什么，计划进行哪些类型（单元测试、自动化测试还是人工测试）的测试。测试计划要简明扼要，设置好格式要让团队能够迅速审核。

如果测试员能主动以简单、易用的格式预先做好测试计划，这然后可以为其他团队成员描绘出，测试团队是如何理解这些功能对最终用户所起的作用的。这还会让所有矛盾和误解浮出水面，这样团队就能对此进行讨论，并让测试员成为所有开发阶段的一位积极的参与者而不仅仅是在测试阶段。

测试员进行测试时同样还能影响到代码设计。其目标不仅仅是让代码通过单元测试。真正的测试要做得更多。测试员必须参与并影响开发设计，其方式是为每一个故事进行额外的对话，并为验收标准增加测试计划。

继续关注成功的持续集成之含糊定义处理和测试价值树立。