51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 14220|回复: 20
打印 上一主题 下一主题

[讨论] 原因分析活动

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-1-7 14:06:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
原因分析活动(针对项目活动本身出现的缺陷进行分析,和过程无关的缺陷)
QA人员需要关注哪些方面并从哪些方面着手审计?

[ 本帖最后由 51testinggg 于 2009-1-7 15:13 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-1-7 14:13:55 | 只看该作者
要看你的原因分析是针对什么的,是对defect的原因分析,还是对Audit出来的不符合项(CAR:corrective action report)作原因分析。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-1-7 14:16:24 | 只看该作者
这个不清楚呀
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2009-1-7 15:13:11 | 只看该作者
原帖由 chnowasm 于 2009-1-7 14:13 发表
要看你的原因分析是针对什么的,是对defect的原因分析,还是对Audit出来的不符合项(CAR:corrective action report)作原因分析。


前者呢?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-1-7 16:11:26 | 只看该作者
如果是对defect(bug)的,首先要看它原因分析的类型对不对,不知道你们公司怎么分的,我们分为,Req,Design,code三个方面。
Req:需求-又分为,UI,Interface,logical,Traceability,Other
Design:设计-又分,Constraint,Traceability,Interface,Function,Error Handing
Code:编码-又分,Function,Interface Relationship,Timing,Algorithm,change history,Checking,Coding Standard,Comments,Resource .....等等

分类正确后,查看它所描述的原因是不是浅显易懂,并且具有可追溯性。
描述清楚以后再看它的改进方案(Corrective action plan)是否合理可行有计划.

不过我看你写的不像是对bug的原因分析,倒像是对不符合项的原因分析。
对不符合项的原因分析也可以模拟改bug的步骤,其实道理是一样的。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-1-7 17:14:12 | 只看该作者
原帖由 51testinggg 于 2009-1-7 14:06 发表
原因分析活动(针对项目活动本身出现的缺陷进行分析,和过程无关的缺陷)
QA人员需要关注哪些方面并从哪些方面着手审计?

不管是不是和过程有关,首先你要明白你做这件事情的目的,既然是原因分析活动,那你就要知道有多少问题是出现在这个原因的。举例,像缺陷,你想知道现在的系统主要的缺陷是由哪些原因产生的,那么你在之前就需要定义好缺陷的分类,也就是说你先要定义好可能引起缺陷的原因,(缺陷分类是个很复杂的科学,是要划分不同纬度的。)然后在缺陷被发现之后由产生该缺陷的成员来填写其缺陷的分类,然后当项目进行的一定阶段后,在对项目的缺陷分类进行统计,看看大部分问题是由什么原因产生的,通过80/20规则,就可以知道我们只要解决一小部分的问题那么就能解决大部分缺陷。这个方法不知道是不是你想要的答案!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-1-8 11:38:40 | 只看该作者
原因分析可以侧重考虑以下几个维度:
1,分布:产品/业务领域/人员/发现和引入阶段
2,产生原因
其中统计技术主要运用在1中,但我认为统计技术只是原因分析的初步,是数据钻取和聚焦。真正还是要回归到技术和业务分析上。这个是不可避免的,也是绕不过去的。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2009-1-9 13:31:55 | 只看该作者
至于原因分析,个人认为,首先要清楚地是公司作原因分析的流程,我们要清楚,我们做原因分析的目的,我们是针对什么,因为问题关注点的不同,我们所得到的答案也会不同。至于其他我认为按照公司的原因分析的流程走就好了
至于QA人员需要关注的是,项目组原因分析的活动,首先看它是否和制定的流程相一致,输入输出的准则是否满足,对分析出来的对策,是否进行跟踪,效果如何

[ 本帖最后由 chengxq 于 2009-1-9 13:33 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-10-17 16:52:39 | 只看该作者
学习学习
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2010-11-17 11:00:36 | 只看该作者
学习了
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2010-12-21 23:21:46 | 只看该作者
可以采用鱼骨图,从根因上进行那个分析,找到问题的引入环节,控制环节,并了解各个环节中出现的问题,制定改进措施或者修改流程,验证,再改进。按照PDCA环来做是没有问题的。呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2011-2-21 10:23:24 | 只看该作者
回复 1# 51testinggg


aaaaaaaaaaaaaaaaaaaaaaaaa
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2011-3-9 16:51:59 | 只看该作者
1.楼主所说的“原因分析活动”是指根据PPQA检查过程中发现的不符合项来诊断项目活动或工作产品的质量吧?
我们实际也会做诊断,但是其实也是缺乏依据的,大家若有什么好的方法或工具,麻烦推荐下哈,先谢谢啦!


2.QA人员需要关注哪些方面并从哪些方面着手审计?
QA在项目初期会依据项目定义的过程来制定QA检查单(就是依据项目过程裁剪一些检查项),在项目过程中就要依据QA检查单来执行检查了。

QA审计一般不会是自己审计自己的项目,一般都是QA人员之间交叉检查,主要看项目所有活动的执行是否符合标准。
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2011-5-25 13:24:15 | 只看该作者
谢谢!
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2011-7-4 11:53:40 | 只看该作者
留个记号
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2011-8-1 17:42:06 | 只看该作者
冒个泡。。。学习中
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2012-5-25 11:05:15 | 只看该作者
learning
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2012-7-10 17:06:07 | 只看该作者
我目前最喜欢用的就是采用鱼刺图,还是比较好
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2012-7-11 15:39:14 | 只看该作者
鱼骨图和柏拉图
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2013-10-10 21:27:41 | 只看该作者
学习了,菜鸟啊,要学的太多
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-23 18:16 , Processed in 0.074234 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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