要求开发人员明确说明错误的修复方式

#1 楼

我将假设您的开发人员正在某个地方进行文档记录，因为我还将假定他们是关心良好开发实践的优秀开发人员。作为开发人员，我坚信应该让开发人员用代码以外的语言描述他们所做的工作。它不必很全面，我相信他们（如果还没有这样做的话）应该花些时间和精力来确保其他人无需阅读代码即可了解他们所做的更改。俗话说“如果您不能简单地解释它，您仍然不理解它”，那么如果您接触代码，那将是一个危险的地方。

这可能很简单例如编写良好的提交消息，或者是否涉及代码审查，请提供有关更改内容和原因的简短摘要以及代码审查。这样，代码审查工件将成为测试人员参考的有用工具。

如果除了最琐碎的错误以外的所有错误（例如“字段X的标签拼写错误”），我也将感到惊讶。 ，一个好的开发人员在调查和发现错误后并没有在错误报告中添加任何有关根本原因的信息，也许还包括对正确修复程序的解释。 （如果涉及到变更控制委员会，通常首先要证明有必要修复该错误，通常值得一试，而后根据每个工作的粗略描述来描述几种可能的修复。）产品已经编写了设计文档，我还希望某些错误需要对设计进行更新，特别是如果必须进行一些重大更改以消除故障模式的话。

我将不得不想象他们正在以上其中一种中捕获所需的信息（提交消息，代码审查或设计文档，尽管您的问题暗示他们没有将其放入错误报告中）。可能很简单，就是对他们的其他工件进行摸索，以找到这些信息，或者与开发人员交谈，看看他们将这些信息放在哪里。他们将这些信息放在头脑之外的其他地方，只是问您在哪里可以找到它。如果您的开发人员除了代码本身之外，没有对他们所做的更改留下任何面包屑，我相信他们是可怜的开发人员。这是牛仔编码。在那种情况下，那么似乎对基础开发实践进行了一些介绍是合理的，但是除非他们希望成为优秀的开发人员，否则很难驱使它。

#2 楼

请求质量检查和开发部门的高层管理人员开会，并说明您所要求的目标。我认为您在问题中提供的描述是解释问题原因的一个很好的开端。 QA希望更好地了解bug的修补程序，以便我们能够：


更好地测试原始问题
更好地识别和测试其他可能受到影响的领域
更好地了解运行中的系统
在测试中更加高效>总是有两个方面...开发人员打算修复的内容和实际更改的地方。理想情况下，这两件事是相同的，但质量检查不会有工作。这并不是说DEV不好或很笨。许多系统非常复杂，我们正努力以迅捷的速度发展。犯了错误，并且DEV和QA需要共同努力以增加发现的缺陷数量并减少逃逸的缺陷数量。

有时不得不向别人解释一些事情会使您想到自己所做的事情以前没有想过。向QA解释它可以使他们更多地了解各种系统以及它们如何相互作用，从而使他们成为更好的测试员。高效并检测更多错误。我认为每个人都会落后于此。我认为问题与询问的措辞有关。


尽可能详细地说明导致问题的原因以及他或她如何解决问题


我认为在某些/很多想法中，每个bug都需要进行大量的“额外工作”。我希望在错误中进行简短描述。如果质量检查人员查看简要说明并需要更多信息或有更多问题，他们会与开发人员联系并获取该信息。我认为这是每个错误中信息太少之间的一个很好的折衷。 br />

修复程序是什么
修复程序影响了其他哪些区域
修复程序可能影响了其他哪些区域
是否有任何特殊的测试指南？是否有有关此修复程序的问题？测试的重点是什么？

我认为这不是DEV的大要求。我认为这是他们在流程中的工作。当他们完成错误修复后，他们会回顾更改的文件，并将修复总结为上述4个问题的答案。实施几个月后再见面并进行审查。 DEV是否始终如一？工作太多了吗？我们如何才能最大程度地减少DEV开发人员需要输入的文档以及QA做好工作所需的信息。

我不认为答案是让QA自己查看代码更改。然后，您假设QA知道DEV日常工作的这些复杂系统的所有方面，我认为这不是一个合理的问题。

#3 楼

