本章讨论的是，驱动研发
改进的方法和技巧，独立的
第三方评估的业务范围等。
9.1驱动研发改进
测试工程师是研发团队里和“
问题”打交道最多的人，产品缺陷大部分是通过测试发现的；客户问题的处理也需要测试参与
重现和回归。此外，测试处于研发的
下游环节，产品及其研发流程的“问题”最终都会不可避免地给测试带来
麻烦。
测试人员看到的问题比较
全，同时又深受其
害，因此，大部分测试团队都会从问题
出发，驱动研发团队进行产品质量、研发能力或者研发流程的
改进。
这个活动从职责定义上来看是属于QA的工作范围，但是大部分的QA由于并不实际参与产品的设计、开发、测试工作，往往很难及时、准确地发现问题。因此，很多时候改进活动由
测试发起，QA参与措施的制订，并协助改进工作的推进和落实。
【价值体现】
驱动研发改进的价值在于，测试联合研发及客户的相关角色，共同推动研发质量、改进效率，使产品质量、交付效率持续提升。
由测试驱动的研发改进，往往以产品质量和需求响应速度出现明显问题为契机。
【核心工作】
无论测试发现的是什么机会点，都需要展开以下工作：
1、
问题分析及制订解决方法。对问题进行根因分析，找到导致问题的直接、间接和根本原因，并针对原因找到解决方法。
2、
说服利益相干人投资。产品及其研发过程的大部分质量和效率问题，都无法通过测试单方面的行动得到彻底改善，测试人员说服各利益相干人共同行动，才能达成目标。
3、
做好沟通管理。在改进项目实施的过程中，要做到信息及时批露，让利益相干人看到进展，在实施过程中建立达成目标的信心。
从我的经验看，大部分测试驱动研发改进的项目，最困难的是让问题和解决方法具备说服力，从而顺利得到研发在设备和人力上的投资。其次，在项目实施过程中，往往聚焦技术和流程改进的活动本身，忽略了和利益干系人的沟通，导致研发实际投资缩水。
9.1.1问题分析及解决方法制定
测试驱动研发改进，通常是基于问题的，通过这些分析找到研发能力和产品质量的改进方向。
测试驱动产品质量改进。测试实践比较多的是驱动产品质量改进，有产品的研发团队明确提出：驱动产品DFX质量提升是测试的主要价值之一。
测试驱动产品体验的提升。
测试驱动研发能力改进：从分析缺陷和客户问题总结得到的测试设计要素
清单，用这张清单可以帮助
改善测试的设计质量，同样也可以
提升软件功能性设计的质量；用RBT的方法使设计、开发和测试活动聚焦高风险特性，聚焦风险点的解决；通过项目管理和流程制定，改善交付活动的质量和效率。
问题分析一般是采用
根因分析，在原因分析过程中，直接当事人的原因分析意见必不可少，切忌由测试人员包办根因分析。
在改进项目的过程中，经常遇到直觉判断错误这一情况，测试人员根据自己的理解完成了问题分析，但是研发团队其他角色根本不认可分析结论。原因的分析经不起挑战，自然也就无法推动后续的改进行动。
当要求分析、设计、开发人员实施能力改进时，尤其避免测试人员自说自话，如研发流程、软件分析和设计方法、研发工具、知识管理平台、产品信息管治平台等。最好是由测试提出问题，质量部站在全流程的角度上评估问题的严重性，并组织各角色分析问题，确定改进措施，最后组织实施。
在研发改进项目中，测试如果能够基于已有的成果开展工作，将会事半功倍。常见的、对研发改进有帮助的测试成果包括：
1、
自动化。基本功能的自动化用例集执行100%通过，作为产品发布的门槛条件，确保发布产品的基本功能正确。稳定、易用的自动化工具，可以帮助开发者进行功能验证，提高特性开发的质量。
2、
测试用例。将基于需求的业务场景、应用场景测试用例作为实例化需求，提升需求确认的效率和质量，也防止开发的功能偏离实际需求。特性的基本功能用例100%执行通过，作为开发工程师提交特性的门槛条件，可以控制研发过程质量，提升整体效率。
3、
工具。测试使用的接口驱动、业务处理流程跟踪分析、产品运行环境监测、产品运行数据搜集分析工具等，很多情况下也可以改造成为产品运营维护可以使用的工具，提升产品运营维护的问题定位、健康检查等工作的效率。
9.1.2让问题和解决方法具备
说服力
问题分析、解决方案完成后，接下来就需要说服研发各角色共同投入后续的改进行动。
面对研发的各个角色陈述问题、驱动改进时，想要具有说服力，需要注意以下几个基本问题：
1、
围绕业务问题而不是技术。以问题为核心更容易获得有价值的建议，而以技术为核心则非常容易陷入孰优孰劣的争执。这是应该避免的。
2、
问题背景清晰明了。背景信息至少包括：问题影响、问题的原因、研发各个角色做过的努力和遇到的困难等。最后一点尤其重要，很多改进项目的陈述在最初的5分钟就被打断，就是因为完全没有了解设计、开发团队在这个问题上曾经做过的努力，以及无法攻克问题的原因，因而大家也就不相信这次提出的方法能够真正落实。
3、
推论的证据链严谨。采取的措施和需求解决的问题之间要有明确的因果关系，如果只有因果关系，但无法通过定量计算确定措施问题解决的重要性，那么需要辅以业界同行的经验数据。
4、
对问题及其解决方法有独特且具启发性的见解。这是引起兴趣，打动利益相干人愿意去试一试的关键。
5、
逻辑清晰、层次分明、概念准确。这是为了让听众能够跟上陈述者的思路，理解内容、抓住重点和关键。
6、
将“自己”代入问题和解决方案。测试人员自己要成为解决问题的主力之一，不能到最后发现全是别人的问题，或者全是别人的工作。
对设计、开发、测试等研发角色的说服工作，并不是在解决方案定下来以后，更不是在决策会议上才去做的。说服工作在问题分析的时候就开始了，只有在整个问题分析和解决方案制定过程中，不断地和利益相干人及直接当事人讨论、确认和澄清，才有可能给出经得起推敲的问题及分析结论，以及可行、有效的解决方案。
9.1.3
目标制定和沟通管理
研发改进项目启动的时候，需要设定可度量的改进目标。除了
结果性目标，还需要设定一些
过程性目标。在项目开发过程中，监测的是过程性目标，到了项目试点和应用时，同时监测过程性目标和结果性目标。
目标确立以后，在项目的过程中需要通过例行报告、阶段报告、项目例会、多部门联席会议等形式进行项目内外部的沟通。沟通的形式和频次，也是在项目启动时，作为项目计划的一部分明确下来的。例行报告和阶段报告主要用于沟通进展，例会和联席会议主要用于进行计划和目标调整、方案选择，以及问题和风险相关的决策。
沟通进展需要包含以下内容：
目标是什么；已经做到了哪一步；下一步行动。
与测试报告一样，进展报告最好也遵循金字塔原理--把最重要的进展、最主要的问题和困难、最有帮助的外部支持放在最开始的位置，然后是得出的详细的目标及其工作进展。
9.2独立的第三方评估
对于测试的价值，有一位测试经理的观点很激烈，但也切中要害：测试的价值，就是如果把现在测试团队的工作包装成产品或者服务的话，能卖出多少钱？这个问题目前很难找到答案，因为占大部分工作量的功能和性能测试，很难找对相应的测试服务提供商。
目前，把测试做成服务大概有以下几种：
1、
认证。这些认证大部分与安全、设备规范有关。
2、
设备成本高昂的测试。这种情况多数出现在兼容性测试、互操作性测试上。
3、
人力成本高昂的测试。这种情况出现在专项测试上。
第三方评估可以向第三方公司购买，在某些大型的软件公司中，还存在专门的第三方测试团队，这个团队的职责是对产品进行专项评估，降低产品商用的风险。例如，安全性测试团队、体验测试团队等。
9.3小结
从问题出发驱动研发改进，这一价值的范围比较广泛，随着推动解决的问题不同，需要的技术能力也不同，但也有共同的基础能力：问题分析（RCA）、项目管理和说服力。
说服力是测试工程师常常需要使用的能力，典型的就是推动问题解决和报告缺陷。说服力的重点不是锻炼口才，而是锻炼有效的倾听、清晰的逻辑。
独立的第三方评估并非测试团队场景的价值，了解即可。