QA要不要追究bug的根原因？
大家觉得报bug是否需要追究bug产生的原因？ 我认为至少要给Bug分类，这样才能进一步分析缺陷的分布，产生原因 QA重视的是开发流程 测试人员一般只要说清楚Bug的产生过程及可（说清楚问题的表象），至于原因如果开发人员提出要进行分析，那只好分析了——关键是归纳。但做为测试人员我认为不必从程序以及设计上探就BUG产生的原因。 to kpxl：我觉得有必要，因为最后是要提交一份BUG报告的，如果只是罗列BUG，那缺陷检查报告岂不是太没有意义了？
little_student
严重同意你的观点，昨天就这个问题跟我的leader吵了一次，我觉得如果大家把眼光不是仅仅放在自己的测试部门上，那么找出bug的原因就很用，对整个项目的进度也很有帮助，对自己的将来也很有好处，自己也会有成就感！ 学着去分析BUG产生的原因有助于个人能力的提高，但从项目以及开发的角度看，测试人员分析BUG产生的原因对项目以及开发的作用不大，开发人员比测试人员更了解程序的内部情况…… 分析BUG是否要懂一些语言呢 明确测试人员的职责，或者说至少明确自己公司对测试人员职责的定义，可以要求开发人员在缺陷记录标明缺陷产生的原因，但是如果缺少开发经验，尽量不要把自己的精力太多的花在一些效益较低的事情上。 同意jackei的话，花时间做有意义的事情，这样会有效率的 如果是这样的话，BUG分析报告是不是不由测试人员来做，而是由开发人员做了？ 不知道little_student朋友所说的缺陷分析报告都包括什么内容？哪些应当有测试人员完成？哪些应当有开发人员完成呢？ 软件发行前，是要对软件中仍然存在的Bug和缺陷进行分析，以决定软件是否可推向市场或交给用户使用。——产品经理负责（很少会让测试人员做这样的决定）对BUG进行分析？——是要追究开发人员的责任么？我想是因为对BUG描述的不够准确、清晰，开发人员要求得到更为准确的描述而让测试人员“对BUG进行分析”吧？ 可能是因为我没有说清楚，我说的bug的原因不一定非得去看开发的代码，只是我认为测试人员需要定位bug产生的条件，如果仅仅只是报一个现象（特例），如果QA没有说明白，那开发根本不知道如何改。这样对整个项目的进度和质量的影响都是很大的。
例如，一个操作只有在数据量达到100以上或者在计算每个月1号的数据出错，这时如果QA没有写明白，就会耽误很多开发的时间。 kpxl所说的其实是测试人员是否应该明确缺陷重新的过程和方法。这是毋庸置疑的，是测试人员应当尽量完成的工作。看一条缺陷记录是否合格，开发人员是否可以通过记录中的描述在不用联系测试人员的情况下重新缺陷是一个重要的参考条件。 缺陷的类型，缺陷的分布规律，缺陷产生阶段这些数据很有价值吧？
应该由测试人员完成么？ 我认为还是需要进行缺陷分析的,这样才能够清楚产生缺陷的原因,进而进行流程优化和改进,提高组织的软件能力成熟度;而缺陷分析应该是测试经理或高级测试工程师的事情,因为一般的测试人员是无法胜任的;这应该是要积累多年的测试经验和高超的测试技术才行啊! 我觉得一个测试人员应该是一个优秀的程序员 我觉得非常有必要，本来测试人员的水平就比开发人员的水平高，只是国内的环境所导致这样，从长远来看，我觉得测试人员必须这样做，这目的：1、可以提高白盒测试的能力及开发的能力；2、能真正了解问题的所在；3、对开发的程序进行评估；4、对开发人员进行评估；5、让测试人员的地位大大提高.......现在我在公司都开始这样做，也要求我的下属都是这样做。
[ 本帖最后由 jackiepsq 于 2007-1-29 23:35 编辑 ] 普通测试人员暂时就把bug描述清楚、准确，然后不断积累经验，学习开发知识，最终是要发展到资深测试工程师的，那时就应该要进行bug原因和结果分析了
