问题的背景

             无论是日常工作中对流程落地的追踪，还是晋升答辩时，评审们经常喜欢反复追问的问题，大意就是：流程中某个环节落地不好怎么办？这里举一个实际的例子： 项目提测流程中有一个环节，测试人员在类似bugfree的平台上，写一些主流程方面的测试用例，让开发人员在提测前，需要执行这些测试用例，并且全部通过后，才能提测。这本来是一个极其常见的提测流程，但执行中为了防止开发人员不执行测试用例，就立马提测，所以要求其没跑一个测试用例，需要在类似bugfree平台上点击一个按钮(分别可以标注PASS,FAIL)。开发人员具体需要执行2个步骤：

              然而，在实际的项目中，测试人员接到提测后，会发现开发人员把所有自测用例全部标记PASS了，然后测试人员在执行时，却发现是有fail的情况存在。

              于是来了一个流程执行中的常见一问：如何保证开发人员在提测前，确实100%执行了测试人员提供的测试用例，而不是没有执行，只是在类似bugfree平台上做了PASS标记：

从问题原因来分析

         这个问题说白了，就是开发人员不认真执行流程的问题(没有实际执行测试用例，就标记pass的动作了)。这个站在开发人员的角度来说，无外乎几个原因：

• 时间太紧张了，没时间执行测试用例，但又是提测环节中的一个要求，不得不执行。
• 实际执行测试用例了，但可能由于测试用例描述不清等原因导致执行不到位。

        上面两个原因，都是可以理解的，需要测试人员与开发人员充分沟通，了解开发人员对自测的执行程度、时间要求、执行效果等等，并一一针对性解决问题。           

以结果为导向来分析

         这里是说，提测前之所以让开发人员执行测试用例，最终的目标是期望开发人员提交的待测产品，质量相对比较高。那么任何执行层面的问题都可以以这个目标为最终判断标准，而开发人员执行自测的形式可以反复斟酌了。

         还是开头的问题，可以从提交的待测产品质量上来反过来推动开发人员自测：

• 待测产品质量很高。首先这个结果已经达到了推动开发人员自测的目标，因而类似开发人员执行流程过程中的不规范问题，可以再讨论决定，比如可以寻求一些一键自动化自测方法，让开发人员既可以快速自测检查，又最大程度的不分散其过多的时间。
• 待测产品质量一般/比较差。这种结果还未达到推动开发人员自测的目标，因而不妨从这个角度入手，和开发人员一起确定自测执行过程，毕竟高质量的待测产品是测试人员最期望的目标，而具体的落地过程是需要开发人员愿意积极配合执行的行为了。

一切以最终目标为依归

          在任何流程执行不好的时候，都需要重新强调实现最终目标(如：解决问题、提升效率等)，考虑流程的执行成本与产出是否成正比，并区分清楚以下两个问题：

是否流程本身有问题——流程本身确定是大家都积极拥护、并愿意配合执行吗？

是否流程执行有问题——流程执行的每个环节大家都”心甘情愿“赞同，并且时间允许吗？

          谨记：  别因为固守某个流程，而忘记当初为什么出发