大多数其他答案表明，要在测试中取得更好的要求是理解代码-但这需要大多数QA测试人员不具备的技能。不需要深入了解代码。在大多数情况下，对于QA而言，代码更改过于复杂且晦涩难懂，以至于无法从仅详细阅读代码的情况下瞥见任何相关内容。 ）浏览代码更改，而不是了解更改，而是查看更改影响了系统的哪些部分（哪些网页，处理哪些功能的库等），这些都是测试的不错选择。这只是对Bug票证中的更改/测试的描述的补充。

以我自己的经验，尽管我在少数情况下仍能够读取代码（作为系统的前开发人员）并建立一个测试用例来使修复失败，并向开发人员证明修复错误，这是非常罕见的情况。

您的开发人员应该已经使用代码审查工具，因此也应该使用它（如果您认为票证中的变更描述不够充分）-如果不行，代码审查是最便宜的方法提高代码的质量。

不确定组织中的代码状况如何，但是在我们的组织中，每个错误都有一个拥护者（“内部客户”）与其他专家一起写出如何准确测试更改（除了开发人员添加的单元测试之外）。识别什么和如何进行测试是“错误拥护者”的责任（而不是QA的责任）。该信息会保留下来，有时用来代替文档，以便更好地了解特定情况下的系统行为。

请记住，质量检查不是在事后保证质量，而是要保持一致的过程。所有相关方之间的沟通，以将质量设计到产品中，并提供有关质量状态的信息。

质量检查的责任是确保遵循约定的过程（高级开发人员审查了代码，编写并通过了单元测试，通过了回归测试，开发人员和拥护者确定了应该测试的内容），并按要求执行了要求的测试。质量保证的任务不是要取代开发人员和问题专家所拥有的所有技能和知识。质量保证的任务是确保所有相关方都参与了该过程，而不是解决这些方的问题。

#4 楼

根据您的质量检查团队的素质，这个问题似乎有两个答案。

如果您的质量检查团队可以阅读代码，他们可以查看修复了错误的提交-如果您使用版本控制系统。这样，您的团队可以自己分析更改，这意味着您不需要其他人提供任何信息或时间。

如果您的质量检查团队无法读取代码（或至少只有很小一部分代码）整个），您应该不断要求开发人员提供更多信息，以便您可以从现在开始更早地发现错误。如果您继续为开发人员提供良好的论据以为您提供更多信息，这将有所帮助，因为对于他们而言，由于错误已得到修复，这可能会浪费时间。可能的参数有：


改进回归测试。如果您知道错误是由f.e.引起的如果没有为最后一个元素执行for循环，则将向您的回归测试添加更多测试用例，以涵盖该内容。
改进自动化测试。与上述观点相同。
将帮助您在下一个漏洞中更早发现这些错误，从而使这些漏洞在下一次更早地得到修复，这意味着该产品可以更快地发布。
您可以执行“白盒测试”旁边的“黑盒测试”。如果您知道代码的哪些部分已更改，则可以使用更适用的不同测试技术。如果您使用黑盒测试技术，则将花费更多时间（大部分时间），因为您不知道代码库的哪些部分已更改。如果使用白盒测试技术，则可以在代码库中已更改的那些部分进行更精确的测试。

当然，仍然可能是开发人员不相信并且他们确实下次不提供额外的信息。但是，尝试将这种节奏融入到流程中，有望使他们将来（在您需要询问之前）预先做好准备。

#5 楼

与许多回答说测试人员可以检查源代码的更改相反，我在多个地方工作，测试人员无法访问源代码。他们唯一发生变化的信息源就是机票中的任何信息。

在这种情况下，开发人员绝对必须向测试人员提供有关他们所做的更改的信息，并涵盖以下内容：


更改会影响或应用哪些配置设置至。许多错误仅在特定的配置设置下发生，但是我已经看到首次通过修复会由于代码的假设而导致配置不同的问题。
应用程序的任何相关部分，开发人员都知道会受到影响。有经验的测试人员将大致了解该软件中的哪些模块是相互关联的，但不能保证开发人员不会看到细微的依赖关系，但测试人员不会知道。
开发人员可能遇到的任何相关问题修复或重构为错误修复的一部分：如果正在进行的重构工作中，这对于测试人员来说至关重要，因此他们也可以检查其他更改。使用此信息向票证添加一组注释，而不是让测试人员挖掘代码以找出可能受到影响的原因，这仅仅是因为开发人员可以在处理项目时做这些注释。

