如何提高生产Bug都由测试背锅是不科学的?

年轻的时候去面过一个相对于当时我的比较高端的管理岗位,当时的我情况是,开发经验相对丰富, 但管理经验还欠缺。对方当时面临一个具体的问题。

“我们最近生产上,出现了一个比较严重的事故,复盘的时候,开发喷测试,测试喷开发,都觉得是对方的问题。对于类似情况你有没有什么解决和处理的经验。如何提高软件质量”

我当时对这个问题回答的比较单薄,无非就说,大家要团结合作,开发要加强自测,测试要考虑全面,有责任心。这么说虽然没错,但是只有战略没有战术,也没实例经验。最终,显然对方也不是很满意, 无缘了这个岗位。

如今的我已不再是曾经的那个少年,虽然错过的人已经错过, 但问题长存, 都说人在不同的阶段,对相同的问题,会有不同的答案,于是锅叔在这里重新回答一次……

具体这件事情,建议从三个层面来处理。

一、就事论事

这一层比较简单,具体问题要具体分析, 要了解下这个问题的出现的原因, 归属的类型,然后才能明确责任。 一刀切的让所有的生产Bug都由测试背锅是不科学的。

二、举一反三

复盘的目的,主要应该不是为了追责。而是为了优化流程。弄清事情的发生原因后,应该建立对应的流程,机制,避免类似的事情重复发生。例如,用例的执行应该能追溯,测试开发能力不足的,要培训,要编写对应操作规范等,缺少评审的流程加入评审。

三、统筹安排

如果公司觉得此事暴露了软件质量的不足,期望改进开发质量,那么就要理解,软件的质量控制和软件测试,其实是不同范围的事情。质量改进包含的范围远大于软件测试,对这一点要在团队中进行宣贯,统一认识。

提高软件质量不等于提高测试质量,质量控制是一个贯穿开发流程始终的活动,需要团队的所有角色共同参与,为交付质量共同负责。

1、产品,需求人员的质量责任

非常容易想到的一个职责是——不能理解错用户的原始需求,否则就将带着整个团队南辕北辙了,但这其实只是一个最基本的要求。

除此之外另一个重要的职责是——传达清楚,即把需求全面,准确的传达给用户。

“准确”可以理解为要把你的需求描述清楚,条理清楚,避免歧义。实践中很多bug的产生,是因为开发人员遗漏一些细节需求导致的。这类bug的情况,通常功能较为细节,例如一些细节的校验,提示的文字,与同类功能的细小差异等。这类问题可以通过在需求编写形式上上,使用逐一列出,重点强调的方式会比把所有需求无差别写成一坨文字,降低发生的比率。歧义情况的出现,多是由于语言描述不严谨,不具体导致的,可以有意识多使用逻辑性描述,实践所占比例不高,适当注意即可。

“全面”实际是一个非常难以达成的要求,需要需求人员有较高的素质。这类问题造成的bug在运行维护多年,持续迭代的系统上暴露的非常多。抽象来说就是修改了某功能,要对应修改系统中对于此功能为有依赖的其他功能。对于陈年老系统,要考虑周全非常困难。简单的例子如,为了增强账号安全,增加了注册用户名的长度,也允许加入特殊符号。需求人员应该想到,此处修改除了影响用户注册页面的用户名输入框校验规则外,也同时需要修改,用户登录页面的用户名输入规则,如果有其他客户端如移动端,也需要同步修改,如果后台有用户管理,搜索,用户名搜索框允许输入内容可能也要同步修改。甚至要求高的UI界面, 因为长度变化,可能会导致显示异常,也要一并考虑到。

而产品架构,则是更高层次的要求, 要求需求人员对产品的功能,实体,概念,做恰当的抽象,并有一定前瞻性。 产品架构其实是技术架构的基础,如果产品没有一个需求上的框架,那技术架构也是无法恰当提出的,随机应变会成为日常,修改成本会升高,稳定性会变差。

2、开发人员

·开发人员主要是要强调自测,对自己的交付物负责。实践中,开发人员常反怼说,我们又不是测试, 我们都测了要测试干啥。 因此也确实涉及到一个度的问题。实践中一个最基本的要求是, 对于需求对应的正向用例应该自测到,通俗说就是需求明确提到的功能开发自测应该覆盖。例如“新增的用户,点击用户名称,能够显示用户详情”,开发人员至少要保证自测下, 新增一个用户,点击其用户名,显示详情这个流程。如果没有问题算通过。而测试人员则要考虑的更多。例如编辑的用户,导入的用户能不能正常显示?有特殊边界输入的,选填项不填的,显示是不是正常。

