之所以写这篇文章,主要是大部分测试还是处于弱势地位,线上一旦出问题,大部分人想到的是:你这个没测?基于这点,这篇文章也许可以给你一个明确的答案,这到底是谁的责任。

一、先解决问题

线上爆发重大bug,这时候不是追究责任的时候,而是动员所有可调用的资源,尽快解决这一问题,将损失降到最低。而一般公司在这之前就应该制定好出现重大问题的补救流程和方案以及对应的人员分配。

二、定义bug的性质

解决问题后,定义线上发生的问题的性质,是第三方引起的,不可抗拒的问题,还是自身疏忽导致的错误?且爆发的问题的严重程度,关于bug严重程度的区分,可以参看我的另一篇文章。(传送门:http://blog.jianjiexuan.com/testdocument/42.html

三、分析产生bug的根源

1、需求未涉及,或需求当初定义的不够详细造成。

 这个一般由需求、设计、测试都承担责任,需求的责任最重。之所以说设计和测试也有连带责任,是因为需求评审的时候也参与进去了,而需求都是通过大家一致确认可行通过才执行的。当然,有些公司对于需求评审也不是很重视,也没有专门写需求文档的人,甚至一些小公司直接都是口头表达,这样的需求连记录都没有,实在没办法追责。不过,一般这样的公司也不会追责,如果追责的话,建议设计(产品)、测试一句:你可以刷新简历了。

2、设计过程、开发过程未实现造成。

 这种问题是需求检查到了有未完成的需求,但是设计和开发并没有进行弥补。则为设计与开发的责任,而设计的责任最大。

3、测试过程中的疏漏造成。

 测试过程中的疏漏有2种情况,一种是测试用例没有覆盖,一种是测试用例覆盖了没有执行。第一种参与过测试用例评审的都有责任,但是设计测试用例的人承担最大责任。第二种则完全是测试责任。当然,很多公司根本就不具备评审测试用例或者有专门写测试用例的人,本来管理流程就乱,一人做多种职位的事情,这时候如果硬要追责,建议测试一句:你可以刷新简历了。

4、交付部署中出现问题造成。

 比如版本错误、发布错误、部署错误,一般在设计(产品)、配置、测试经理共同承担责任。

5、私自改动代码造成。

 只能开发哥哥完全承担了。

四、分析总结

 对于这次的事件进行分析与总结,确定是谁的问题后,应该吸取教训,并给出措施,给下次的版本一个参考。

 

其实这套方案肯定是基于自身的流程和管理都非常明确的公司执行。并不适合小团队去执行,小团队建议还是大家一起承担,否则,只会让员工提前离开。如果你不是领导者,愿你不需要看到这篇文章。

 

标签: IT

添加新评论