我认为这取决于各方相互尊重和努力。与我合作最好的开发人员是那些向我提供有效定位测试所需要的信息的人，然后当我发现与我的期望不符的东西时与我一起工作。

#6 楼

我是一名开发人员，我确实会在我们的错误/功能跟踪系统中添加有关完成某项的其他信息，只要我认为这可能有用即可。我主要针对测试人员，但是许多其他开发人员也可能会用到相同的信息，这些开发人员遇到了我接触过的一些代码，并想（在阅读源注释之后）进一步了解这样做的原因。
对于一些简单的修复，确实没有更多要说的。 （问题描述：“ foobar图标是绿色的，但根据要求它应该是青色的。”解决方案：“将foobar图标的默认颜色更改为青色。”）但是对于大约所有缺陷修复程序的大约一半，我的分析和/或修复程序值得注意。毕竟，我是花时间最多的人，目的是了解原始问题，确定确切的解决方法，并分析我的更改是否可能会影响其他任何事情。测试人员能够理解代码，但是即使对于确实读过代码的人，对错误和修复程序进行简短的英文说明也很有帮助。有时，在复杂的代码中，所涉及的事件序列可以通过许多不同的功能和存储的数据运行，但只有一个行修复程序。查看该行（以及所有添加的注释），您也许可以看到更改为什么是“正确的”，但这并不总是很明显，这与所观察到的错误有何关系。

因此，您可能会尝试提出一些问题，以更加准确地了解所需内容，而不只是询问“更多信息”：

是什么情况导致此错误？

这与“如何复制错误？”稍有不同。错误报告通常将至少包括一种重现错误的方法，并可能包括一些可能引起相同问题的方案。但是很多时候，当我发现问题的原因时，我会意识到它实际上比所报告的情况更普遍，并且/或者只会根据报告中未描述的其他事情而发生。例如，一个错误报告可能会提示您在“对小部件A执行操作B，然后对所有C执行操作”时重现了该问题，但实际上，当您“对某类特定动作执行A'然后对所有操作执行具有属性B的小部件，而至少有一个D处于活动状态”。

或者更好的是，我可能会从一个似乎经常发生但不可靠的问题开始，并提出一种重现它的方法始终如一。

这对于测试人员正确测试更改的范围至关重要。例如，如果我如上所述地描述了原始错误，那么测试人员可能还想验证问题E和具有属性A'的小部件的采样是否已解决，并且系统可以在相同情况下继续正常工作，除非没有D处于活动状态。

您可能会重新表达以下问题：“还有其他方法可以重现此错误吗？”。一个子类别的问题是：“是否存在任何会影响该错误的现有配置设置？”

除了所观察到的错误之外，是否还进行了其他修复？

当然应该进行完全无关的更改不能附加到同一票证上。但是，可能有两个不同的功能正在使用一个通用函数，该函数在每个功能中都有以不同方式体现的错误。或者修复程序可能涉及以某种方式重构某些代码，从而解决了工作中发现的多个问题。

绝对应该使测试团队知道是否注意到了诸如此类的任何积极“副作用”，以便他们也可以进行测试。

哪些功能可以执行任何更改，添加或删除的代码？

这是上一个问题的反面。有时，代码更改会带来令人愉悦的副作用，但是几乎总是存在任何代码更改都可能破坏其他功能的风险。开发人员应做出合理的努力来分析更改，以尝试确定哪些其他内容可能会受到不正确的影响，但是可能会遗漏某些东西，或者只是得出结论认为剩余的风险是可以接受的。对于相同的更改代码，可能有必要关注这些功能的任何自动化测试，和/或为这些功能运行一些简单的回归测试。

在一个极端情况下，答案可能是“修改了核心库功能，因此可以在任何地方看到效果”。 （也许修改“显然”是正确的，但是其他一些代码意外地依赖了旧的不正确的行为...）运行您已记录的所有手动回归测试和/或可以想到何时进行此类手动回归测试可能不可行事情发生了，但至少您会意识到这是一个可能的问题。

