• 0
  • 0
分享
  • 学会这些,扔掉测试人常背的3口“锅”!——软件测试圈
  • 曼倩诙谐 2022-10-12 14:12:09 字数 2036 阅读 514 收藏 0

  51Testing测试行业调查问卷得不得填一下吧。这套问卷能够对未来的行业发展趋势做出权威的分析,只要点击链接参与,还能获得实用软件测试资料。链接:http://vote.51testing.com/

  最近发生了一起生产事故,究其根源,事故本身属于架构或者需求层面需要规避的问题,测试人员的责任其实是非常小的,但实际情况是:相关测试人员因此承担了很大的压力,成为质量问题的“背锅侠”。

  实际上,测试人员一直处于“背锅侠”的处境,今天就来聊聊,测试人员究竟背了哪些锅?

  测试背的第一层锅:产品不能如期交付的锅

  我们知道,产品交付排期一般是固定的,很多时候,我们在这个基础上,进行开发测试排期的倒排,而测试作为产品交付的最后一个环节,经常被严重压缩排期,场景比如:

  研发未能按时提交测试版本;

  研发如期交付,但功能并未开发完,或者交付质量很差。

  上述两种场景非常常见,尤其是第二种场景,这时候测试人员几乎是有口难言,人家按时提交了,交付质量差也怨不得人家,但因此带来很多测试成本,原来评估的排期根本不够用。

  更有甚者,虽然交付测试,但部分功能未开发完,然美其名曰“敏捷测试”,这里不是说敏捷测试不好,只不过实际过程中,敏捷测试被滥用了,因此带来很多测试人力的浪费和排期挤压。

  这两种场景,带来的直接后果,就是测试排期被严重压缩,如果产品未能如期交付,第一个被拿出来的理由一定是:未完成测试。

  而为了不背这个锅,测试人员只能压榨自己,逼自己如期完成。这是测试背的第一层锅:产品不能如期交付的锅,而为了如期交付,测试人员只能压榨自己,加班加点。

  测试背的第二层锅:质量不符合预期的锅

  在产品使用过程中,如果出现问题,第一个被问责的对象就是测试:测试人员为什么没有发现该问题?

  而因为几乎大部分问题都能定性为测试案例未覆盖,所以测试经常需要背“质量不符合预期的锅”。

  之所以背这顶锅,根本原因是业内人员对测试人员的职责定位有误。

  大部分人认为测试的职责就是为质量负责,且是负全部责任,只要是质量问题,测试就需要承担起来。

  但,请问质量是测试出来的吗?显然不是,质量是设计出来的。

  一个坏透了的架构设计,注定产品质量会漏洞百出,测试无法穷尽所有场景发现所有问题。一个好的架构设计,在设计层面就规避掉了几乎所有潜在风险。

  当一个产品漏洞百出时,一定是架构设计的不够合理,这时候无论怎么测试,质量都不会太好,因此,当问题出现时,不应该去问责测试为什么没有发现,而是去反思架构设计。

  总结来说,很多时候,测试成了架构设计不合理的背锅侠。

  当然,这个结论的前提是,这个问题的确是架构的问题。如果出问题的是核心流程,测试的确需要承担一定责任,毕竟基本功能需要确保无问题。

  测试的职责是验收产品主要功能满足要求。

  测试背的第三层锅:紧急出版本的锅

  很多时候需要紧急出版本修复问题,这时候,测试排期几乎被严重压缩。然后,测试还要担着交付后质量无问题的责任,这两者其实是互相矛盾的存在:为了保障质量,需要充分的时间去测试,而排期被严重压缩,几乎没时间充分测试,测试人员深陷其中,苦苦挣扎。

  总结来看:

  一方面产品交付前,测试排期被严重挤压,测试需要加班加点去完成测试,而由于排期被压缩,测试可能无法充分展开,存在质量隐患。

  另一方面,产品交付后,如果真的出现质量问题,测试又会成为第一个被问责的对象,而为了紧急修复问题,测试又需要加班加点去完成测试,而这时候测试周期往往被严重压缩,无法充分测试,进而又埋下了质量隐患。

  这不是“背锅侠”是什么?

  如果团队研发能力很弱,且对交付质量要求很高或者事故容忍能力很低的时候,测试面对的压力会被急速扩大,成为“超级背锅侠”。

  为什么呢?因为研发能力弱,代表潜在质量问题会很多,测试复测成本非常大,且交付的产品从根上就注定了功能不稳定,导致事故频发。如果这时候产品对事故的容忍能力很低,那么后果就是测试需要频繁的被问责,以及被要求完成紧急版本的测试。这种情况下,压力被严重放大。

  如果产品对质量问题的容忍度较高,那么测试人员暂且还可以承受住这个“冤屈”,而如果团队研发能力很弱,且对交付质量要求很高或者事故容忍能力很低的时候,就需要考虑“伸冤”了。

  如何伸冤

  列举几条:

  摆正测试人员的职责范围,质量是设计出来的,不好的设计一定会存在很多质量隐患,不要上来就问责测试。

  基于当前的研发能力,对未来事故的发生频率给予合理的预期,尤其在上面描述的场景下,这时候,如果还要做大型架构设计改造,那么未来一定会出现各种质量问题,需要对质量问题有足够的容忍度,提供宽松的空间让大家去踩坑,只有这样才是最为人性的处理。

  放缓产品交付节奏,缩小产品影响范围,逐步交付,降低事故发生频率。



