如何通过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之前就拦截大部分缺陷,我们的测试人员也可以解放出来更好和更有信心地指导前端测试,并有精力搭建后端场景级的自动化防护网。整个持续改进圈有望进入一个良性循环。

本文来自企鹅号 - 点融黑帮媒体

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏WOLFRAM

Stephen Wolfram:如何训练孩子们的计算思维(I)

1546
来自专栏DevOps时代的专栏

从企业案例看 DevOps 转型路线图

前言 在给客户培训DevOps的时候会尽量把整个DevOps体系,包括流程、文化、 技术实践,和业务IT的关系等等传递给客户。但是企业要想从头开始实施 DevO...

2348
来自专栏全栈数据化营销

数据分析案例:sem关键词竞争形式和优化策略分析

在之前的文章中,通过用采集到的公开数据对竞争对手投放sem广告方法和行业竞争态势做了分析,得到了如下结论:

572
来自专栏JAVA烂猪皮

同样的工作、同样的做需求,为什么他们能进阿里

方法论,就是人们认识世界、改造世界的一般方法,是人们用什么样的方式、方法来观察事物和处理问题。概括地说,世界观主要解决世界“是什么”的问题,方法论主要解决“怎么...

832
来自专栏数据的力量

如何写好一份优秀的竞品运营分析报告?

1777
来自专栏腾讯技术工程官方号的专栏

2017国际体验设计大会 | 用研跨界

导读:7月12-16日,2017年国际体验设计大会在北京国家会议中心举行,来自腾讯用户研究与体验设计部(简称:CDC)的负责人ENYA围绕 “ 用研跨界:线上融...

1836
来自专栏华章科技

十大优势让4D打印成为新蓝海

日前,MarketsandMarkets发布关于4D打印的最新市场研究报告《4D打印市场之材料、终端用户的行业和地域——全球趋势及预测,2019—2025》。该...

961
来自专栏程序员笔记

游戏是什么?

1765
来自专栏无原型不设计

UI设计:掌握这6点,轻松0到1

非科班出身能成为UI设计师吗? 答案是肯定的。世上无难事,只怕有心人。只要找对方法、坚持不懈,即便是零基础也能学好UI设计。 那么零基础学习UI设计,需要...

2465
来自专栏大数据应用解读

中科点击:关于大数据概念最全面的解读都在这了

随着大数据产业的迅猛发展,“大数据”三个字对我们来说早已经不再陌生,生活中我们也能经常在身边听到关于“大数据”的讨论,大数据已经代替互联网成为新时代的最热门的话...

60

扫码关注云+社区