如何通过FST实现研发生态持续改进

如何在新兴创业公司开展有效的持续改进，达到质量和效率的双赢，以下是笔者入职不到一个月时某天早晨突然冒出的想法，当然也是因为之前的一些实践基础，就此诞生此篇文章。个人粗浅见解，欢迎大家一起交流。

当我们的测试人员和开发人员比例是：一个项目组仅配备一个或2,3个测试人员的时候，我们该如何低成本又非常有效的来保证我们研发对象的质量呢，这里的质量包括需求设计的质量，开发代码的质量，开发自测试和测试人员的测试质量到产品上线的最终质量。

大家都明白产品的质量是做出来的而不是测出来的，若很烂的需求设计和开发质量，凭再高的测试能力也测不出好的产品质量来。因此以这么少的测试人员配备现状，开发还是自己做自己的代码编写，测自己的开发测试，测试人员自己cover这个项目组demo阶段的整个测试，常常会看到测试人员的测试报告反馈，因为时间和人力限制，仅测试了什么平台等，某些没有测试可能存在风险。

这个现状下测试人员很疲惫，因为时间压力和精力限制都在被动尽力完成自己的测试任务。测试人员也没有精力或意识去反馈他对研发前端的需求或具体有效可落地的改进建议。需求设计者，开发人员也因此得不到测试后端对自己的设计和代码开发及自测试的改进反馈，整个本应客观存在的持续改进环在这里没有发挥出它应有的效果。

因此根据现在项目组一般仅有1,2个测试人员的情况，测试人员后端的测试工作量时间压力很大，如何才能改变这种现状。

第一，大家很快可能会想到每个产品提升基线功能的自动化率，减轻测试人员压力，但现状测试人员本来已经压缩了基线的测试了，主要测新需求，bug回归和主流程。所以自动化建设也需要测试人员人力解放出来一点才加的进去。

换个思维，在这么少的测试人员情况下，测试人员最应该发挥的作用是什么：测试的特有价值：测试该有的端到端测试分层策略，基于工程方法指导的测试设计，以及测试人员特有的逆向思维和代表客户的思维。

而减轻测试后端压力的方法就是从漏出问题反向推动前端需求设计和开发代码及自测试持续改进，减少前端就可发现的缺陷漏出到后端测试。在这么少的测试人员情况下，具体该如何操作呢？

有个思路，测试人员可以定位为Test Coach，把测试思维带入需求设计阶段，开发自测试阶段，指导需求设计和开发自测试阶段的测试工作，比如需求设计阶段可以指导需求设计者做需求实例化，输出验收用例，达到需求设计者，开发，测试铁三角对需求理解的一致；开发自测试阶段指导开发如何设计自测试用例，把测试设计的工程方法：边界值，等价类等这些提升测试设计质量的能力建设到开发团队去，并指导开发自测试也是需要基于对业务场景的基础上区分高低优先级用例，等等。

这种测试人员TC的定位以达到前端的需求设计和开发自测试缺陷漏出的拦截，进而减轻后端测试压力，让测试自己也可以有精力去建设后端基线测试自动化能力，以及后端测试保障防护，从而达到从需求到开发到测试后端分层的质量防护网。

那么具体TC如何才能让需求设计者，开发，测试都通过自己的后端反馈持续改进各角色本阶段的事情，避免缺陷遗漏到下一个环节，造成更大的成本和效率损失。这里介绍一个缺陷流出分析的工程方法：FST（fault slip through）。

TC可以在项目组里和PM主导做FST分析，实现持续改进圈的落地，以期收获带来的研发效率和质量提升。

FST的目的：尽早暴露缺陷，降低后端暴露定位和修复代价。

Fault slip through缺陷流出分析流出流入率定义：

Faul流出率=本阶段之后发现的本该本阶段发现的缺陷 / 本阶段应该发现的缺陷总数，

Fault流入率=本阶段发现的前期缺陷 / 本阶段发现的总缺陷。

因此FST里需要对Bug进行分析：

Bug分析里需要项目组根据产品形态、项目组的研发能力和测试本应遵循的规律共同定义缺陷类型及缺陷应发现的阶段，项目组成员达成共识，方便后续大家分析时理解一致。下面例子仅供参考，产品不同，各阶段的缺陷类型定义会有不同，以下只是一般意义上的示意。

Bug分析：

FST度量：根据Bug分析填写FST分析表得出Fault流出率和Fault流入率

改进点寻找：Fault流出率，流出率最大的，即可找出最需改进的研发阶段，进而找出此阶段哪种类型的缺陷漏出最多。

改进效果度量：

1．对于demo测试阶段，Fault流入率相比前一版本降低。

2．对于stage阶段，Fault流入率相比前一版本降低。

各项目组间对比直接通过相同研发阶段流入率和流出率比较。

FST分析的目的是找出需Top改进的地方，并给出改进措施落实到项目，收获后续版本的质量和效率提升。以上分析过程是为了说明FST的思路，具体实施，在项目组就缺陷类型及各类型应发现的阶段定义清楚后，这些都可以做入我们的缺陷管理工具，日常缺陷处理的时候开发人员测试人员就可通过填写这些纳入分析的必填字段自动完成FST分析，每个版本或两三个版本一个周期导出数据，即可获得缺陷流入率和流出率，重点工作就落在如何进行切实可行的改进措施及落地。

FST分析最终能带来实际效益的是改进建议和措施的具体落地，比如一些常见的需求阶段需求澄清通过scrum铁三角协同制定实例化需求，最终测试输出验收用例，代码静态检查自动化工具使用，代码review方法和规则使用，开发自测试用例设计原则，开发自测试自动化用例建设等切实根据项目组人员和能力制定的有效的改进措施，而项目组在实践过程中可根据具体问题给出可落地的措施，措施可是原则也可能是就添加某类基线自动化用例等等。

到此，改进措施落地，下一轮FST度量看改进效果，持续改进的环就算正常运行起来了。改进效果如果较好，我们可以在demo之前就拦截大部分缺陷，我们的测试人员也可以解放出来更好和更有信心地指导前端测试，并有精力搭建后端场景级的自动化防护网。整个持续改进圈有望进入一个良性循环。