测试人员在编写错误报告之前是否应该先与开发人员讨论错误？

#1 楼

作为具有15年以上经验的开发人员，我会说：请报告该错误。我宁愿在跟踪系统中拥有一张票，也不愿模糊地记忆走廊交谈或打断我正在做的事情。正如Joel Spolsky所说：


在任何给定的时间，我只能记住两个错误。如果您要我记住三个，其中一个会掉在地板上，被灰尘兔子扫到床下，后者会吃掉它。 …

程序员始终认为最大的错误事实之一是，他们可以记住所有错误或将其保留在便笺上。


（另一方面，错误通知书必须是好的。（Spolsky的帖子对此也有很好的入门建议。）含糊不清的错误报告是在QA和开发之间建立不良关系的肯定方法。 >

#2 楼

以我自己的经验，我发现这确实取决于与您合作的团队或公司的文化。

在一个具有良好沟通能力的团队中，并且每个人都可以很好地合作，您也许可以将开发情况告诉开发人员，他们会看一下，然后说会固定在5分钟内。如果更长，也许他们会要求您发送电子邮件。我自己，如果它是在我们当前的sprint中创建的，我并不担心将其记录到缺陷跟踪器中。如果当前正在生产中并且已修复，请始终对其进行记录。

在其他团队中，如果这种关系还不存在，或者即使文化有所不同，也可以非常不一样。在我目前的团队中，大多数开发人员甚至都不会看它，除非它被记录并被批准可以使用。

长话短说，始终记录它可能是一个好主意，但是，尝试与开发人员进行交流并更好地进行解释的做法很少会有伤害。

#3 楼

我们更喜欢先与开发人员交谈。然后，我们共同决定检测到的错误是否是由于处理过程中的一些古怪而导致的，甚至不是值得的bug；或者，如果值得，则我们将协商将错误输入到Bugzilla的人员（我们称其为“错误化反馈”）。 。

通常，开发人员更喜欢编写错误描述，因为这样他们可以更好地描述问题以及需要解决的问题。如果非开发人员输入了该错误，则有时会令人困惑，并且开发人员仍然需要消除误解。因此，仅当在测试环境（QA）中捕获到错误并且错误与当前迭代中的错误相关联时才可以修复错误报告，而该错误与当前正在QA中测试的错误有关（错误状态从“测试”转换为“开发”） 。即使对PROD代码进行的微小更改也需要具有错误号并具有优先级，因此，不幸的是，即使是微不足道的更改也可能需要5分钟以上的时间（除非与当前迭代相关的更改）。

还审查了所有代码更改，这也减慢了修复速度（但我们认为可以提高质量）。紧急修复，但随后我们添加了该错误并稍后填充了该过程。

#4 楼

不要立即与开发人员讨论缺陷。主要是因为上下文切换不利于他们的关注，并且可能最多需要5-30分钟才能恢复。
当我在测试当前迭代的任务期间发现缺陷时，我会在功能部件中记录缺陷并将功能部件移回到Todo阶段。我会在站立会议期间每天传达此操作。

除非此缺陷不是由当前迭代中的开发引起的。如果是较旧的缺陷，请向我们的错误跟踪器报告，并将其放置在积压的顶部。我更喜欢零错误政策。产品负责人应决定我们是否解决此缺陷。在计划会议期间将讨论该缺陷的详细信息。

即使您不使用Scrum会议，我也建议您找个好时机与开发团队讨论这些缺陷。当您的开发人员正在做其他事情时，请不要使他们烦恼。如果确定它是缺陷，则将其记录到缺陷跟踪器中。除非将其作为优先事项，否则尖叫和所有地狱都将破裂。 :)

#5 楼

我认为，亲自讨论事物总是很好。幸运的是，您的工作场所发生了一切。在许多公司中，所有通信仅通过系统进行，有时会造成很多混乱。您写的内容和其他人所理解的可能完全不同。

对于诸如开发人员这样的问题，我认为您应该开始提高说服人们的技能！ >

#6 楼

作为David所说的推论，测试人员具有与开发人员相同的内存限制。如果您不记录该错误，则很有可能无法修复。如果它不是严重的错误，则尤其如此，因为很有可能开发人员首先要解决严重的问题，并且暂时不会修复不太严重的问题。通过记录该错误，您可以节省下一位找到该错误的测试人员的时间，因为他们不必自己记录该错误。

