51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3071|回复: 8
打印 上一主题 下一主题

QC应为设计缺陷承担怎样的责任?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-3-26 14:12:40 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
设计缺陷是否为bug?在产品的整个生命周期,QC需要为设计缺陷承担怎样的责任呢?


说说我的理解。



广义上讲,设计缺陷就是bug;狭义上讲,设计缺陷不是bug。不同的时期对QC在这一方面的要求可能有所不同。

在开发期,QC通过文档分析来发现设计缺陷,主要是策划设计文档的不合理之处;除功能模块自身逻辑之外,还要联系整个产品的其它功能。这是QC的主要工作内容和职责之一。在alpha测试阶段,QC仍有途径来发现和反馈设计缺陷。这2个时期,QC都有责任来解决掉可能的“设计缺陷”,而不是置之不理或轻描淡写;必须有个结果,而结果是说服或者被说服。



在beta测试阶段,设计缺陷通常会通过运营渠道反馈上来,项目经理乃至主策、主程和测试主管都将知晓该情况。这是职责的定位是比较敏感的。我想QC的第一反应不要去追究大家的质疑“为什么有这个缺陷存在?为什么没能更早的发现这个缺陷?”而是把第一时间拿来跟进解决方案。当质疑结束,总结经验教训是必须的。


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/qiaoanlu/archive/2010/03/26/5418691.aspx
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
 楼主| 发表于 2010-3-26 14:15:38 | 只看该作者
游戏测试职业讨论群号:106566454
本群的定位是:游戏测试的职业发展、技术、管理的讨论群。
本群只允许讨论游戏测试相关内容。1月不发言者将被请出该群。
本群允许人身攻击,但不许骂脏话。

希望每个人都能为群共享,并从这里获得。我们在一起交流和提高。

为了保证本群能达成该目标,本群欢迎1年以上工作经验的游戏测试从业者加入本群。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-3-26 14:27:58 | 只看该作者
我做过的项目也是这样
1、审核策划文档
2、功能测试过程中发现设计缺陷
发现缺陷后按正式bug提交并关注缺陷生命周期。处理流程如下(没法画流程图凑合看吧):
1.发现缺陷提交new一个bug     等待处理goto2
2.得到回复信息     
2.1已经修改该缺陷     已经修改好goto3.1   没有修改好goto3.2
2.2该缺陷是设计需要或无法解决    认同意见goto3.1    不认同意见3.3
3.对缺陷bug做出处理
3.1认同回复意见结束该缺陷bug的生命  end
3.2没有修改好继续修改   goto2
3.3不认同回复意见找更高权限角色处理     goto4
4.高权限角色做出处理
4.1一定要解决缺陷     等待处理后goto2
4.2做出取舍不修改了,服从命令   end
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2010-3-26 15:24:35 | 只看该作者

回复 2# 的帖子

新人真难混,群都不让进!
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2010-3-27 13:28:06 | 只看该作者
max提供的流程是个范例,应该差不多大部分公司都会这么做
但是流程毕竟是流程,重要的还是要看每个执行环节的执行效率
在3.1容易出现的问题是缺陷的生命周期结束后(验证关闭)后,BUG会重新出现。
解决办法是,在BUG进行修复和测试之后,如果通过了测试,则不验证关闭(会和开发部门与策划部门约定一个功能开发结束点)在结束点到来前,这个被测试过的BUG将会反复的进行测试。直到版本计划结束时,统一验证关闭。
在3.2容易出现的问题是开发任务过重,有些BUG不会被及时修改而导致关联性BUG产生。此时BUG的严重程度和优先级会发生变化(进化?)
解决办法是,将此BUG与其引发的其他BUG做成一个集合,提交开发部门,并申请提高这个集合的严重程度和优先级,以达到提醒的作用。这个对QC的要求比较高,会预估到可能出现的问题。在日常测试中发现的BUG,一定要进行缺陷模型的整理和总结,对BUG涉及和影响的范围有个一个预估和判断。
在3.3出现的问题是:你不可能让所有人都了解测试和测试的工作。更高权限的角色也有可能不明白,而是希望通过部门间的配合和调整进行处理。你无法获得建设性的意见。那么你在提交之前,必须确认如下几点:
1,这个问题是不能通过部门间协调和组织解决的
2,这个问题需要在成本上考虑
3,这个问题牵扯到的部门非常多
4,这个问题已经没有第二条解决方法
5,在提交这个问题给高层时,确认问题是重现的
6,你有一套可行的解决方法和解决该问题的花费
7,你准备好了说服别人接受你的意见和观点
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2010-3-27 13:34:07 | 只看该作者
至于QC为设计缺陷承担的责任,我想建议类会多于修改类吧。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2010-3-29 09:24:03 | 只看该作者
哈哈 我提供是对于搞不定的bug应该怎么找boss处理的流程。

关键版本要对以往出现过的bug做复测,确保不会因为代码覆盖重复出现。
开发过程如果出现影响主线开发的bug,应该在解决bug后统一更新最新代码后继续。防止在错误的基础上建房子。如果在测试过程中发现表现层与数据层出现差异过多,申请开发部门开debug模式加入测试,进行功能消息传递的测试。由开发部门提供环境和监视人员,由测试部提供测试流程。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2010-3-29 22:49:59 | 只看该作者
假如BOSS是熊出没注意的那种, take care....
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2010-3-30 09:15:39 | 只看该作者
彪悍的人不惧这些
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-9-20 20:41 , Processed in 0.076283 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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