51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

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

[复制链接]

该用户从未签到

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


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


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

使用道具 举报

该用户从未签到

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

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

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

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

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

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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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

使用道具 举报

该用户从未签到

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

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

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

使用道具 举报

该用户从未签到

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

使用道具 举报

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

    连续签到: 1 天

    [LV.1]测试小兵

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    该用户从未签到

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

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

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

    使用道具 举报

    该用户从未签到

    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管理,最终大家听到了理由后都不说话了。
    当然我也有错,从中我得到了教训,也学到了一些基本流程知识。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    tongyi

    回复 支持 反对

    使用道具 举报

    该用户从未签到

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

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-23 21:53 , Processed in 0.085256 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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