51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5912|回复: 16
打印 上一主题 下一主题

[求助] 软件发布后,发现BUG谁负责?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-8-12 15:50:55 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
软件发布后,发现BUG谁负责?


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


非常感谢!!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

17#
发表于 2008-10-14 14:54:03 | 只看该作者
签订合同 量化指标!
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2008-10-14 13:46:31 | 只看该作者

tongyi

回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2008-10-13 23:48:09 | 只看该作者
其实呢首当其冲的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管理,最终大家听到了理由后都不说话了。
当然我也有错,从中我得到了教训,也学到了一些基本流程知识。
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2008-10-13 16:45:36 | 只看该作者
原帖由 ftoilove 于 2008-8-12 16:57 发表
比较通用的做法是:度量软件的缺陷密度,即:发布后的缺陷数/总缺陷数*100%。

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

那么想请问一下,能接受的缺陷密度是多少?
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2008-10-13 08:45:41 | 只看该作者
两种方法
1、对半开,各承担50%的责任
2、泄露的故障测试部负责,但是找到的故障开发部负责。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2008-10-12 19:17:11 | 只看该作者
同意2楼和6楼的,这个问题真的很不错
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2008-10-11 18:04:51 | 只看该作者
责任应按比例划分,开发测试各有责任,至于是3-7,4-6,5-5分,还是什么,具体问题具体分析了
回复 支持 反对

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

9#
发表于 2008-10-10 22:52:57 | 只看该作者
支持2楼
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2015-1-13 13:37
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    8#
    发表于 2008-10-10 18:56:26 | 只看该作者
    赞同2楼的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2008-10-10 14:40:07 | 只看该作者
    楼上MM讲的很好,关键不是谁来负责,关键是这些BUG是怎么发生的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2008-10-5 17:38:10 | 只看该作者

    重点不是谁来负责,而是分析这个bug被泄漏的原因

    重点不是谁来负责,而是分析这个bug被泄漏的原因。比如是否是需求的问题?设计的问题?测试用例未覆盖?测试执行未覆盖?测试环境问题?历史遗留问题?等等
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2008-8-13 22:47:15 | 只看该作者
    对于这种公司,你就要测试时间么,如果不给足够的测试时间就不要放,如果老板说要放,那你就说,有bug你负责,我不负责:)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2008-8-13 16:50:50 | 只看该作者
    2楼回答挺好的
    我们公司也是这样,去实施的人员在测试过的软件系统上发现了bug,领导就怪测试没有测好
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2008-8-12 17:25:09 | 只看该作者
    严重同意楼上的说法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
    发表于 2008-8-12 16:57:52 | 只看该作者
    1、测试的目的:在已有的测试用例下证明系统是没有错误的。
    2、测试的本身目的:以最小的测试用例达到最大的测试覆盖率。

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

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

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

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

    还有没有人能保证发布后不出bug,微软也不行!
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-24 01:29 , Processed in 0.078229 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表