如何写好测试报告(2)

　　回复：如何写好测试报告 曾盛开(技术部)

　　我看完了，总是觉得程序员和测试员之间在问题分歧上存在很多不同之处，其中包括个人专业知识的深度，对软件理解的能力，对业务、程序的理解能力，产品开发成本、周期与bug之间的协调。

　　诸多方面加起来，使我的脾气在沟通协调bug问题上变得很容易激昂，或者说发火，头脑发热。程序员多少都有些自大，不甘屈服的情绪，而且确实很多东西由于变得和以前写好、定好的需求有出入，导致做好的东西可能又被推翻。。。心里那种滋味很不好受的。。。毕竟每个地方和环节都是自己努力去想过的，有时候一个问题可能是花去几天时间确保那样做没有漏洞和正确。

　　我感觉到两个部门之间协调缺少更多互动，比如产品部在测试之前或者有空时候可以培训一下技术部，一般会测试哪些东西，如何测试的，这样子程序员心里多少有更多的底，在写程序的时候会有一种警惕性，从而产品部也会轻松一些，双方有利，应该是三方有利，公司最有利。。产品部也要考虑如何帮助程序员快速有利地处理bug，而不是一味为了bug而找bug，这根本背离了两个部门合作的基调;技术部也同样有责任去帮助产品部理解好系统运行的流程，找出隐藏的bug 。

　　另外，我想说的是在文档细节上面不要过分苛求，否则一方面是开发进度和成本，另一方面是使Xp轻量级文档开发流程又变成重量级文档开发，程序员为了文档忙于疲命。。我深有体会的，文档花去的时间几乎占用了1/4-1/3。

　　我觉得在测试的同事面前谈测试，有些班门弄斧，关公卖刀，但有些话不得不说，那就开诚布公拿出来，就算贻笑大方也好吧~~~

　　回复：回复：如何写好测试报告 李鹏

　　文档花去的时间几乎占用了1/4-1/3：这个时间我不觉得多，我觉得不够。花在需求定义，开发文档方面的时间应该是1/2以上

　　我觉得XP编程不适合我们，理由有三：

　　1、我们的8.0项目跨度有近2年，可以说是个中型项目，xp编程比较适合小项目(2-3个月)。

　　2、xp编程理论中基本上没有提到如何对程序进行系统的测试，而我们公司非常重视软件测试，程序员和测试员的比例近1：1。

　　3、xp中对文档的定义是“够用就好”，而在众多的工程理论(rup、cmm)中都建议要有详尽得需求和开发文档。花在需求定义，开发文档方面的时间应该是1/2以上。

　　回复：回复：如何写好测试报告 黄为东

　　技术部和产品部的斗争性，有它的积极作用，但确实存在两个部门目标不一致性的问题，既存在内部损耗，又存在被共同忽视的中间地带。

　　大胆设想一下，假设把技术部和产品部合并为一个大部，每个小组都配2个测试员，是否会更好呢?这样测试人员对本组开发人员的配合密切程度也许会更高。问题是，测试的专业性、分工性是否会下降?

　　该怎么组织，是一个大问题。

　　回复：回复：如何写好测试报告 蒲冬梅

　　产品只有足够人性化，用户才会乐意使用此功能，而不是买回去就将其束之高阁。文档只有足够详细化，才能为产品部测试提供准确的依据。因此就需要产品部与技术部能够有更多沟通，更充分的文档准备，更大的耐心。

　　因为最终目标我们只有一个，做出来的产品要对得起用户。因此我们需要彼此体谅，理解与尊重。

　　如果技术部有时间或是计划能够安排接受产品部的测试培训，我想我们部门每个同事都会举双手双脚赞成的。这样应该能减少很大部份测试的工作量。

　　关于为了找BUG而找BUG的说法，我觉得是很有必要就此申明一两句的。现在产品部最终提交到技术部的BUG都是有人负责审核的(BUG的定位是否准确，BUG的描述是否清晰等)。由于BUG的数量，这项工作其实是相当费时与费力的，因此曾停过一段的时间，但是为了提高BUG的质量和减少为了BUG而需要与产品部沟通的时间，这部份工作我们依然坚持在做。但是难免会有部份BUG在产品部进行准确定位是很困难的，而如果改为由技术部来定位则仅仅只是几分钟的事情，因此我们并未严格控制每个BUG都会精确定位，但是我们的目标是尽可能减少技术部为了BUG的描述或定位而进行多次反复的沟通。

　　因此就BUG本身的问题，也欢迎技术部能多多提意见，我们一定坚绝改正。

原文转自：http://www.uml.org.cn/Test/200512212.htm