作者:刘盼    

来源:http://www.51testing.com/html/48/n-7793248.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •   测试用例编写完之后,我们在测试过程中往往会发现,有一些用例其实是重复的,造成很多重复工作,那么我们应当如何去除这些重复用例呢?  尤其使用等价类划分和边界值分析编写用例时,很容易造成用例重复。  举例  下面我们通过一个例子来具体分析一下。  首先选择一个场景,后台维护前台账号,主要有以下几个字段(字段太多,这里只列举三个字段进行分析)。  账号:4~8位字母和数字组合  密码:8~16位字母数字组合  姓名:字母、数字、特殊字符和汉字组合,长度4~20  下面我们对他们的等价类和边界值进行分析。  账号  有效等价类:6位数字和字母组合,5位纯数字组合,7位纯字母组合。  无效等价类:3...
            0 0 1343
            分享
          •   当前,我国金融体系内交易量持续增长,业务场景日趋复杂。系统交易量的增加,临时产生的集中业务需求,都会使服务器面临考验,因此,需要对系统进行性能测试。在金融系统中,报文处理是必不可少的。各大金融机构间通过报文的交换进行信息流的传递,从而最终实现资金的跨机构流转。在对金融系统的性能测试中,自然也少不了与报文打交道,而性能测试往往伴随着大量数据准备。那么,如何高效地生成大量报文呢?  试想这样一种场景:某金融机构需在特定时间内进行一波资金划转,该业务是新增交易,且交易数量较大,需要准备大量报文对服务器进行性能测试。数据的准备有很多方法,其中Python由于易上手且兼具灵活性而逐渐受到测试工程师们...
            0 0 934
            分享
          • 距离17年下半年高项考试已过去将近1个月时间,回想起准备考试的日子仍历历在目,现如今吸引眼球的东西太多,需要我们花精力处理的纷杂事情也堆满了难能可贵的休息日,电视剧里跌宕起伏的剧情,奔波于陪孩子补课的路上等诸如此类,以至于每周拿出半天时间去阅读去学习都是极其奢侈的事情,不知大家是否也深有同感,所以如何能够既省时又省力的通过考试,是我们准备考试前都应该了解清楚的事情,俗话说"不打无准备之仗,方能立于不败之地"说的就是这个道理。1. 备考选择我们都知道要想通过考试的决定性因素是分数,我们只要把握住考点以及每年常考和必考内容通过考试基本上没有什么问题,掌握这些考点的过程...
            0 0 988
            分享
          •   【案例】  在我们日常生活中,ATM机是个大家都非常熟悉的事物。银行为例提高工作效率,方便客户随时办理基础的储蓄和提现业务,于是,ATM机就诞生了。我们都知道,所谓用户取款业务,就是指为用户提供插卡、校验和取款操作的全过程。那么,围绕用户取款业务,我们应该如何为之设计测试步骤呢?  【解析】  在这一场景下,我们首先需要做的,就是构造基本流和备选流。详情如下:  (1)基本流  对于ATM机来说,它的基本流的初始状态是:荧幕出现欢迎页面,表示系统已经准备就绪,可以开始自主操作。接下来,它的业务处理流程基本如下:  ① 插卡:用户将银行卡插入ATM机的卡槽;  ② 卡校验:系统读取被插卡的账...
            0 0 5363
            分享
          •   关于Jektor  Jektor是一款功能强大的Windows用户模式Shellcode执行测试工具,该工具可以帮助广大研究人员了解和测试恶意软件所使用的各种不同技术。  该工具主要针对的是Shellcode注入技术,可以演示恶意软件在目标系统上执行Shellcode时所使用的技术方法,其中包括:  · 动态解析API函数以避免IAT包含  · 使用未记录的NT Windows API函数  · 通过CreateThread执行本地Shellcode  · 通过CreateRemoteThread执行远程Shellcode  · 通过QueueUse...
            0 0 487
            分享
      • 51testing软件测试圈微信