情况往往也不会这么简单, 现代系统通常分工比较细,一个功能通常由几个开发人员合作完成,他们之前通常通过接口定义来衔接,也就是各自按约定的接口协议,实现功能即可。这种情况下,除了要求按照接口自测外,还要要求,这几个人中指定一个人负责串联的测试,保证功能正确。因为实践中接口难以定义的事无巨细。 这里的接口可能是前后台间的http接口,也可能是基于数据库表的接口(一个存,一个取)。如一个负责用户存的开发只验证了用户信息有没有写入数据库表。 另外一个负责展示的开发人员只验证了,自己在数据库手动填写的数据,能不能正常的被读取显示到页面上。 如果没人负责串联验证下这个过程,那接口对接环节的bug就无法发现,例如,存取的字段不对应,空值的表示不一致null与””等。

开发人员自测确实可以更早的发现bug,降低bug修改的成本,不需要经过 ,“测试提”,”开发查”,”开发改”,”测试验”的过程。但锅叔觉得这只是开发自测收益中较小的一面,更大的收益在于,提高开发人员的质量意识,不是功能写完就算是开发完。通过结合其他追溯机制,可以推动开发人员,使用更合理的设计,主动进行重构优化。

3、测试人员

测试人员在很多人的观念里,是天然的负责软件交付质量的人员,其质量责任主要就是做“好测试”。做好测试,无非依赖于,扎实的软件测试理论基础,和对系统业务的充分理解。 测试理论属于通用技能,只能通过学习思考,积累提高。而对系统业务的充分理解,对测试人员的稳定性是有一定要求的。 如果你们公司的测试人员是共享资源性质的,那应该尽量让他们稳定服务于,1个或几个项目。尤其对于长期迭代,周期较长的项目,人员稳定性非常重要,切换成本高昂。

质量控制是测试工作的超集,因此提高软件质量,也要求测试人员额外承担一部分质量分析统计工作。因为Bug直接由测试人员记录产生, 由其来进行这类工作更为直接。常见的统计指标如,

用例通过率,重激活Bug数,需求问题Bug数,未自测Bug数,遗漏需求Bug数,生产发现Bug数。

都是开发质量的评价依据,是复盘优化的基础数据。测试人员在测试工作中,或者生产环境支持过程中,在bug管理管理工具中,应对bug类型,进行识别归类, 用于日后统计分析。

这也要求,测试人员要客观公正,真实反应质量数据。这里也提下,个人不赞成Bug与绩效明确的挂钩,否则容易造成开发测试对立,内耗严重,非常糟心。-_-||。

4、管理人员

管理人员,首先明白,研发有其自身遵循的客观规律。所谓给技术以时间,凡事总有个测试,优化的过程,如果总是随意拍脑袋,削减研发评估的研发周期,那么,因为功能是显而易见,一定要交付的,所以首先被压缩的一定就是质量。例如一个系统计划开发一个月,测试一个月, 领导一拍脑袋,开发测试压缩成一个月, 那实际上,可能就开发3三个周,测试一个周,中间的各类评审也都被扔的七七八八,开发设计怎么方便怎么来, 测试就走走主要功能能用就行。这样质量就不要苛责了,相当于把测试交给最终用户,对于长期迭代的项目,也会累积不菲的重构债务。

建立评审,复盘机制,是高级管理人员的职责。 重要的评审公司多小也应该具备,如需求评审,开发设计评审,测试方案/用例评审。同样复盘,如结项复盘,或以时间为周期的月复盘,季度复盘。

基层管理人员,参与组织评审时,应保证评审不流于形式。如需求评审, 就是降低需求BUG的重要环节, 系统大了,需求人员自身的能力,也很难考虑的面面俱到,需要开发,测试共同,帮忙考虑,新需求对已有系统各处的影响。评审过程也是一个传达质量价值观的好机会, 在“好改,工作量小”和“规范,长远可维护”中尽量选择,规范的需求设计, 开发设计方案。要倡导细心和减少Bug是有非常有技术含量和挑战的事情,而不是一件麻烦的事情, 让开发多花精力在一次作对上。

复盘是一个重要的回溯机制,质量问题应该都能追溯到个人,谁提的需求,谁写的,谁测的。 到不一定要跟绩效挂钩,但责任到人的方式,确实可以推动大家,建立质量意识,遵守质量规范。用例通过率低的模块的原因?需求Bug的数量较多,提示我们要重视需求编写,评审,提高需求编写人员能力,未自测bug多,提示开发人员责任心不强,生产的Bug数多,要分析,是否为常见问题,测试是否应该覆盖,如果是用户的日常操作,而回归流程却没有纳入,要考虑测试与用户多沟通,了解用户使用习惯。

OK先到这里,上面的回答,你给几分 :-)。

曾经有一份真挚的爱情摆在我面前,但我没有珍惜,等到失去了我才后悔莫及,尘世间最痛苦的事莫过于此……o(* ̄︶ ̄*)o

© 版权声明
THE END
喜欢就支持一下吧
点赞200赞赏 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容