九、版本控制
在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。
十、自动测试
产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。
十一、小结：应用推广思路与体会
整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。
测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。