[讨论]Bug 的报告是要简明扼要还是详细说明?
有时要简明扼要,有时要详细说明,难办……有人能告诉我什么时候简明扼要,什么时候详细说明么?
[ Last edited by Nio on 2004-12-27 at 16:37 ] 把事情描述清楚就好了,程序员都是高智商,至少跟我们差不多 To:肚皮
君不见:“简明扼要” 和 “详细说明” 中都有个 “明” 字? 不管什么方式前提当然是都要能够说明问题了。比如说吃饭:你可以只说你吃饭了,你也可以告诉我你吃的是中餐还是西餐以及饭食的内容。
我要问的是:在都能说明问题的情况下,哪种方式更可取呢?以前我看过一个贴子,有人建议详细一点会比较好,不过这会给开发人员带来时间上的浪费。而如果太简单了,又怕人家说你太懒……总之众口难调呀。
在都能说明问题的情况下,哪种方式更可取呢?当然是越简单越好了。
不要浪费资源。 简单有简单的妙处,详细有详细的好处。不要阻碍了别人的发言哟;)
[ Last edited by Nio on 2004-12-27 at 16:46 ]
??
给领导看,越简单越好,给程序员看,越详细越好 TO:gubinger有道理~~~~ 是的是的,在下佩服 度量的问题,对于不同的人员分配不同的详细程度,我的建议是尽量详细,以便于以后对Bug进行分析和汇总。 同意楼上的意见!尤其对于同一产品的不同版本的测试有很大的研究价值!
看来,BUG报告写详细了还可以当历史参考文献用呢! bug的标题要简明扼要,并且要有让开发或者自己QA的小组的人,不用查看详细信息就可以了解到这个bug的严重程度,发生频率,测试环境,状况等基本信息。
对于bug的描述,要求做到条理清晰,不能太简单,但是也不能太罗嗦,标准就是开发根据你的描述可以很清楚的知道如何重现并且确实可以重现这个问题。
做到以上两点就够了。 对问题的看法如此老到,楼上的兄弟绝对不是新手!
不妨定义好bug的格式
强调敏捷方式 哦。详细好。 其实这个标题是无法回答的,这是个度的问题。衡量的标准是每次发出的bug list是不是会总有开发人员过来问不明白的事情,和写bug list的时候是不是自己都觉得自己很罗嗦。在这两者之间找到个平衡就可以了。 好不容易找到个bug,肯定要把它搞的比较详细才好! 其实,把这个问题提到标准上有点高了,对于文档是不是考虑下规范就ok了呢?
个人意见 我公司是这样的,给你参考
bug报告是由这两部分组成的:
先在标题中简单介绍出问题的模块,原因等等
然后在问题描述中详细介绍操作步骤,以及问题的日志等等 bug摘要中简单描述,bug描述中详细说明 学习中...........
页:
[1]
2