话虽如此，打开缺陷后，与开发人员交谈以获取/提供更多信息，并可能将其也放入缺陷报告中也没有什么不对。 />另外，直言不讳，这里还有一个CYA因素：如果您报告的错误未得到修复并被释放，那么如果可以指出的话，事情可能会容易得多在错误报告中记录发现的错误。可能有人认为这不值得解决，或者可能受到时间限制，等等，但是从您的角度来看，能够指出错误报告要比说“是的，我明白了， ，但是...“

#7 楼

测试人员应该在报告错误之前先与开发人员讨论该错误吗？

根据我在多个不同组织中的经验，我认为给出当前问题详细信息的答案是“取决于情况”

这取决于一般因素，例如：


公司规模
开发小组的规模
当前截止日期
开发人员的位置
行业
开发方法，例如敏捷，瀑布等

以及诸如以下的无形资产上：


开发人员的个性
测试人员的个性
管理风格合作与竞争
开发人员在给定时间的忙碌程度

，以及有关所提交错误的具体因素，例如：


严重性
类型，例如设计，布局，数据库，工作流等。
对数据完整性的影响
对收入的影响
对用户体验的影响
对品牌的影响

在一天结束时，所有这些都相互作用，对于每个公司而言，您都必须在一个极端中询问所发现的每一个小（或大）事物，而在另一个极端中则永远不要问开发人员任何问题。 br />
作为一名前开发人员和当前的质量检查人员，我经历了几种情况（作为质量检查人员），在这些情况下，仅向开发人员显示和共享错误会导致他们提出其他问题，想要查看控制台， DOM，数据库等，我们俩都学到了很多东西。很多时候，这导致未提交错误。在其他情况下，该错误与其他信息一起归档，这些信息对于开发人员很有用。他们通常只是基于对应用程序的了解而注意到相关信息。

放眼大局是一件好事-QA和开发人员以及产品如何一起工作以就这些事情进行良好的公开对话和达成共识的方法。如果您对bug及其分类（通常是最有争议的项目之一）进行了很好的交谈，那么关于设计和功能的讨论通常会更容易。这还导致需要考虑其他因素，例如在敏捷环境中进行回顾，这为此类讨论提供了机会。如果您不敏捷，我还是会尝试回顾。根据我的经验，它们对任何类型的团队都很有用。

#8 楼

我想这将取决于所提出的错误。如果这是一个显而易见的错误（页面无法加载，基本功能无法正常工作等），那么我不会浪费开发人员的时间来确认它并编写文章。但是，如果遇到可能被认为是极端情况的事情，或者我不确定预期的功能（通常在负面测试中发现），我将与从事该特定故事的开发人员进行对话，并讨论该错误的有效性。

这将根据您要测试的产品以及公司的发展而变化，我们的质量保证人员与开发人员位于同一地区，因此使沟通更加容易。

#9 楼

这取决于...

与报告问题相关的间接费用是多少？
一些组织的企业流程很大，在问题出现之间需要大量的单击，必填字段和多个参与者是开放的，每个人的时间都做完了。如果重要问题淹没在未成年人（或未分类）的海洋中，您可能也看不到重要问题。

不跟踪问题会带来多少开销？
一个以上的人可能会偶然发现相同的“不是问题”问题，并提出相同的问题。跟踪它可以有所帮助-但前提是人们正在积极有效地寻找重复项。您实际提出的“不是问题”问题越难解决。

（从开发人员或专家那里）征求第二意见有多容易？
远程工作并通过邮件进行通信，您不妨归档一些东西。如果您正坐在将要解决问题的开发人员旁边，那么问问对每个人来说都是方便快捷。

您怎么确定这是一个错误？尽管时间也会发挥作用-您是否正在测试成品？还是您偶然发现了尚未完全解决的问题，并且在浪费时间报告那些尚未实现的问题。根据已提交的错误数量来衡量（是的，某些组织会这样做-请换工作），然后您要尽可能多地提交错误。如果您只关心问题的修复，那么不要跟踪从经验开发中知道的次要的-真正的-没有时间解决的错误是正确的选择。合规性和客户沟通也是因素。

结论

我认为该问题没有“正确”的答案-这取决于您的工作方式以及开发过程是什么样子。

作为开发人员，我个人（我喜欢敏捷宣言）（“在综合文档中工作的软件”和“在流程和工具上的个人和交互”）-因此，“报告”可以是口头的，除非要避免，否则应避免对工具进行跟踪。完成工作的最有效方法。但这只是一种意见。

#10 楼

如果有可能讨论该错误，则可能很有价值，例如，您将直接获得原因的信息以及谁将是该错误的受让人。但是通常这不是强制性的。报告错误后也可以执行此操作。

不管是否与开发人员讨论该错误都无关紧要，可能无论如何都必须报告该错误（如果这是一个真正的错误） 。