是否有任何与错误或修复相关的非用户工具？

我们开发人员喜欢创建或找到获取有关软件运行状况的各种信息的方法，这些信息对最终用户而言并不可见。这包括日志输出，执行跟踪以及实时检查内部数据的方法。

其中许多事情都需要配置或以其他方式激活，甚至可能需要外部程序。但是它们通常相对易于学习使用，因为其主要目的是使我们更容易使用。

只有用户可见的行为才能真正定义软件是否正常运行，但有时以这些方式查看软件内部结构可以帮助更准确地验证修补程序或功能是否按预期工作。特别是，在某些情况下，您可能会期望输出有所变化，但是该输出中似乎存在不希望的模式。由于可能无法通过一次尝试来判断是否有任何错误，因此研究计算输出的步骤可能会更有用。

另外，了解一些此类工具可以帮助您当编写新的错误报告或未通过修复或功能时，软件系统可能会派上用场。如果您从这样的工具中收集到一些数据，这些数据以最佳估计的方式与实际观察到的错误高度相关，那么负责研究该错误的开发人员可能会感激不尽。确切说明哪种信息对您有用，为什么会说服开发人员开始尝试提供这些信息。

如果开发人员仍然拒绝更改，则您可能想讨论这些与希望获得更多信息的相同原因。经理，因此可以建立对流程的期望。这可能或多或少是正式的，具体取决于团队的规模和风格。

#7 楼

您不能期望开发人员重复他们用自然语言编写的代码。他们不需要在意的时间和精力。充其量，您会得到两个句子，几乎看不到任何内容（通常-我曾经遇到过开发人员的单行注释触发了一些警钟的情况）。

好消息是：有一个以测试人员身份检查修复程序的一种非常简单的方式。 （当然，您在问这个问题的事实使我有些担心您没有这种可能性）。一个警告是您必须能够阅读代码。

假设您的团队使用代码版本控制，开发人员的每次签入（TFS中的变更集，GIT中的提交）都会获得一个唯一的编号。如果开发人员在签入期间创建带有缺陷的链接，您甚至会看到该链接也出现在缺陷项中。如果不是这种情况，您可以随时查阅提交历史记录，在其中可以看到与修订有关的签入。

一旦知道了编号，您只需打开它并查看代码更改即可发生了。以这种方式查看比较之前/之后，确实可以给您作为测试人员的出色见解。它还可以极大地帮助您减少和集中测试工作，例如如果您在代码中看到一列硬编码值，则在通过GUI尝试之前就知道是否缺少某个特定值。来自开发商。当然，在查看了变更集之后，您总是可以向开发人员询问一个更具体的问题，比告诉我您为该缺陷所做的一切以及如何以及为什么做的要容易得多。

#8 楼

这里有两个问题：

1）我们如何说服开发人员测试人员需要知道他们所做的更改？

2）他们传达的最佳方法是什么？该信息？

我将重点关注2，因为这就是我们正在做的事情。我可能会回过头来谈论1，尽管这里有很多好的答案。功能测试。 （如果您正在执行功能测试，但不了解更改的内容，那将是一个更大的问题。）我假设您正在执行集成测试/系统测试/将系统作为最终用途的某项工作-用户。

因此，我们要做的就是邀请参与测试的每个人都进行代码审查，然后他们重新组织代码审查，以便最初的几分钟专门介绍更改的内容，然后代码审查的其余部分将深入研究代码。因此，我们可以在开始的几分钟内到达那里，了解问题所在，所了解的级别以及发生了什么变化。这不仅可以帮助我们更好地了解系统，还可以帮助我们验证修复方法，因为有时外部症状和内部原因不容易联系在一起。

#9 楼

我认为要求开发人员总是添加非常详细的报告是不合理的。


全面文档中的工作软件


确定要始终使用数据吗？这听起来像是文档浪费。我读此书是因为我们的质量检查人员希望您记录所有可能的信息，因为以防万一我们可能希望在某个时候使用它。如果是，则：


