如何通过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 条评论
登录 后参与评论

相关文章

来自专栏java学习

初学java的一点感想!你当初是否也是这样?

从毕业后工作半年,发现生活轨迹正在一点点偏离自己的理想,2017年底果断辞职,开始了零基础自学java 的旅程(我是土木专业的)。总结了一些自己的经验,当然不是...

2716
来自专栏web前端教室

知识碎片化对前端学习体系化的损害

你我都身处信息大爆炸的时代,这是一个伟大的时代。 自秦一统天下以来,2000余年从未有普通人能像我们这代人一样,能够这样随心所欲的接触我们想要接触的任何知识。 ...

1937
来自专栏Albert陈凯

Storm创始人Nathan Marz:反馈即一切

**摘要: **Nathan Marz是分布式容错实时计算系统Storm的创始人。在2011年7月Twitter收购社交媒体数据分析公司BackType前,他...

2264
来自专栏华章科技

优秀程序员的七大特征,你具备几条?

程序员的脾气通常很大,常常会和客户、同事,甚至老板在程序问题上发生争执。优秀的程序员能够站在对方的立场上想问题,能理解客户的无知、初级程序员的无能、老板的无奈,...

793
来自专栏about云

以一当十的程序员不是传说

昨晚,我发了下面的微博: 有些人议论所谓“10x”或者“超级”的程序员都是传说。可那些著名运动员,艺术家,作家,呃,还有摇滚明星的都是神话吗? — Yev...

2628
来自专栏程序猿的那些趣事

自学编程难在哪里?教你如何解决

他们要么看书学习,通过各大论坛网站找资源学习,要么通过线上课堂学习,更或者在线下接受培训。

533
来自专栏java一日一条

如何成为一名Java冠军程序员

几个月前,我和的商务合作伙伴 Carl 以及我们的法国课程导师 Xavier 在巴黎的一家餐厅就餐。在谈话中,我和 Carl 就我们年轻时使用的那些炫酷技术而谈...

330
来自专栏非著名程序员

程序员的技术修炼如登峰,到不了顶也要努力向上攀!

为了学习React Native,我用了5天时间研究了JavaScript,并写了四篇文章总结自己的认识,有人留言:“才学了5天就能这么厉害?”。前段时间,我花...

1948
来自专栏斑斓

构建你的技术标签

作为一名程序员,又或者IT工作者,拼搏在技术快速变迁的大潮流中,其实是一种幸运,毕竟我们无需陷入重复的枯燥生活之中。然而要跟上技术发展的脚步,真的太累了,就怕步...

2803
来自专栏企鹅号快讯

Python语言会被纳入高考内容吗?

据澎湃新闻近日消息,山东省在其最新出版的小学信息技术六年级教材中,加入了Python的内容。在此之前,编程界也一直有传言,称浙江省将对中学信息技术教材进行改动,...

1817

扫码关注云+社区