您描述的行为是即时主义，并且：


讨论此错误而不报告此错误，如果他们立即修复（例如，极限编程方法）。如果无法随时解决这些问题，则必须进行报告，以便开发过程中应有明确的任务清单。
如果您不确定这是错误的话，可以讨论该错误在其他情况（测试环境，数据等）引起的代码或错误中。我可以想象，这可能是由极其缺乏技能的测试团队造成的。然后找到一个高级测试人员，而不问他是不是开发人员。 ”，后来被人遗忘。不要做！这直接不利于测试人员的工作。
最后，如果这是一个错误，那么此行为可能会对开发人员造成困扰，开发人员不得不切换到其他问题，这只是您将来的错误的另一个来源。 。不要做！这直接不利于开发人员的工作。最好是请一些高级测试人员。

更好的选择是：



要有熟练，负责任，自主和自信的测试员。
先请高级测试员。如果需要，请与开发人员/开发团队负责人讨论该错误，并宣布将报告此问题。
如果需要，请与开发人员/开发团队负责人讨论该错误，并要求应指派的开发人员。 />如果需要，请与开发人员/开发团队负责人或开发人员讨论该错误，并要求您将更多信息放入错误日志中。
如果该错误尚未修复，请始终记录该错误/问题。 >

#11 楼

如果测试人员认为这是缺陷，则很可能是缺陷。开发人员可能是正确的，表明该过程已按预期进行，在这种情况下，缺陷可能存在于文档，用户界面或测试计划中。

即使发生测试错误，也应记录该缺陷。这样可以更好地确定存在文档缺陷的位置。

#12 楼

一定要出票。


如果该错误是“无法修复”，则可以将发现相同错误的另一测试人员或开发人员推荐给现有的测试人员或开发人员，并为开发人员保存一些错误时间。
如果该错误是5分钟的快速修复，则仍然需要5分钟才能完成，并且您必须记住要重新进行测试。如果这些小干扰加起来并且没有记录下来，那么类似的事情会使您和开发人员都觉得您整天什么都没做，这对士气不利。由于未记录任何内容，因此其他人也可能会觉得您整天没有做任何事情，这对性能检查不利。

制作票仅是一个问题，如果它给您或开发人员增加了很多开销，或者票务系统被破坏了。在那种情况下，解决方案是确认您的最高优先级错误是损坏的票证机制，需要立即修复。票务系统损坏的一个例子是，如果滥用票务系统以惩罚发现错误的开发人员。

始终举票的一个例外是，如果测试人员仍在业务领域中接受培训，在某些情况下无法分辨某种行为是否是错误。在这种情况下，他们需要询问某人，最好是业务方面的某人，但询问开发人员也可以。如果发现这是一个错误，请制作一张票。

就个人而言，我的偏爱是测试人员是否告诉我一个错误，但以已经创建的缺陷的错误号为准。作为一个团队的领导，我可以快速弄清是否值得一看，或者将他们指向罪魁祸首，或者为搞砸而道歉，或者告诉他们在故事XY之后重新测试，此时负责的代码会被抹掉。

就个人而言，在发送有关错误的电子邮件时我看不到任何意义。如果可以书面形式，请将其放入票中，如果没有，可以过来谈谈。

#13 楼

这取决于。

我发现的一些因素都会影响我是否正式举报：



发展方法论-如果我愿意在敏捷环境中工作，起初我更有可能与开发人员进行非正式的合作。在瀑布式环境中，我更有可能报告该问题，因为开发人员可能已经转移到其他地方，在敏捷环境中，我可能正在研究正在进行的代码。

团队位置-如果我和开发人员在同一个房间，那么我更有可能与开发人员进行非正式的合作。如果我在单独的位置，则更有可能进行非正式报告。

活动开发中的代码是否有问题？ -如果我正在寻找正在开发中的东西，发现有问题或疑问，则更有可能询问开发人员，或发送电子邮件或即时消息。如果他们能在一天内给我答案或解决问题，那通常就可以了。如果要花点时间解决这个问题，我会正式报告。

问题有多大？ -这很大程度上是一个判断电话-即使您打开新模块并遇到访问冲突，也可能不需要您正式举报：很多时候我都在查询类似的内容，并做出了回应例如“哦，可惜，我错过了，我马上就给你一个固定的版本”或“哦，是的，那部分还没有准备好。这些情况都不能证明正式的错误报告。

