• 0
  • 0
分享

  产品出了问题,谁都不想担这个责任,那么锅由谁来背呢?

  背锅侠No1:测试人员

  在以往的工作中发现,只要线上有bug,或者有哪个功能没测到,都被认为就是测试的问题。之前做过一个项目,在项目验收阶段,客户对下单的流程提出了一些优化性的建议,但是在开发人员开发完这个需求之后,并没有通知我进行测试,就导致在下一次给客户演示的时候,下单流程根本不通,让客户非常失望。

  就这样甩锅之路又开始了,开发说是功能已经做好了,但是是测试没有测出问题来,测试又说并没有被通知到这个已经改好了需要测试,那么到底是谁的问题呢?其实严格说起来开发和测试都有责任的。

  1、开发人员在功能完成之后应该及时的通知到测试人员进行测试,留出足够的时间改bug;

  2、测试人员应该严格按照需求的时间节点去确认开发人员是否完成了需求开发,不要一味的等开发人员通知,因为有时候开发人员有可能会遗漏掉。

  当然这不是最奇葩的,遇到的最奇葩的一次是,由于运维人员数据维护错误,导致客户的订单错误被投诉,打眼一看,这应该没测试什么事儿了吧?不要太早的下定论哦,领导给出的结论是为什么数据维护完了不测一下?我当时都震惊了,测试只能保证功能没有问题,不可能每维护一条数据都测试一下,数据维护错了把锅甩在测试人员头上,这就有点过分了吧?

  还有就是项目或需求延迟的情况,只要项目有延迟,就是质问测试人员,为什么没有测完?为什么不催着点开发赶紧做完?怎么还有bug没有改完?工作时间越久就越来越发现,测试人员都成全能的了,什么也得干,什么都得会干。

  背锅侠No2:新人

  记得我刚入职一家新公司的时候,由于对业务还不太熟悉,所以刚开始的工作都是了解业务和需求,并没有实际的分给某个功能做测试,有一次一个新需求,其他测试人员测试通过之后,第二天需要将这个新功能更新到生产环境上让客户使用。

  因为是新人嘛,所以领导就让我和他一起来做版本的更新测试,正好可以熟悉一下公司的工作模式和系统的业务流程,但是第二天那个测试人员来晚了,所以就只有我来做了线上的基本流程测试,他并没有这个新功能进行测试。

  但是在版本更新完成后,客户在使用这个新功能的过程中,发现在编辑数据的时候,并没有在原来的数据上进行修改,而是新生成了一条数据,导致数据混乱。

  等追究责任的时候,负责这个功能的测试人员就说是我做的线上测试,在线上没有测试这个bug,不是他的问题是我的问题,当时其实是很憋屈的,明明不是自己负责的功能,就因为自己做了线上的回归测试,问题就被甩在我身上,但是由于是新人,不能一入职就和老员工硬钢,所以就忍了,当时也是很无奈的。(这只是举个例子,当然这种情况也会出现在开发或者运维等岗位上)

  更奇葩的是,新入职一家公司后,接手了辞职人员的工作,当这部分工作线上出问题时,责任也是你的,因为你现在负责这部分工作,没有理由,也不能申辩,接着就行了,作为一个新人,好憋屈哦~

  背锅侠No3:特殊情况不能离职的人

  这里的特殊情况包含但不仅限于怀孕、通勤时间等等。

  当线上出问题被客户投诉的时候,总要找一个人来背锅,孕妈当然首当其冲的成为了最佳选择,为什么呢,因为孕妈不能轻易离职啊,离职之后就要做好在家养胎的准备,一般的企业都不会招聘孕妈的,因为还没为公司创造价值呢,就要休产假了,当然孕妈们也都深有体会,所以在这个前提下,孕妈总会被推出来背锅,因为她不敢轻易离职,有委屈只能受着。(这个小编自己都深有体会)当然还有通勤时间的影响,如果住处比较偏僻,而当前公司又是仅有的离家近的公司,那么也会成为背锅的靶子。

  遇到职场甩锅,我们应该怎么办呢?

  1、如果遇到顶头上司甩锅

  那么就得看你能不能忍了,如果能忍了,那就忍着吧,毕竟还要在他手下工作,不然你以后的日志就不大好过了,有被穿小鞋的风险。

  虽然忍了,但是也可以在跟他沟通的过程中表达一种我非常乐意承担这个责任的态度,既然结果不能改变,那么也要表明自己的态度,这样领导心里也会觉得愧疚,有可能你会得到更好的资源或者更好的待遇;如果你觉得忍不了,或者这个公司可有可无,那么畅所欲言吧,把事情说明白,尽量的证明自己的清白,既然不打算在这呆了,也就不怕得罪领导了。

  2、如果是同事之间甩锅

  两个测试人员之间,那么我的建议是,明确这个功能到底是谁负责的,由主要负责人负责。如果是开发和测试之间,那么我建议是共同承担责任,因为两人都有问题,开发没有考虑全面,测试没有测出问题。

  3、新人老人之间甩锅

  如果新人遇到老员工甩锅,不要急着撇清关系,首先要表达出自己刚来,对系统还不熟悉,有可能漏测并愿意承担责任的态度来,其次是委婉的表达自己没有负责这个需求,并没有对这个需求进行过多的了解;

  当然作为一个老人,不能仗着自己是老人就将责任推到新人身上,是自己的就是自己的,要有一个勇于承担责任的心,因为所有人都是从新人到老人一步步过渡的。



