大家一定要重视缺陷报告的问题
从我过去的开发经验来看，只要是和测试人员发生矛盾，直接原因有99%以上是缺陷报告的描述问题导致的，心情好的时候我还会去跟一些来实习的学生说应该怎么写，心情不好的时候我就直接扔给测试经理告诉他我看不懂，并且我最反感的事情是：写了我看不懂的缺陷报告的测试人员跑过来跟我说：“你不明白的话我演示给你看！”开发人员没那么多时间给你一个个的bug演示给他看。缺陷报告里最基本的事情就是要把产生bug的操作步骤描述清楚，我认为有个很简单的判断标准，就是开发人员看了你的操作步骤以后是不是可以不和你进一步沟通就把bug重现出来，如果可以的话那么操作步骤部分的描述就没问题，如果必须要和你进一步沟通才能重现bug的话，这条缺陷报告里的步骤描述或多或少是存在问题的。
所以我今天上课的时候特别强调要说清楚word里添加的是一个visio的对象，如果你光说是个流程图，至少碰到我的话我肯定会问写这条缺陷报告的人：“你说的流程图指的是什么？” （上次作图的作业，某个强人是用excel画的。。。）当然你可以把你用的测试用例放在缺陷报告的附件里，但是如果bug list里附件太多的话，开发人员同样会失去耐心的。
其他像一些可能导致的原因之类的，一开始不会写不要紧，这些以后都可以慢慢学习慢慢积累，但是操作步骤的描述必须要写的很精确。
至于像测试环境之类的问题，我倒觉得老师上课的时候有点过于强调了。 通常情况下，如果工作单位是按照类似课堂里给的那个模板来写的话，不可能每条缺陷都要写什么测试环境windows2000之类的东西 （当然写上去也没啥不好）一般的bs cs的东西，一个模块多半是在一个固定测试环境里跑的。。。 浦兄的帖子
言之有理了~
Bug缺陷报告这东西,同样是描述一个问题,
简单的可以两三句话,详细的也可以写一长串
谁都不喜欢看到Bug,但我们首先要善待它,正式它,才能解决它.
不然,还没来得及理会Bug,测试人员倒和开发人员弄僵了...多不好... bug report的确很重要,但是真正想写好确实又不是很容易 我觉得更多的时候是因为这个bug是不是bug而弄僵的。这个可能是对需求，设计的理解不一致，这是我的观点。 原帖由 meng0819 于 2007-11-4 10:14 发表 http://bbs.51testing.com/images/common/back.gif
我觉得更多的时候是因为这个bug是不是bug而弄僵的。这个可能是对需求，设计的理解不一致，这是我的观点。
开发人员如果对bug认定有异议的话不应该去和测试人员去理论（这种争论通常是不会有结果的）
直接扔给teamleader或者manager就是了
所以制定一个合适的缺陷管理流程很重要
不管是多么小的团队。。。 看来测试人员的书面表达能力很重要啊 开发还是强势啊。我们这边即便写的很清楚了，开发有时候还是会懒得看要我们亲自演示步骤出来。唉。。。。。。 Try your better... 写不好就走人际啦,搞定就行啦,还是开发的牛,测试的牛在哪呢???
与开发工程师的交流同样重要
Bug report 是正规交流的一种，它需要书面的表达技巧。并不是具有高超的书面表达能力，就并不需要与开发工程师交流了。而和开发工程师的口头交流，你可以有两种选择：
一种是正规交流,(个人觉得比较适合群体交流，如会议等)
另一种可以采取非正规交流，非正规交流当然也是需要技巧的。
你的用词，你的态度，你选择交流的时机等等都是比较关键的因素。我觉得one to one 交流选择非正规的交流，效能要比正规交流要高。(当然你要和这个开发人员关系良好)。
缺陷报告固然重要，与开发工程师的交流同样重要。
[ 本帖最后由 王爬爬 于 2007-12-16 20:24 编辑 ] 大家的目标都是为了项目质量，所以恰当的交流是关键，对事不对人 其实就是简单的沟通加上测试人员的bug 描述要精准，至于具体怎么实施，要看公司了，只要按着公司的规章来做就ok了，如果你发现公司的流程有问题，你可以提出来，能解决就更好了。 如果就缺陷的需求和设计有分歧，让经理来处理，多半是SRS描述有问题 缺陷报告的描述的确很重要，尽量做到简洁、明了。有时候在工作中，也会遇到一些缺陷，不知道怎么描述好，但后来慢慢揣摩，也就会了 ，感觉截图有时是一个不错的选择。至于开发人员有那么强势吗？至今我还没遇见过，我到觉得测试显得更主动一些。 我觉得在缺陷描述上下功夫也在考验测试人员的定力，往往测试人员发现bug后马上写报告，这时候头脑正处于很兴奋的状态，报告的完成也很迅速，而这个时候恰恰是容易出问题的时候，因为bug他刚重现过，很多的部分他理所应当觉得就是那个样子的，殊不知这个时候如果让另一个对此一无所知的人去按他的操作去做却很难重现。所以我认为本身测试人员写完后，等心静下来后再仔细推敲一遍，检查一遍。
页:
[1]