是谁开发的？ -可悲的是，并非所有开发人员都是合理的。在我的职业生涯中，我只有一个有问题的孩子-一个能够完全按照要求说的东西开发的开发人员，而那里没有的任何事情都不会发生，因此，如果概念草图中不包括两者之间的像素数字段时，将以无间距的方式构建字段，并且报告字段不可读的结果是“不是错误”-仅对于该开发人员而言，所有内容都已详尽记录或无法修复。对于其他人，我经常问他们是否想要将某些东西记录为错误，然后按照他们的要求进行操作。我会通过电子邮件或消息通知开发人员，让他们在准备就绪时做出回应，而不用中断流程。无论是正式的还是非正式的，都会以某种方式进行报告。

#14 楼

作为开发人员，我的看法是，即使不确定是bug，也要报告它。结果是（其他人已经提到了其中的一部分）。


如果不确定是否是错误，则您没有足够的产品知识来执行测试。这可能是由于多种原因，包括部分培训，不良的文档和不够详细的规格。
如果您立即中断开发人员，由于上下文切换（不计算对话时间）而导致生产力损失15分钟（不计算对话时间）。
错误报告始终可以按设计状态关闭。这样，就可以跟踪任何对话以及参与的人。可以提出一个相关的问题来改进文档。
如果是bug，那么在检入此修复程序时应提供一个问题编号。已经涵盖了，测试人员有责任创建错误报告。理想情况下，该报告应包含问题的描述（应该是普通用户会看到的问题）。
重现此问题的详细步骤
这些步骤的结果
预期的结果
也许是一些屏幕截图
如果日志文件或调试文件内置在日志文件中，则可能是调试文件产品
如果测试人员对原因有很深的了解，请提供其他技术信息。请注意，这与说明之间有很大的区别

#15 楼

如果明显且明显地违反了简单的接受标准，请尽快报告错误。随意绕开开发人员，BA或产品所有者。如果不这样做，则可能会引发实际上是功能的错误，或者延迟可能导致接受标准更改的重要对话，或者更糟的是，开发人员会选择“非错误”错误和“修复它，浪费了很多人的时间。

#16 楼

如果我的开发人员有空，我会先与他们交谈。这使他们有机会请求我可能没有想到的其他信息。

如果我的开发人员告诉我该区域尚未准备好进行测试，我告诉他们我将输入一个错误，以提醒自己一旦他们准备好就可以回来查看该区域。

如果我听说该错误不会得到修复或正在按预期运行，则错误报告将成为支持引用的工具，如果它成为调用生成器。

#17 楼

由于我是在对项目没有特定要求的团队中工作的，因此我始终与开发人员进行沟通，并向他们展示如何重现此问题。他们会承认的。有时他们会说，让我检查一下。回来时，他们会说，哦，我已修复，请对其进行测试。在他们修复它之前，我已经记录了问题并将错误分配给他们。我总是会说它是用于文档的

#18 楼

报告错误。质量检查人员的角色是成为独立的验证机构。了解产品要求并且注重质量的人。确保记录您的问题场景/重现步骤，以便对错误报告进行审查。有机会开始。然后，您可以短路所有指标，并允许开发人员玩系统，或者更糟糕的是，在情感上滥用质量检查人员。这会降低产品质量和士气。

为什么如此频繁地发生？因为不同的开发人员采用不同的错误报告。有些人大步向前，另一些人则将其视为批评或冒名顶替的形式，使他们感到羞耻和尴尬。当然这很荒谬，但是人是人类，来自各种背景。如果这是您组织中的问题，则需要解决。但最重要的是-请鼓励开发人员和测试人员遵循该过程。报告错误后，有足够的时间讨论问题。

#19 楼

为保持简洁，并与他人的想法保持一致-（在这里已有20年的经验）... 。
查找根本原因，如果可以

报告该错误。在系统中获取它。也许要进行一些有限的搜索以确保它不是重复的。
此时或在第一个能够
<-fin-> :)

时与开发人员联系

#20 楼

项目经理，设计人员，质量检查人员，开发人员和其他利益相关者；即使进行完美的分析，每个人对产品的看法和期望也不同。客观的外观确实很重要。因此，有时，尤其是当我要发布新功能或不确定任务要求时，我会要求质量检查的时间，并请他花一些时间。他可以发现我不知道的简单错误。开发人员不会被打扰，可以早日诊断并修复一些错误，现在质量检查在将来需要更少的时间进行测试；甚至可以通过这种方式避免发布错误修复程序。

但是标准的首选方法是报告错误。已报告的错误是官方的；它会被跟踪，修复和验证。没有人不会被打扰，没有张贴或待办事项清单，也不会记住。该错误记录在将来。

#21 楼

