51Testing软件测试论坛

标题: 软件发布后，发现BUG谁负责？ [打印本页]

作者: ytyss 时间: 2008-8-12 15:50
标题: 软件发布后，发现BUG谁负责？
软件发布后，发现BUG谁负责？

大家好，大家给给建议或意见：
我们公司软件部刚刚成立，很多研发流程和制度都不完善，尤其是我们测试部，一切从零开始，都靠自己学习摸索！
昨天开会，开发人员和领导一致认为“软件发布后，如果发现BUG，就是我们测试部的责任！”，懂得测试的人都很清楚这样不是很不合理吗？
我想知道大家所在的公司都是如何追究BUG的责任的？开发人员、管理者难道就没有责任吗？

非常感谢！！

作者: ftoilove 时间: 2008-8-12 16:57
1、测试的目的：在已有的测试用例下证明系统是没有错误的。
2、测试的本身目的：以最小的测试用例达到最大的测试覆盖率。

测试通过只能证明一点：在现在的测试用例下，系统是成功的。

但是测试用例无法穷举，所以不能保证测试面面俱到。但是又不能不考核测试部门的绩效；

比较通用的做法是：度量软件的缺陷密度，即：发布后的缺陷数/总缺陷数*100%。

您可以向贵公司领导建议定一个基准值，高于这个值是测试部的责任，低于这个值的话证明你们做的很好。

还有没有人能保证发布后不出bug，微软也不行！

作者: topor 时间: 2008-8-12 17:25
严重同意楼上的说法

作者: yym841105 时间: 2008-8-13 16:50
2楼回答挺好的
我们公司也是这样，去实施的人员在测试过的软件系统上发现了bug，领导就怪测试没有测好

作者: allenzgw 时间: 2008-8-13 22:47
对于这种公司，你就要测试时间么，如果不给足够的测试时间就不要放，如果老板说要放，那你就说，有bug你负责，我不负责：）

作者: flying_up 时间: 2008-10-5 17:38
标题: 重点不是谁来负责，而是分析这个bug被泄漏的原因
重点不是谁来负责，而是分析这个bug被泄漏的原因。比如是否是需求的问题？设计的问题？测试用例未覆盖？测试执行未覆盖？测试环境问题？历史遗留问题？等等

作者: sinakevin 时间: 2008-10-10 14:40
楼上MM讲的很好,关键不是谁来负责,关键是这些BUG是怎么发生的

作者: tofy 时间: 2008-10-10 18:56
赞同2楼的

作者: pbz 时间: 2008-10-10 22:52
支持2楼

作者: chengxq 时间: 2008-10-11 01:34
我想首先这个bug属于什么类型的bug，是高级别的错误，还是比较简单的错误，这个bug没有测试出来是由于什么原因，是由于测试用例的不足，还是测试人员的粗心，这个错误是什么时候注入的等等，对必要的数据进行度量来找出过程中的问题，对相关的组织和个人进行说明，积累经验和教训，而不是一味的找出责任

作者: lvxdoo 时间: 2008-10-11 18:04
责任应按比例划分，开发测试各有责任，至于是3-7，4-6，5-5分，还是什么，具体问题具体分析了

作者: applejuzi 时间: 2008-10-12 19:17
同意2楼和6楼的，这个问题真的很不错

作者: harryku 时间: 2008-10-13 08:45
两种方法
1、对半开，各承担50%的责任
2、泄露的故障测试部负责，但是找到的故障开发部负责。

作者: 蝴蝶月色 时间: 2008-10-13 16:45

原帖由 ftoilove 于 2008-8-12 16:57 发表
比较通用的做法是：度量软件的缺陷密度，即：发布后的缺陷数/总缺陷数*100%。

您可以向贵公司领导建议定一个基准值，高于这个值是测试部的责任，低于这个值的话证明你们做的很好。

那么想请问一下，能接受的缺陷密度是多少？

作者: maggietsai 时间: 2008-10-13 23:48
其实呢首当其冲的Boss肯定会找QA算账
但是QA肯定委屈：为什么最后自己付出最大还要背黑锅？
所以一般我们的做法是：
1.确定defect的类型
2.确定defect来源
3.谁造成defect发生
4.程序上回归测试有没有问题
5.谁对defect的来源有相关责任

有一次我负责的那个item在production上出现重大defect，搜索功能无法使用，project leader问下来
为什么这样？因为我是比较爱面子的，而且辛辛苦苦的工作，经常OT，我的东西出现这么大的问题当然是誓死找出defect源头。

从早上10点追究到下午2点。。
终于找到了答案：
1.我让新人去测这个item，bug fix了她只测defect的那个case其他不测
2.developer fix defect之后没有自己做unit test
3.developer leader在没有重新部署的情况下就把defect 的status改为 ready for testing
4.没有code froze就开始regression testing

这么几个理由牵连到developer leader，和QA管理，最终大家听到了理由后都不说话了。
当然我也有错，从中我得到了教训，也学到了一些基本流程知识。

作者: huchao 时间: 2008-10-14 13:46
标题: tongyi

作者: 厍仕杰 时间: 2008-10-14 14:54
签订合同量化指标！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)