TMMi项目通常是以软件测试过程改进的TMMi模型为参考，以软件测试过程改进为目的的工程活动。
如何引入测试过程改进，并取得成功？
这是TMMi项目自始至终都应该要关注的一个问题。
根据笔者多年的实践经验和国际软件测试工程师认证体系（ISTQB）专家级大纲的建议，TMMi项目的成功有三个重要的因素，首先是要有一个“成功的开始”，其次是要“踏踏实实的落实”，第三是要有“过程改进的文化氛围”。
一、成功的开始
“成功的开始”主要针对TMMi测试过程改进项目的启动阶段，可与IDEAL改进框架中的“初始(Initiating)”阶段和“诊断断 (Diagnosing)”阶段相结合（参见IDEAL改进框架）。
在这个阶段，需要明确项目目标，获得领导（管理层）的支持，确保项目资源能够得到保障。这个阶段重点的事项具体包括：
·对测试过程改进设置清晰的、可度量的和实现的目标（不是好高骛远的目标）；
·获得管理层的承诺和合适的支持，尤其是获得有“实权“的领导的支持；
·将测试过程改进作为正式的项目来组织，制定合理的过程改进计划；
·确保项目人员有足够的时间参与项目；
·设定的过程改进目标与组织的成熟度相呼应（如果差距太大，目标实现的代价太大和实施周期太长，可能不利于整体的发展）；
·建立测试过程改进的管理方法，包括沟通机制等。
二、踏踏实实的落实
“踏踏实实的落实”主要针对TMMi项目的测试过程改进实施阶段。
改进实施阶段是整个TMMi项目的关键阶段，需要全力以赴的推进。在这个阶段，能促进项目成功的因素包括：
·明确定义出清晰的改进时间跨度，以及反馈周期的长度。
这些时间跨度都不太大，让项目工作能形成一定的节奏，并让项目团队可以保持良好的工作势头。
·每个周期的改进目标都应该是清晰的、可度量的和可实现的。
·明确组织改进过程的所有权。
·对过程进行监督控制管理。
·实施改进中，需要哪些测试专家参与，如何参与，何时参与，等相关事项，需要明确定义。
·当问题出现在测试组织之外时，其他的利益相关者需要参与进来，例如，说明规格的质量、变更和发布管理过程等。
·负面情绪的控制（抵制）和营销执行。
·尽可能使用已有的实践，不为了改变而改变。
如果现有的可用的实践未被使用，首要的事情是调查清楚不使用它的原因，而不是急于去改变或新建。
·稳定的项目团队，协同工作，欢迎变更（而不是抵触）。
·应用支持测试改进的工具。
·选择具有合适知识和技能的人员。
这不仅覆盖了一般的测试，而且覆盖了改进过程的相关部分和所采用的改进方法的使用技能（例如，特定的模型和分析技术）。
·考虑人力因素，如学习方式、性格特点和态度。
·在需要时，可以请外部顾问参与。
例如，外部顾问可以提供特定的知识和技能，但不应该让他们对改进项目负全部责任。
·应意识到那些可能是强制性的外部标准，例如，银保监会对金融机构的要求等。
·整体过程和术语应预先定义，以确定它们在改进策略的各个组件中是一致的，并且属于整体框架的一部分。
·构建与所有受影响的相关者的关系，例如与软件过程改进人员、质量保证人员和人力资源人员。
·清晰的进度展示。
·内部批准，服从组织的监管要求。
·确保与其他改进措施相一致，如CMMI、ISO等。
·开发和测试的成熟度水平保持大致上的步调一致，以避免潜在的过程不一致。
三、过程改进的文化氛围
TMMi项目和过程改进团队作为组织的一部分，要将改进的需要置于公司文化背景之中。例如：
·管理文化（指挥和控制、咨询、团队驱动）将会影响建议的改进策略的可接受度；
·组织所处的地理位置；
·对于改进的目标、策略和战略，以及态度（例如，在组织中是否有正在使用的改进策略或是已经获得成功的策略）；
·各部门间的关系，例如，当两家公司合并时，是否会出现对那些被认为是来自于其他组织的改进过程变更的抵触；
·正在使用的生命周期模型（顺序模型、迭代模型、敏捷模型、非过程模型等）将会影响那些对项目来说是可接受的改进的频率；
·正在使用的测试方法（自动化测试、手工测试、脚本化测试、探索性测试、混合测试、随机测试）将会影响已被提议的改进类型的可接受程度。
[vanVeenendaal]以敏捷宣言为模型，提出了一个测试过程改进宣言，是一个不错的策略。
他在测试过程改进宣言中建议考虑下列五个要点：
“灵活性胜过详细过程”
他建议组织需要应对变化，并且能够处理这些变化带来的风险。
对灵活性的需要，正是对测试工作人员是知识性人员的认知。他们需要思考、适应和应用那些根据项目的具体情况而定的改进。改进过程的灵活性和自由度源于对员工的信任，并能够激励他们主动改进。
“最佳实践胜过模板”
模板具有指导性，有可用的价值，但范例能更好的展示如何使用模板。
最佳实践范例没有必要作为事实标准。它们只是在特定的情况中从众多的实例中挑选的最好实例。
“以部署为导向胜过以过程为导向”
构建过程相对是比较容易的，但改进的挑战在于部署（实施）流程，使之真正被采用。
“评审胜过质量保证（部门）”
项目的成功离不开交流与反馈。质量保证人员的工作成功并不能给出及时有效的反馈，而在本团队内快速的反馈将会起到更好的作用。
“业务驱动胜过模型驱动”
改进应与业务收益而不仅仅与外部标准一致。
如果与组织中团队驱动方式、敏捷软件开发和探索式测试同步，那么这一改进方法将是可接受的。如果在命令和控制的管理风格之中，或是强烈依赖于过程细节，或是在脚本化的测试中，这一方法很难被接受。
文章来自 王道质量，侵权联系删除！！
