当决定改善组织的测试过程时，遵循一套结构化的方法（如业界知名的TPI®或TMMi®测试过程改进模型）是至关重要的。如果仅仅是凭着感觉来做事情几乎肯定会导致浪费精力和金钱的结果。
在已经选择了适合的改进模型的情况下，仅仅照搬模型提供的改进步骤也不一定会带来预期的效果。为了能够实现明确的目标，有一些问题是我们在开始改进的工作之前需要首先思考的。那么，我们真正需要思考的事情究竟有哪些呢？
对业务的贡献
测试过程的改善究竟能给业务带来多大的贡献？以下答案总结了大多数人对此问题的回答：
1、更好的测试能够多少提高一些产品的最终质量，从而带来更好的客户满意度、减少退货量和提高销售额；
2、更好的测试能够多少缩短一些产品开发周期，从而降低项目成本以及有助于更快速的投入市场；或者能够帮助更好的控制产品开发周期；
3、更好的测试能够多少节省一些产品成本，因为总工作量可能会因此降低；
4、更好的测试能够多少使产品符合外部法律的要求，获得新市场准入许可，从而增加销售额；
5、哦！还有这样的说法“适当的测试可以帮助管理者对产品的发布做出客观详实的判断”。
尽管上述原因可能引起了你的共鸣，但是还有一些问题是要进一步考虑的，特别是关于“多少”的真正含义以及一些进一步的假设。不要被美好的言辞所迷惑，我们需要清楚知道更好的测试是否“真正”能够带来更好的产品质量和更高的客户满意度。
第一点：
测试本身并不能改善任何东西。只有当有效的测试作为产品改进周期的一部分时，并在进行了根本原因分析，开发人员的设计、编码能力提高后，测试才真正能够改善产品质量。
测试的确可以提高客户的满意度，但是这是在真正了解客户的关注点并对那些部分进行测试的情况下。对客户几乎不感兴趣的部分下大力气进行改进是值得称赞的，但这并不会在多大程度上提高他们对产品的好感度！如果你想要提高客户满意度（你知道如何让他们满意吗？你真的知道客户对你产品的期望以及他们如何使用它们吗？），你最好首先了解他们如何使用你的产品，客户有哪些不满，以及实际使用中哪些问题应归为“产品故障”。
当然，在开发组织中的测试活动是绝对必要的，而且要确保对测试结果进行分析并尽早解决缺陷。
第二点：
众所周知，同一个缺陷，其发现的阶段越晚则修正它付出的代价越高。在开发生命周期后期阶段（或开发完成后）的活动中发现的缺陷的修复代价远远大于在开发生命周期早期阶段的活动，如审查、单元测试等发现的缺陷的修复代价。因此，在早期阶段便开始查找缺陷的工作显然是一个好主意。但是……你是否清楚在哪个阶段进行测试活动最有效吗？应该从哪里入手呢？是建立高质量的需求？使需求和测试用例有更好的可跟踪性？提高设计能力？提高代码审查质量？改善单元测试？改善集成测试？改善功能测试？改善可靠性测试？引入测试自动化？提高代码质量（内存泄漏、过多消耗处理器性能和其他资源使用等）？还是改善可用性测试？
除非真的很无聊，否则几乎不可能在同一时间改善所有这些活动。并且对于每个提到的活动，所在的组织必须要具备或学习相应的技能，并且还需要有机会在组织中实施它们。仅花费时间学习而缺少实践几乎不能带来很好的效果；通常你可以使用一个产品开发项目作为引入新技能的载体。通常一项新技能的“学习”和应用于实践的时间间隔不应太长，否则只能是白白的浪费时间。
制定改进策略的小技巧：为改进计划制定小的改善步骤，使其能很快的看到效果。而且实践中总是有一些超乎想象的细节性困难。创建单元测试用例来引入单元测试？没问题，但是触碰遗留代码时，却发现由于软件结构设计时根本没有把测试纳入考虑，单元测试基本不可能实现。改善评审过程？也没问题，但是你却发现你处在一种比较含蓄的企业文化中，人们更愿意承担产品质量较低的风险而不愿意破坏彼此的感情。你你认为只是改善一下评审技巧，却发现你你需要改变的是整个文化氛围和思维方式。
因此，我们得出的教训是，在引入改进方案之前，应该为组织进行FMEA（失效模式影响分析）。要弄清楚希望从哪个方面入手进行改进，为什么是这个方面；并且考虑所有可能失败的因素，正视并解决这些问题。
第三点：
从及早发现缺陷能够节省稍后返工的角度来看，这点是正确的。然而，这个观点正确的前提是，必须对可能发生的情况作出妥善的规划。如果没有投入足够精力对测试过程改进进行整体细致规划的话，那么在实际的改进过程中，你会发现遇到了大量从未预想过的问题。这个时候，你不应该放弃，而是要坚持分析预期和实际结果的差异以及为什么出现这样的差异。顺便说一下：你是否考虑过采取措施对测试过程改进的结果进行度量，以此得到管理层的认可？
第四点：
如果一些立法机构对你的产品销售至关重要，例如FDA（食品和药物管理局），那么只有一条建议：请确保你满足他们的要求。以明智的方式去处理。必要的话聘请一位了解其规则和条例的专家，并满足他们的要求。
