第五点：

　　是的，你可能为你管理层提供更好的信息，但他们会使用这些信息吗？你能够提出与商业相关并引起他们关注的信息吗？找出他们的需要和期望。试着将测试结果关联到商业价值。如果改进的确是必要的，那么弄清楚能够发生什么程度的改变。

　　思考这些问题，并将这些答案作为测试方针的一部分。另外，你打算如何使所有参与的人理解你的想法呢？请注意，尽管你可能为了得到大家的认同而预备了很多知识和实践，然而事实上，你认为是正确的很多事情并不是那么显而易见的。所以，请让自己真正站在你试图说服的人的立场上，了解他们的犹豫，并为他们提供真正有效的答案。

　　目前所处的水平？

　　TPI®和TMMi®都提供了很棒的问题，来帮助你确定你的组织的成熟度。实施一次专业评估或由内部的专业人员进行评估应该会帮助你认识到目前所处的位置。然而，如果想要通过测试真正提高产品质量，还需要清楚的知道测试对开发生命周期中各个过程的贡献都是怎样的。请记住，从CMMi®的角度来看，如果希望测试能够充分发挥它的功效，你需要达到一个相当高的成熟度水平。下面提供了一些有助于成功实施测试过程改善的检查问题：

　　1、即使你有一个好的测试方针，还需要考虑测试方针能够帮助你对开发组织造成多少影响？你如何实施测试方针？如何确保它被执行？是否要强制执行？为什么？

　　2、哪些测试度量是能够从组织中得到的？使用工具时能够得到哪些支持？如何培训缺陷分析师？（由谁来担任这一角色？）如何维持员工的积极性，以确保他们填写正确的信息（甚至在几个月之后）？需要进行哪些度量来证明有些改进措施有助于商业目标，而有些无助于？

　　3、如果你开始自动化测试或单元测试，你如何证明被自动化测试或单元测试提早发现的缺陷的价值？

　　4、你所在的组织是否已经具备了所需的技能？

　　5、你是否确认测试工具已经到位了？

　　a）它们处于什么样的状态？

　　b）有多少遗留测试件和具备多少测试资产？

　　c）人们对这些工具的感觉如何？

　　6、可以真正开始测试了吗？换句话说：对需求的了解程度达到进行测试的要求吗？以我的经验来看，有时需要将一些假想的需求作为测试设计的一部分记录下来。尽管这样做还非常不够，但也比什么都不写只是在大脑里对需求有个认识要强很多。

　　从个人经验来看，在着手进行测试过程改进措施之前，对上述的问题有清晰地认识是很重要的。同时，进行改进时应该选择改进的试点来看一下实践中会发生什么样的问题，而不要期望一下子就能有彻底的改变。做好可能遇到各样从未预料的困难的准备。

　　如何得到干系人的支持？

　　你的许多干系人（知道他们都是谁么？）可能对测试没有太多的了解。他们可能过分高估了自己的知识而低估了建立一个好的测试过程的难度。因此，根据他们能够接受的程度来把问题阐述清楚也是非常重要的。

　　最恰当的方法是找到一些对干系人来说不是很大但又切实可见的一些关注点，并通过初步实施来证明改进的有效性。同时，改进计划也需要得到管理层的支持，不仅从资源分配的角度，而且从方向把握和管理控制的角度。（对于改进计划需要注意的是，改进的目标是什么？是否阐述的清楚明白？是否为改进目标制定了改进路线图？理论上，每一步骤是如何规划的？）

　　如果实在得不到管理层的充分支持，只能说时机尚未成熟。不用沮丧，接受这一现实就好了。

　　设定你的范围

　　当你开始测试过程改进时，很可能会遇到的一种情况是你发现除非测试之外的其他过程先有所改善，否则测试过程不大可能改善。我了解的一个情况是，测试经理被指责测试成本过高，但测试时间增加的根本原因是被测软件质量不足导致安装被测对象时出现困难；然而测试经理没有明确表明他的影响力和责任的范围！因此，要弄清楚职责范围及事实情况，从而避免互相指责与推卸。

　　最好在测试方针中明确阐述工作环境相关的前提假设，以及需要从其他干系人那里得到的支持。（一定要明确入口准则！）

　　跟踪和庆祝

　　现在，你已经设定了目标，制定了测试方针，确定了小步的改善步骤，得到了管理层的支持，也找到了试点。接下来需要做的事情就是，对所有这些小小的步骤进行跟踪，确保对结果进行记录和分享。出乎意料的是，我经常发现即使是优秀的测试人员也不太关注他们取得的成就，更不要说进行分享了……

　　每达到一个里程碑的时候，可以庆祝一下。把成绩展示给改进团队之外的人，并感谢他们在改进过程中给予的帮助。