作者:CICI   

来源:51Testing软件测试网原创

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 1、能不能介绍一下国外的工作模式和方法 国外测试的关注是在哪方面我不清楚国内的工作模式,但我觉得类似。对于工作流程来说:每天都会有scurm meeting(我们组是下午meeting,别的公司是在上午),简单讲自己的工作进程,有没有地方不会做,或是遇到问题需要帮助,有些时候会唠嗑。每周五有mini demo,就是给老板和老板的老板展示工作进程,然后得到这些大佬的反馈每月都有sprint demo,就是给老板和老板的老板展示工作进程,然后之后发布对于测试人员来说:月初的工作,将上个月的自动化代码完成(或是其他tech debt没做完的做完)月中的工作,写测试计划,案例,步骤和测试环境的部署和数...
            0 2 1719
            分享
          •   一、缓存测试  缓存系统的使用,在一定程度上,极大的提升了应用程序的性能和效率,在秒杀系统的建设上,缓存系统出力不小,特别是数据查询方面,数据的快速返回广受好评。但同时,它也带来了一些问题,测试过程中,如果没有及时关注到缓存系统,整个测试环节是有遗漏的。缓存系统没有经过严格的测试,容易产生一个严重的问题,就是数据的一致性问题。如果没有对缓存系统进行测试,并且后端系统对数据的一致性要求很高,那么就不能使用缓存。  缓存的主要作用:是将业务系统的数据处理结果,暂时在内存中保存,并且等待下次访问的时候,立马从内存中取出。在日常开发场景中,因为服务器的性能或者自身业务对数据处理非常耗时的时候,当发...
            14 15 1850
            分享
          •   在JMeter脚本设计中,搭配使用各类测试元设计接近实际场景的步骤是整个脚本设计环节的关键。各元件组合搭配,在完整的测试交互周期中,发挥了数据抽取转换、分支逻辑控制、响应解析判断等多种功能,将标准交互请求进行包裹、扩充、衔接、串联形成触达不同数据、激活不同逻辑的树形执行结构。  因此了解JMeter各测试元件在执行线程生命周期内的执行顺序,对复杂场景脚本设计有重要帮助。  取样器(Sampler)。作为支持JMeter实现协议交互的核心元件,也是线程执行的主体部分,在实现请求交互的前后阶段为其他元件发挥增强功能提供基础。环绕在取样器元件之外,有“切入式”的增强元件,也有具备全局性质的功能元...
            12 12 1742
            分享
          • 近10年,技术迭代最为迅速,彻彻底底改变了人类社会的生活方式,中国互联网从无到有,发展迅猛。互联网用户量激增,已由原来的4增长至8亿+。面对当下的局势,用户体验自然就成为了互联网产品面临的最大考验。分析近年来的系统崩溃翻车事故,得出结论:性能是影响用户体验的最重要因素。一、什么是性能测试?通俗来说:利用性能测试工具或者代码对系统的相关性能指标进行的测试,用来评估系统的性能二、为什么做性能测试?性能测试是互联网+企业的“刚需”企业规模越大,性能瓶颈越明显,性能测试至关重要!性能挑战:业务复杂度提升数据级日渐庞大实时性要求提高并发压力越来越高应用面越来越广 三、功能测试与性能测试四、怎么...
            0 0 948
            分享
          •   1 需求分析与确认  意义与作用:  需求的准确性与必要性是项目成功的前提,同时能够帮助开发与测试更好的完成工作,明确工作内容并做出相应的计划。  2 测试点  测试点就是针对需求所设计的,在完成需求确认后就可以确定测试点。  3 编写测试用例  测试用例就是保证测试点能够被正确的数据覆盖。  4 执行测试用例  当开发把相应模块功能完成,就可以执行设计好的测试用例。  5 缺陷管理  将不通过的测试用例提交给开发进行反馈与追踪。  6 总结测试报告  对测试缺陷进行分析统计,对本次测试实施进行总结。作者:枫桥夜语    来源:http:/...
            0 0 989
            分享
      • 51testing软件测试圈微信