独立的测试执行--带来一环不必要的风险

   公司的测试执行作为一个单独的步骤已经开始推广了 ，上个星期我的测试案例大都让执行人员来执行了，但测试执行的结果却让我大跌眼镜。我随便挑了几个执行通过案例来看，查了一下系统数据记录，我需要看到的数据都没有产生，不放心阿，那这是什么原因呢？

  有的其实很明显就可以看到是执行人员从中偷懒了。而有的呢，经与他们沟通后发现他们没有看清楚的我的案例或是没有理解案例所要求的操作意思。对于前两者我能说什么呢？我只能说测试执行一给测试带来一环不必要的风险了。而对于后者，我得改进，但如何改进呢？

  那就得改进案例使得无歧义了，可这个难度可大了。即使是一篇研究报告可能都会存在歧义的，更何况我们编写案例的时候只是在寻找如何用案例来验证需求程序，没有那么多精力去咬文嚼字啊或去考虑更多的执行人员到时候会怎么理解自己的案例了。

  其实我个人认为，只要对系统稍了解的人员都应该比较容易理解我的操作要求了，只是公司领导对执行人员的要求和理解就是像一部机器那样，按照设定好步骤来执行，他们不需要了解系统。可这真的可行吗？也许可以，那就是要求我们这些编写案例的人员需要写清楚点击哪个菜单，哪个按钮了。但我们没有精力放在这些操作上阿，我们也没有必要把精力放在这些无聊的操作上阿。测试的目的是什么？ 不就是为了发现更多的缺陷吗？

  也许公司推行测试需求分析、测试案例设计、测试执行分别独立的测试流程对于管理上是比较好的，但对于系统的改善是否有好处呢？从改善方面我们就不好说了，因为我们还没看到结果。但却增加了我们的工作量和沟通量（特别是开发人员），目前测试流程各步骤是这样子的：

1、测试需求分析：测试需求分析的人员将需要跟开发和业务需求提出人沟通需求

2、测试案例设计：测试案例设计人员需要跟需求分析人员沟通测试需求，并且需要与开发人员沟通系统程序设计的实现等

3、测试执行：执行人员需要与案例设计人员沟通如何执行；案例设计人员需要去跟踪执行情况，验证缺陷是否是真的存在，还需要与开发沟通缺陷、协助查错等。（当然按照流程的话，案例设计人员可以不管这些事情的，但能放心得下吗？）

  当然，这种场面绝对不是领导们所愿意看到的，特别是执行步骤上，他们的理想状态是没有沟通。不过如果真的如他们所要求的那样--案例说明点击的按钮或菜单，执行人员把所使用的数据保留，也许是可以零沟通的。但我还是怀疑，文字真的可以代替沟通吗？真是难为开发了

  总之啊，如果真的需要做到领导们的那理想状态，测试需求分析人员和案例设置人员都必须要努力地去减少歧义，减少沟通。但实际真的能做到吗？大家追求了那么多年的业务需求清晰性，不也始终在努力中吗？沟通始终都是在所难免，必不可少的。

 也许我们这些下属们站的低，看不到全局吧。希望这样子流程在有得有失中，得大于失吧。