对[原创]Bugs 的有效交流和管理[翻译] 的一点点补充
标题标题的名称顾名思义，很简单，我就不多说了。要注意的是下面两个方面：
1.从标题上知道它所要说的内容。理想状态下，bug标题不应超过50－60个字符
2.关于bug另外一个重要的方面是，它不应有任何主观色彩的缺陷描述。
总结
总结在于简明扼要的说清楚问题即可。太过冗长的句子，会让人看不懂而心生厌倦。
再现的步骤
提供如何再现bug的确切的信息，确切的信息的含义是指， 使用恰当的技术术语和命名约定，清楚的提供信息和有条理的标记相关的步骤。
在提交bug之前，扪心自问，这个bug是否能被其他看了这个bug描述的人再现出来。
观察结果
所有与软件运作的结果有关的未实现的功能必须被提及，不能有任何遗漏。比如当你在做一些 明确目标时遇到一个错误的对话框的情形，你的任务不是描述错误本身而是提供错误对话的内容。
预期结果
无论规格说明书如何有用，它的变更是非常频繁的，在bug描述中写期望结果是非常困难的事情。测试人员必须从有相关知识和经验的开发人员处得到你所要测试的项目指导性的内容。也可以从前面已经发布了的版本中或者可以使用的商业标准应用中获取有用的信息。
其他信息
其他信息就是非常重要的，因为它可能会帮助开发人员建立与真实问题的某些联系。
注释/历史
当你需要了解一个已经离开组织的测试人员的工作时，你不得不完全依赖讨论历史，但它是否真的能让你明白如何进行下一阶段的工作吗？
当一个已修复问题从开发人员转到你这里，你需要进行验证和关闭，不要忘了在关闭这个问题时写上注释。
附件
测试文件应该尽可能的付在bug描述后面。这种方法证明对于问题存在的证据是非常有效的，它同样也节省了开发人员不得不浪费在再现错误上花费的大量宝贵时间。
里程碑
应该关注是在哪一个阶段发现的bug。
严重性和优先性
严重性和优先权的客观分配在理论上是可行，而在实际中，大多数情况下，取决于个人主观理解。所以想要避免主观性似乎是行不通的。
成熟的公司对于他们组织明确的活动相应的严重性进行定义。这些公司对于如何分配严重性有他们自己的指导方针，这些方针是提供给测试人员的，同时这些规则、方针在项目需求中是可裁减的。每天结束时，项目组的所有测试人员把所有的缺陷以严重性分类。
级别有：
.尽快修复
.高
.普通
.低
严重性和优先级的定义通常取决于所在组织的测试活动的本质。
质量分析报告
简明的bug描述
不要夸大所发现的任何很小的问题。
一个非常详尽的和象说故事一样长的描述都是不适合于bug描述的。
不必要的或不相关的信息都是不应该存在的。
bug隔离
测试人员应该能放大潜在的问题或原因，并提供给已经发现的缺陷逻辑理解。
有时，bug隔离是非常难实现和理解的，因为设计到无数因素，这些因素以一种不确定的方式产生程序的问题。bug隔离需要深入考虑和理解你所要测试的应用。
挑选bug与覆盖bug
要善于将单个的BUG和同一类的BUG区分开来。
每次一个bug描述应该只关注一个明确的问题。那些容易造成混淆的相同问题应该汇总在一起，而这些问题也造成重复提交问题的时间浪费。同样，如果在一个应用中有大量的问题，但是所有的解决仅仅是修改一个代码结构的细节就可以解决的，那么采取的方法是将这个bug覆盖而不是记录大量的bug。
比较分析
好的比较总是使你的用例更有说服力、更有效、更令人信服。有时，对于测试人员来说，用提供确切的行为来类推支持他的主张是非常必要的。当你有当前正在测试项目的较早版本就会更容易，或竞争者提供的类似产品，这种产品已经占有一定的市场份额或者已经形成一定的标准。
区别重要的bug
重要的bug是就算验证基本测试用例或者用例丢失时也可以找到的bug。
认真的思考
重复的bug
产生许多重复的bug导致了在应用条理性方面的低效率和不成熟的思考，这种情况不可能完全避免。注意力应该放在识别重复bug上。
将重复的bug减少到最少的一个方法是仅仅使用关键字查询数据和查找是否已经有记录在案的类似bug。
有得到修复的bug
依靠用户特殊的需要产生的市场，应用程序中严重性高的bug可能被延期，而小的那些bug却得到修复。要记住的是修复一个bug是一种商业决定，测试人员应该尽可能站在组织的角度来理解用户工作流。
不是bug而是设计问题
当你提交一个bug但开发人员把它退回，并付上“不是bug”或给出它是正确的注释。
测试人员所要做的就是尽可能找到规格说明书提到的功能或者其他的开发文档来支持，甚至是设计的人员的支持。
自动修复的bug
过去存在的bug，没有进行修复就自动的正确修改，开发人员并没有对这些bug验证进行标记，但是这些bug却已经被修改了。
其实如果知道开发人员不可避免的重写他的代码，开发人员修改代码路经，修改相关性等等，结果就产生了这些不可思议的事情。因而已经存在的bug 消失而新的bug又出现了。 测试人员需要认识到并理解这些变化的原因，同时为这些消失的bug做好准备。
bug往返
由于缺乏足够的信息，有时候在测试人员和开发人员之间一个bug的提交过程需要重复多次。测试人员提交bug描述，开发人员添加一些信息然后返回该bug，测试人员再添加一些信息然后再返回给开发人员，如此循环多次。这样可能会引起bug描述过程的混乱。
如果bug在测试人员和开发人员之间多次往返，会浪费大量的时间和资源。为了避免这样的情形，测试人员应该认真地在提交bug的时候同时提交所有与bug相关的对修复bug有用的信息。测试人员需要保留关于问题的所有版本，并且随时随地的准备提供完整的信息给需要的人。
个人和情感状态
测试人员要避免唤起激烈的情绪，特别是生气和好斗性的情绪。另外，测试人员永远都不要轻视代码或者发表相关的批评。
测试人员和开发人员之间有时会存在一些概念上的误会。最好的解决方法是通过口头交流进行解决而不是把这些问题反映到报告中。
提出警告
在一个复杂的应用程序中，由于数据库中存在大量的bug，虽然bug的优先级和严重级在bug描述中不是比较高的。测试范围的易测性和测试范围变的非常困难，需要测试立即与开发人员进行沟通。
整理所有可测试的bug
测试人员的职责不仅仅是在遇到缺陷的时候提交报告，也需要对每一个bug的修复进行跟踪，并随着有秩序测试活动延续，根据bug的优先级顺序进行验证。给出测试的应用程序修复质量和相应走向的一个清晰的曲线图。报告中需要紧密监控发现的bug和关闭的bug的比率。
bug搜索
组织多人参加的bug搜索组能够帮助找到那些隐藏的bug。
学习以前的bug报告
如果你的手边有可以用的有经验的测试人员以前写的bug报告，把它们拿来查看和学习是非常好的习惯。
不必要的工作流
后期的发现
后期发现的bug永远也不应该忽略，同时如果它的bug描述是可取的，将立即引起管理层的关注。
低bug数
测试人员需要关注检定缺陷的质量多于简简单单的找到细小的或困难的bug。如果保证了质量，就是低bug数也是可以接受的。
发现已经修复停止的bug
许多软件项目中，对于所有关闭的bug来说完整回归，仅仅是确保关闭的bug不在出现。由于时间限制尽管完全回归不能实现的很好，一般地，在项目里程碑发布之前，都必须要特别注意。跟踪关闭所有的bug，如果对早期的bug有疑惑，尽早再次检查它。
漏掉而用户发现了的bug
注意力应该放在尽可能以有效的方式来管理你的bug上。不同的方法导致不同的想法和对不同测试环境的挑战。测试人员的目标是正确处理这些问题。 不错，支持一把。不过，如果放在缺陷跟踪版更合适。^_^ 说点不同的意见，感觉内容好多，如果不是熟悉缺陷的跟踪的话，感觉好像都是需要记入问题报告中的，能否把叙述的内容分类让看的人思路更加清晰，以上只是个人在读的时候的感觉，希望不要生气，我对测试也是刚入行，以后请多指教，文章不错，给我不小的启发，谢谢！ 很不错 谢谢！ 这两篇关于bug管理交流的帖子看下来，我收益非浅，谢谢楼主！ 同楼上想法！ 很好啊,值得学习 好文章.版主辛苦了. 好文，值得一读
这需要研发部和测试部的共同配合。。。。
但是一般可能性不大...
谢谢版主,确是好文 不错的问章,thank you 斑竹，大家谁还有好的文章拿出来大家分享一下了！：（ 写得不错，受益非浅 感觉不错，多谢！好文
我也感觉不错，对我已有几年的测试经验还有不少借鉴之处，谢谢 如果RD认为不是BUG,而我认为是,我怎么说服他们? 不错。深有体会。支持。 没有那么容易，如果有Bug交流与处理量，此时的公司就有一定的流程与部门界线了有一定困难的
不过，楼主对于Bug的处理让我学到很多
好帖！！！！！！！！！！ 太好了，这几天一直在找这方面的资料了，
如获珍宝呀，
多谢楼主。。。。 这些解释队我帮助很大，谢谢斑竹！
页:
[1]
2