如果您真的有兴趣或打算对信息做一些事情，请亲自（或通过聊天）询问开发人员。解释为什么需要它比总是要求始终提供更好。充分的理由是风险评估和/或进行根本原因分析。
与开发人员一起进行根本原因分析。现在，您可以记录原因和采取措施，以防止将来再次出现类似问题。即使开发人员确实尝试提供所有内容，您所要求的移交数据也会丢失50％的信息。
链接会提交给bug-tracker-id。大多数（如果不是全部）错误修正仅更改了几行。测试人员现在应该可以扫描其他系统的依赖关系或风险。与DEV团队坐在一起。正在与DEV团队交谈。

#10 楼

我知道您来自哪里，问这个问题。

作为测试人员，了解此修复程序对我们而言非常重要。不一定来自编码pov，而是要尽可能了解它，因为我们知道如何评估更改是否会对应用程序的其他领域产生影响。我们已经成功地与开发人员交谈并陈述了以上内容（有些人理解别人会更加顽固，不幸地不能赢得所有人）。

另一方面，我们有很多作为测试人员，我们可以了解SUT特定区域的某个修复程序是否有可能导致代码退化。

持续集成意味着我们应该可以访问DEV团队正在执行的提交/分支/部署，并且可以看到所做的更改以及受影响的区域
某些工具就像TFS和MTM一样，可以扫描所做的更改，并可以为您提供涵盖受影响区域的一系列测试。足以自己找出来。当您可以自己找到东西时，不要依靠DEV喂食您的东西，对我来说，这会让您感到更加满意（您可以学习很多）。

#11 楼

因此，实际的问题是：


我们如何说服开发人员以更详细的方式解释错误修正？


在我认为说服某人的最好方法是不要试图说服，只需将它们放在您的鞋子中即可。例如，有时，例如在版本发布之前，您可能会要求经理在验证已关闭的错误方面获得帮助。经理将指派开发人员验证错误，以帮助质量检查小组。当开发人员尝试重现和测试错误时，他们将了解票证或提交消息中缺少哪些详细信息。

所以我的意思是，

不要说服，让他们加入你的行列。

#12 楼

这是一个沟通问题。

敏捷宣言中定义的


过程和工具上的个人



大多数答案指向工具，代码和过程。我会要求：

有关修复程序详细信息的定期面谈，以便您了解修复程序。

如果您有太多时间退回有关抽出时间来解决问题的信息，然后，作为一个团队，您需要详细讨论为什么需要这样做。这就是回顾在敏捷环境中的作用。如果在尝试并没有使事情有所改善之后，现在该与管理层进行讨论了，但是要当心：如果他们“解决”了问题，您可能还启用了命令和控制功能，这在大多数工作场所都是一个大问题。 br />
随着时间的流逝，您会发现具有讽刺意味的是，当质量检查人员问“固定器”的问题时，它将开始出现开发人员未曾考虑过的问题……他们没有遇到的条件考虑...有时会导致“哦，是的，我也解决这个问题”。

这就是通往质量的道路

#13 楼

“策略的本质是选择不该做的事情”-Michael Porter

QA此处需要的是洞悉错误的潜在模式，而不是个人修复的实质内容。
抽象与具体
可以通过设置正确的期望值，即需要什么样的信息以及精确的精度，建立一个坚实的共同点（可能通过一次会议），从而对双方都互惠互利目的。
这将有助于避免浪费任何一方的精力，因为开发人员可以通过最少的努力（假设他已经通过修复错误获得了很多有用的信息）来提供大量有用且精确的信息，而测试人员将为此付出大量的努力通过阅读代码（在大多数情况下是没有道理的）或在某些情况下根本不可能（测试人员无法阅读代码）。类似地，EXACTLY测试人员正在寻找什么以及出于什么目的将通过不放置任何可能对测试目的不完全有用的实际单个修订的详细信息，并保留表示测试所指定的错误模式的特定信息来节省开发人员大量时间团队。
反过来，这将帮助测试人员通过根本原因分析以更少的努力来提出总体上更好，更有效的测试策略，并减少被测产品中计划外的生产问题，从而帮助开发人员改善被测产品的整体质量。
如果做得正确，这将使开发人员和测试人员以及整个团队受益。

