如果版本开发测试过程中没有流程的约束，会出现什么样的情况？如果不管版本大小、不考虑版本特性强制使用标准流程约束，又会是什么样？我经常听到的抱怨是流程太厚重了，流程导致了版本开发周期变长、成本增加了。可是，如果某个产品抛开流程，它是不是可以运转的很好？这个问题我不知道，我想对于优秀团队来说，可能可以。但是对于大多团队来说，离开流程的约束或者管控，大概率情况下会出现更多的问题，耗费更多的成本。
那么，流程对于我来说有什么作用？为什么我觉得它很重要。
明确各阶段的入口条件、工作内容、出口条件，有据可依
流程最重要的作用是明确了版本开发测试过程中有哪些工作阶段、每个阶段的入口条件、工作内容和出口条件以及版本发布标准。比如需求传递的入口条件、版本转测试的入口条件。
对测试来说，流程是一把利器，合理利用流程，有助于提高测试工作效率。举例来说，利用流程中版本转测试入口条件，要求开发自测试达到某种标准，要求开发提供版本影响分析指导测试、要求开发已全部修复已知缺陷等。这样，一定程度上提高了版本转测试质量，确保测试有更多的时间用在复杂特性的测试，避免把时间浪费在低级bug上。
对版本来说，利用流程，可以减少人为因素造成的缺陷遗漏到现场。比如要求版本归档后必须提交到配置库（提交后不可以修改），测试从配置库上取包。避免非最终测试版本（无已知缺陷）发布到现场。按照版本发布checklist检查版本，避免漏测等问题出现。
流程是阻塞问题的推动器
在版本开发测试过程中经常会碰到一些需要急需推动的问题。某些时候测试去推动一些问题比较吃力还不讨好。这时就可以让流程去说话，去推动。比如问题单的修复、走单过程中会由于某些原因导致问题单在开发环境而没有走到测试手中，而测试在第二轮次测试中首要的问题就是回归问题单，每次转测后都会出现测试追着开发让转测。其实完全没必要。因为转测试的入口条件之一就是问题单开发自验证完成走到待回归状态，测试经理只需要跟项目经理简单说明入口条件就自会去催促。因为谁也不会去轻易去承担版本延迟的责任。
流程是问题争论的工具
想法设法利用流程去说话，去推动问题。问题有争论或者阻塞时，需要清楚流程的要求。问题出现阶段、问题阻塞在哪里、该阶段的责任人是谁，讲清楚这些，上面自会清楚问题该是谁取主导解决。
流程是say no的工具
很多时候我们对于一件事情不知道该拒绝还是该接受，这种情况下通常很多人都是选择接受，因为他不知道拒绝的理由。如果他知道自己的职责、知道流程的要求，他就可以理直气壮的say no say yes。