软件测试过程改进宣言
提到“过程改进”，不同的人有不同的声音。有些人会说：“过程改进很有用，我们得到很好的改进结果”。 也有很多人会抱怨：“过程改进没什么用，都是些务虚的东西，而且特别浪费时间。 我们需要的是‘敏捷’”。虽然研究测试过程改进模型有一段时间了，也很肯定过程改进模型能够帮助企业/组织得到能力提升；但一直没能领会测试过程改进的精神，将过程改进模型切实地运用到实际的测试过程改进中去。近看到一篇关于测试过程改进的文章，感觉不错。在这里和大家分享一下作者在文章提出的“测试过程改进宣言”。
灵活性高于详细过程
过程是一种手段，通过该手段可以把人、规范、方法、设备以及使用工具进行集成，以产生一种所期望的结果。一般企业/组织都会定义所应用的过程，以支持企业/组织有效的运行。这些过程可以帮助并指导员工很好地在企业/组织中工作，然而，太过严格的过程定义也会抹去员工应有的价值。 我们想要的测试人员是有能力面对问题、处理问题、感知问题、挑战问题。支持过程是必要的，但在运用过程中，要讲究灵活性，为测试人员提供足够的自由度，让他们独立思考，找出好/合适的方式前进。我们需要的是“Just Enough Process”。
佳实践高于模板
模板固然很好，但更好的是要学会如何使用模板。想一想，一个测试计划模板和三个测试计划佳实践，哪一个对我们的帮助更大？我想大多数测试人员都会选择后者。因此，当我们在进行测试过程改进时要把重点放在佳实践库的建设上，而不是过度定义模板。不用去担心整理的佳实践是否是业界好的，只要是所在组织好的，并不断地维护和更新ok了。这正是支持测试工作，改进测试过程所要做的工作。
部署导向高于过程导向
建立过程方法是较容易的事情，我们有很多的过程方法可以参考；然而如何落实这些过程方法，从而改变测试人员的行为才是困难的。过程改进所有的内容都与变更管理有关。很多测试改进计划把重点都放在了测试过程的定义上。然而，一个成功的过程改进项目至少应该将70%的精力用在改进部署上 – 做到“真正落实”，过程定义在整个测试过程改进中只占很小的百分比。
评审高于部门质量保证
沟通与反馈是项目成功的必要因素，其实这是同行评审所要做的内容。原则上部门QA是负责评估文档并反馈建议给工程师的。然而，很多QA对测试行业知识了解甚少，他们的反馈都是基于模板及已定义过程的形式化建议，对项目帮助很小（声明这里无意要冒犯那些工作做得好的QA）。也有很多组织是采用同行评审的方式，一个测试计划，一个或两个同行测试经理，他们的反馈都是关于测试计划内容及测试方法的。
这才是我们想要的——真正意义的反馈。
业务驱动高于模型驱动
无论你做什么，请确保你了解你为什么要做它。你要尝试解决什么样的商业/业务问题？组织管理的测试策略是什么？不去了解商业/业务背景，而盲目地去追求目标迟早都会遭受失败。我们常常会发现，过程模型中的某个实践是可以以不同的方式去履行的。了解商业/业务问题（产品质量低，测试执行时间长，成本高等），它会告诉我们如何去选择。我们要依据商业/业务驱动及测试策略不断地评估调整过程改进的内容。
以上便是对测试过程改进宣言的解释，希望大家可以将这份宣言带到你的测试过程改进工作中去，同时也相信只要正确地领悟并运用这份宣言，你会在实践中得到好的结果。
