1.软件测试人员对bug都非常熟悉。

2.测试人员经常抱怨自己就是背锅的,产品上线出bug,一定会有人说测试没测出来,做好背锅准备吧

2.产品上线真就是测试人员背锅吗?也需有测试人员不服气凭什么,我就死扛我测过了,不知道为啥上线有问题,耍赖,踢皮球,说需求没讲清楚,需求变动了。。。等等各种原因。

3.需求评审,测试只需要带耳朵去可以了,你说什么不重要,你人在就行,这就表示流程的要求达到了。这时候你跟道具没有区别。如果真是这种情况,测试人员背锅一点都不冤。

4.需求变更,没有软件项目是不变需求,产品经理可能考虑不周,可能业务方需求变更,总之需求变更肯定存在,开发和测试就勇敢面对吧,如果真是这种情况,建议需求切割,化整为零,排优先级,产品经理需求一尽量写的细,思考的周期点,避免到测试阶段才不停的确认是否需求这样?测试人员背锅概率也大。

5.开发人员,代码质量,提测是否自测等,如果都没自测问题都留到测试阶段风险也就大了,来不及测试,或者测试覆盖率低,都可能背锅。

6.测试人员多多少少都会发现很多bug测不出来,上线才暴露出来,但是是否每个测试人员都想过也许有什么办法可以解决这些问题。

测试左移:为什么开发在憋大招写实现需求的时候测试不能介入?尽可能早的测试,也许能带来一定的质量改进效果。比如说用测试桩的数据,先进行接口测试。

测试右移:preproduction环境,尽量保持与生产一样的数据,接近与生产环境的数据更能发现问题。

优秀的团队:软件质量其实不是靠测试人员来保障的,软件质量贯穿余整个软件开发周期,需求——研发——测试——运维,每个节点都与软件质量密不可分,质量过程管理就尤为重要,需要团队的每个成员一同保障每个环节的软件过程质量并治理,才能确保软件质量。

总之,并不是说出问题了测试人员就是背锅侠,或者开发人员就是背锅侠,产品经理就是背锅侠,互联网团队,应为线上问题处理响应能力,如果真的出现bug,立即处理,立即响应,而不是再找到底谁来背锅?同一个团队,共进退,共拼搏,同输同赢。