我认为您绝对应该与开发人员讨论。我在这样的环境中工作：我们的大型机通过MQ和其他中间件连接到各种前端（Web应用程序，POS机，智能手机应用程序）。仅仅因为方案失败并不意味着代码是错误的。也许中间件开发人员没有将正确的数据传递给前端。主机之间的XML可能是垃圾。我们的新事物是离岸测试人员通宵工作，因为他们不了解我们的平台或应用程序的工作方式，因此脚本中的左右所有内容均无法通过。太疯狂了与开发人员交谈将有助于将其分配到正确的区域，并确定失败的原因和位置。将其分配给随机开发人员是一种很好的方式，它可以绕过每个人，让所有人在没有解决任何问题的情况下说“不是”。

#22 楼

只是重复一些已经讲过的话，但是作为具有15年以上质量检查和开发经验的另一种声音，我将主要同意那些认为这一切取决于对您的公司/团队最有效的意见。尽管如此，我还是Dev＆QA之间公开对话的支持者，我个人认为拥有这一点的团队将在质量的整体共享所有权方面表现更好。以我的经验，在可能的情况下先与开发人员交谈是一种基本的方法，可以帮助您确认所遇到的错误（一些简单的示例可能是-主机因您不知道的预期原因而停机-或您认为与您无关的其他操作对您的测试有影响），还可以帮助您获取更多信息并缩小再现说明。通常，just-Dialog可以帮助你们双方更多地了解问题。

现在，这并不意味着“如果开发人员说您对需求有误解”，那么他是对的，您是错的。您似乎在担心是否应该与Dev谈谈，因为他们可能会不同意您的观点。我认为这与您是否应该首先提出问题完全不同。您不是开发人员的下属-您是他们的同伴。您经常会有意见分歧……无论您是否先提出意见。您将拥有亲自做事的人，采取战斗方法而不是一起工作的人（在开发人员和质量检查方面）……这只是作为一个良好的质量检查工作的一部分，您可以尽可能地应对这些情况。有时，这意味着尝试与开发人员找到共同点，如果这不起作用，则可以采取其他方法（首先与团队/经理建立共识，也许与开发团队/开发团队经理的其他成员尝试建立共识），等等。底线是-如果您强烈认为自己所看到的是一个错误并且需要注意（或者至少要进行记录和跟进），并且可以提出自己的理由，然后将其归档并支持。 br />
最后-我只想说，有时候这只是常识。有时，您可能只知道开发人员很忙，不应根据所查看内容的严重性而烦恼-而是将其归档。或者您知道这是一个问题，只需归档即可。这里确实没有是非。如果您的团队没有定义任何内容，则可以同时尝试一下，看看能为您带来最佳结果的原因。

评论

---

我还要说-首先提出它的一个好处是，他们很难看到一个他们不同意的错误突然冒出来，就像“哇，这很蠢，我要关闭它” 。如果您已经讨论过，即使他们仍然不同意，他们通常会觉得他们应该在尝试关闭它之前再次与您交谈。如果他们不这样做，就说您有一个不遵守质量检查的开发人员问题，这是您首先要解决的问题。

– ryoaska
16年1月28日在22:39

---

#23 楼

是的，开发人员将可以建议如何进行进一步的测试。重要的是它是在编写报告之前。不是。开发人员不负责确定是否已删除错误。

#24 楼

不能。测试人员不应与开发人员讨论，因为他们会说服测试人员其他人员在我们将其提交漏洞跟踪器之前可以修复该错误。如果开发人员喜欢这样做，那么测试人员就无法在组织中探索其小/大问题。

#25 楼

最佳实践是首先报告缺陷跟踪工具中的错误。

在与开发人员进行“缺陷审查”会议时，讨论所引发的bug是否有效，设置严重性和优先级是否适当以及开发人员要重现的细节等。 br />
缺陷跟踪工具还提供了注释部分，开发人员可以在该部分放置注释，同时将错误的状态更改为拒绝，推迟，重复等。

#26 楼

如果可能的话，不要以为您是测试人员，首先请以为您是一个努力工作以使事情正确的团队成员。开发人员可以提出有关如何更好地测试特定模块的建议，同时测试人员可以展示如何纠正缺陷。开放自己寻求新的建议和分享想法。

与其他所有开发团队隔离开来的测试团队无法产生成果。当测试人员在开发人员之间调整自己/发展彼此之间的关系，建立良好的团队环境以及所有开发人员和测试人员一起工作时，对于双方来说都是双赢的情况。首选敏捷方法，一起工作，进行配对测试，与开发人员一起工作，经常讨论和开会，减少文档记录，同等重视和尊重每个人的工作。