进行测试改善时要思考的关键问题.docx

进行测试过程改进需要思考的关键问题SRC 刘宇旸（原文：Key Questions to ask when improving testing）当决定改善组织的测试过程时，遵循一套结构化的方法（如业界知名的TPI或TMMi测试过程改进模型）是至关重要的。如果仅仅是凭着感觉来做事情几乎肯定会导致浪费精力和金钱的结果。在已经选择了适合的改进模型的情况下，仅仅照搬模型提供的改进步骤也不一定会带来预期的效果。为了能够实现明确的目标，有一些问题是我们在开始改进的工作之前需要首先思考的。那么，我们真正需要思考的事情究竟有哪些呢？对业务的贡献测试过程的改善究竟能给业务带来多大的贡献？以下答案总结了大多数人对此问题的回答：1. 更好的测试能够多少提高一些产品的最终质量，从而带来更好的客户满意度、减少退货量和提高销售额；2. 更好的测试能够多少缩短一些产品开发周期，从而降低项目成本以及有助于更快速的投入市场；或者能够帮助更好的控制产品开发周期；3. 更好的测试能够多少节省一些产品成本，因为总工作量可能会因此降低；4. 更好的测试能够多少使产品符合外部法律的要求，获得新市场准入许可，从而增加销售额；5. 哦！还有这样的说法“适当的测试可以帮助管理者对产品的发布做出客观详实的判断”。尽管上述原因可能引起了你的共鸣，但是还有一些问题是要进一步考虑的，特别是关于“多少”的真正含义以及一些进一步的假设。不要被美好的言辞所迷惑，我们需要清楚知道更好的测试是否“真正”能够带来更好的产品质量和更高的客户满意度。 第一点：测试本身并不能改善任何东西。只有当有效的测试作为产品改进周期的一部分时，并在进行了根本原因分析，开发人员的设计、编码能力提高后，测试才真正能够改善产品质量。测试的确可以提高客户的满意度，但是这是在真正了解客户的关注点并对那些部分进行测试的情况下。对客户几乎不感兴趣的部分下大力气进行改进是值得称赞的，但这并不会在多大程度上提高他们对产品的好感度！如果你想要提高客户满意度（你知道如何让他们满意吗？你真的知道客户对你产品的期望以及他们如何使用它们吗？），你最好首先了解他们如何使用你的产品，客户有哪些不满，以及实际使用中哪些问题应归为“产品故障”。当然，在开发组织中的测试活动是绝对必要的，而且要确保对测试结果进行分析并尽早解决缺陷。第二点：众所周知，同一个缺陷，其发现的阶段越晚则修正它付出的代价越高。在开发生命周期后期阶段（或开发完成后）的活动中发现的缺陷的修复代价远远大于在开发生命周期早期阶段的活动，如审查、单元测试等发现的缺陷的修复代价。因此，在早期阶段便开始查找缺陷的工作显然是一个好主意。但是你是否清楚在哪个阶段进行测试活动最有效吗？应该从哪里入手呢？是建立高质量的需求？使需求和测试用例有更好的可跟踪性？提高设计能力？提高代码审查质量？改善单元测试？改善集成测试？改善功能测试？改善可靠性测试？引入测试自动化？提高代码质量（内存泄漏、过多消耗处理器性能和其他资源使用等）？还是改善可用性测试？ 除非真的很无聊，否则几乎不可能在同一时间改善所有这些活动。并且对于每个提到的活动，所在的组织必须要具备或学习相应的技能，并且还需要有机会在组织中实施它们。仅花费时间学习而缺少实践几乎不能带来很好的效果；通常你可以使用一个产品开发项目作为引入新技能的载体。通常一项新技能的“学习”和应用于实践的时间间隔不应太长，否则只能是白白的浪费时间。制定改进策略的小技巧：为改进计划制定小的改善步骤，使其能很快的看到效果。而且实践中总是有一些超乎想象的细节性困难。创建单元测试用例来引入单元测试？没问题，但是触碰遗留代码时，却发现由于软件结构设计时根本没有把测试纳入考虑，单元测试基本不可能实现。改善评审过程？也没问题，但是你却发现你处在一种比较含蓄的企业文化中，人们更愿意承担产品质量较低的风险而不愿意破坏彼此的感情。你你认为只是改善一下评审技巧，却发现你你需要改变的是整个文化氛围和思维方式。因此，我们得出的教训是，在引入改进方案之前，应该为组织进行FMEA（失效模式影响分析）。要弄清楚希望从哪个方面入手进行改进，为什么是这个方面；并且考虑所有可能失败的因素，正视并解决这些问题。第三点：从及早发现缺陷能够节省稍后返工的角度来看，这点是正确的。然而，这个观点正确的前提是，必须对可能发生的情况作出妥善的规划。如果没有投入足够精力对测试过程改进进行整体细致规划的话，那么在实际的改进过程中，你会发现遇到了大量从未预想过的问题。这个时候，你不应该放弃，而是要坚持分析预期和实际结果的差异以及为什么出现这样的差异。顺便说一下：你是否考虑过采取措施对测试过程改进的结果进行度量，以此得到管理层的认可？第四点：如果一些立法机构对你的产品销售至关重要，例如FDA(食品和药物管理局)，那么只有一条建议：请确保你满足他们的要求。以明智的方式去处理。必要的话聘请一位了解其规则和条例的专家，并满足他们的要求。第五点：是的，你可能为你管理层提供更好的信息，但他们会使用这些信息吗？你能够提出与商业相关并引起他们关注的信息吗？找出他们的需要和期望。试着将测试结果关联到商业价值。如果改进的确是必要的，那么弄清楚能够发生什么程度的改变。思考这些问题，并将这些答案作为测试方针的一部分。另外，你打算如何使所有参与的人理解你的想法呢？请注意，尽管你可能为了得到大家的认同而预备了很多知识和实践，然而事实上，你认为是正确的很多事情并不是那么显而易见的。所以，请让自己真正站在你试图说服的人的立场上，了解他们的犹豫，并为他们提供真正有效的答案。目前所处的水平？TPI和TMMi都提供了很棒的问题，来帮助你确定你的组织的成熟度。实施一次专业评估或由内部的专业人员进行评估应该会帮助你认识到目前所处的位置。然而，如果想要通过测试真正提高产品质量，还需要清楚的知道测试对开发生命周期中各个过程的贡献都是怎样的。请记住，从CMMi的角度来看，如果希望测试能够充分发挥它的功效，你需要达到一个相当高的成熟度水平。下面提供了一些有助于成功实施测试过程改善的检查问题：1. 即使你有一个好的测试方针，还需要考虑测试方针能够帮助你对开发组织造成多少影响？你如何实施测试方针？如何确保它被执行？是否要强制执行？为什么？2. 哪些测试度量是能够从组织中得到的？使用工具时能够得到哪些支持？如何培训缺陷分析师？(由谁来担任这一角色?）如何维持员工的积极性，以确保他们填写正确的信息（甚至在几个月之后）？需要进行哪些度量来证明有些改进措施有助于商业目标，而有些无助于？3. 如果你开始自动化测试或单元测试，你如何证明被自动化测试或单元测试提早发现的缺陷的价值？4. 你所在的组织是否已经具备了所需的技能？5. 你是否确认测试工具已经到位了？a) 它们处于什么样的状态？b) 有多少遗留测试件和具备多少测试资产？c) 人们对这些工具的感觉如何？6. 可以真正开始测试了吗？换句话说：对需求的了解程度达到进行测试的要求吗？以我的经验来看，有时需要将一些假想的需求作为测试设计的一部分记录下来。尽管这样做还非常不够，但也比什么都不写只是在大脑里对需求有个认识要强很多。从个人经验来看，在着手进行测试过程改进措施之前，对上述的问题有清晰地认识是很重要的。同时，进行改进时应该选择改进的试点来看一下实践中会发生什么样的问题，而不要期望一下子就能有彻底的改变。做好可能遇到各样从未预料的困难的准备。如何得到干系人的支持？你的许多干系人(知道他们都是谁么？）可能对测试没有太多的了解。他们可能过分高估了自己的知识而低估了建立一个好的测试过程的难度。因此，根据他们能够接受的程度来把问题阐述清楚也是非常重要的。最恰当的方法是找到一些对干系人来说不是很大但又切实可见的一些关注点，并通过初步实施来证明改进的有效性。同时，改进计划也需要得到管理层的支持，不仅从资源分配的角度，而且从方向把握和管理控制的角度。（对于改进计划需要注意的是，改进的目标是什么？是否阐述的清楚明白？是否为改进目标制定了改进路线图？理论上，每一步骤是如何规划的？）如果实在得不到管理层的充分支持，只能说时机尚未成熟。不用沮丧，接受这一现实就好了。设定你的范围当你开始测试过程改进时，很可能会遇到的一种情况是你发现除非测试之外的其他过程先有所改善，否则测试过程不大可能改善。我了解的一个情况是，测试经理被指责测试成本过高，但测试时间增加的根本原因是被测软件质量不足导致安装被测对象时出现困难；然而测试经理没有明确表明他的影响力和责任的范围！因此，要弄清楚职责范围及事实情况，从而避免互相指责与推卸。最好在测试方针中明确阐述工作环境相关的前提假设，以及需要从其他干系人那里得到的支持。（一定要明确入口准则！