#14 楼

我将从问题开始，然后研究如何解决。

这里的问题是双向通信。双方都无法互相交流。您将需要更好地与开发人员交流您真正想要的东西。例如，让我们以“已在x.x.x.x版本中修复，请进行测试”为例，您说您想了解更多详细信息。为了争辩，我将继续玩开发。我的下一个答复如下所示：


解决了UnderlyingServerManager装饰器中的一次性问题，该问题导致其在内存地址为质数-1的Widget上产生不正确的哈希。 。


现在您有详细信息。只有一个问题。这些细节都对您没有用。您不知道UnderlyingServerManager是什么（提示：它是底层的，埋在非程序员无法看到的代码中），您也不知道什么是Widget，并且您可能会也可能不知道可能是不正确的哈希。您掌握了细节，但他们并没有提供太多帮助。

您真正要他们做的是帮助您完成工作。他们知道他们做了一个修复程序，并且您知道可能有与该修复程序相关的含义，但是您不知道这些含义是什么。实际上，由于您提到许多测试人员不知道其编码语言，所以许多测试人员甚至都不知道从哪里开始！您需要开发人员完成上半部分的工作，因此您可以完成后半部分。

现在，这不是一个不合理的愿望。一次又一次地说，开发人员不能只是编写代码并将结果扔到墙上进行测试。但是，我选择说的是要指出的是，您正在寻找的信息交接处在代码和测试之间的界限不明确。您正在寻找他们将与代码相关的信息提取为已经完全以测试语言表示的信息。要做的工作还很多，开发人员可能会也可能不会。强调他们是。您需要此信息有两个原因。一个是显而易见的：您将要求他们做更多的工作来使您的生活更轻松。很高兴知道他们有多少带宽。第二个原因（更重要）是微妙的。您将需要打开一个沟通渠道，以正确讨论需要做的事情。能够收集他们的工作量的渠道就是一种能够找到方法帮助他们的渠道。

“你抓我的背，我会抓你的”应该是游戏。也许您发现，质量保证步骤实际上阻碍了他们做好工作。看看您是否可以进行交易：为他们简化该质量检查步骤，以交换有关如何获得“更多细节”的对话。让他们想要帮助您，过程会更容易。

下一步就是要意识到，您要的不是“更多细节”，而是“以人类可读的形式出现的更少细节”。他们给了您细节-在代码中。您想要的是已经被解释为测试人员可以使用的形式的版本。我指出这一点是因为开发人员不会知道您需要什么。您将不得不与他们来回合作，直到他们了解哪些信息对测试人员有意义。您需要训练他们说您的语言（或学习代码，以便您说他们的语言）。一般来说，他们不会想要，这就是为什么我们从第一步开始。通过寻找使他们的生活更轻松的方法来使交易变得更甜蜜。在公司环境中，尤其是在远程环境中，合作并不容易。确保老板知道开发人员正在发挥自己的作用。

#15 楼

它对其他编码人员来说是有价值的信息，所以为什么不与测试共享。

如果我很确定修复程序有限并且不需要一整套回归测试，我将分享一下。

如果这是一个数据库更改，可能会影响其他程序，我会分享。

测试可能使用一些需要更改的手动查询。

我有一个案例，它在测试中不起作用，但在开发中却起作用。原来测试没有复制配置文件。如果我告诉他们配置文件有更改，则可以节省时间。

#16 楼

坦白地说，我们发现该错误的最可能原因是开发人员犯了一个错误。没问题，我们都是人，如果开发人员没有犯错误，那么质量检查工程师就不会有工作。您要人们在永久性记录中写下“我犯了一个错误”，这很可能也是一个错误，在事实发生后非常明显，令人尴尬地如此。而且您对人们对此的反感感到惊讶吗？让我回过头来回答这个问题，如果客户发现了一个错误，您认为可以合理地向该客户解释，您个人如何对质量负责，从而允许这种明显的错误溜走？ br />最好在会议上面对面讨论这种事情，在会议中不要用手指指着，也不要写下名字。您可以获得所需的所有信息，并且人们会愿意提供这些信息，但是您必须以敏感的方式进行处理，而不是为进行巫术活动收集弹药。