希望该错误消失后，如何响应重新测试的请求？

#1 楼

作为开发人员而不是QAist，我有责任提供符合规格且尽可能少出现错误的软件。在我看来，质量检查有责任将我所犯的任何错误告知我。为此，我给予了他们很高的评价。提交之前的代码不同，现在的代码也不同。通常，在已开发的功能中会发现错误，这些错误会在几次提交后发生很大的变化。即使对错误消息的行号进行了更改，他们非常有可能对上周测试的代码进行了更改。

当我们要求您重新测试时，并不是因为我们重视您的时间少于我们的时间。这是因为代码不再存在于该文件行或该文件中，或者不再与该类耦合，或者由于业务需求已使该功能过时，Python版本已更新或百万其他内容。正在开发的代码是动态的，针对开发过程的特定部分提交的任何错误很可能在应用程序的那一部分再经过几分之后就已经过时了。

#2 楼

我在这里看到了几个可能的问题：


有报告的错误，测试团队显然可以重现，但是开发团队很难找到/修复。这表明错误报告中没有足够的信息。在这种情况下，提供精确的复制指令集会很有帮助。如果要测试独立应用程序，则可以包括提供配置文件，数据库备份，甚至可以使用的本地数据文件。对于Web应用程序，可以提供测试服务器，并在需要时提供用户登录。
系统显然足够复杂，更改带来的副作用可以消除其他问题。根据我的经验，当开发人员说“我们在此处所做的更改可能会修复缺陷X”时，我需要对已更改的区域以及与已更改的区域相关的所有要素进行大量的回归测试。改变了。

理想情况下，我希望每晚至少有一次自动回归运行（最好是作为持续集成的一部分运行）来解决这个问题，但是生活并不总是理想的。


您的开发人员对他们的工作还不够确定，不能简单地告诉您他们已将某些内容作为另一个工作项的一部分进行了修复（或者可能在常规过程中未涉及）。 br />
或者，您的开发人员更信任您的团队的评估，而不是他们信任自己的评估。
如果有任何一种情况，您可能希望与您的开发团队更紧密地合作，以建立双方的信心和信任。对于导致这种情况的问题，您绝对应该重新检查该错误。

如果针对其他工作进行的更改已修复了错误，我通常会做的就是将其设置为工具用于“已修复”状态的任何状态，并记下针对另一个工作项的更改已修复了该错误。如果我知道有问题的工作项，我将其列出，以便知道缺陷X已通过用户故事Y的更改而得到修复。

然后我将查看是否有我可以做的缓解导致问题的任何潜在问题-有时无事可做。有时没有问题：这只是一个旧错误，在其他工作中被重构。

#3 楼

大多数问题跟踪器都有一个“过时”的封闭原因。这种情况恰好是该状态的含义：该错误是可复制的，但不再存在，并且您不知道确切的修复时间或修复方式。这不应该经常发生，但是您可以预期，当有能力的开发人员清理结构不良的项目时，这种情况就会发生。紧密耦合会导致更改在系统的遥远部分产生意外的副作用，并且当最终目标是将所有事物解耦并消除它们时，并不总是值得花时间充分了解那些副作用的发生方式。

（向Google的Android开发人员大喊大叫，他们滥用“过时”的接近原因来表示“我们五年来一直忽略此问题”或“报告此错误的人已经受够了并开始为另一个平台开发。” >

#4 楼

詹姆斯·巴赫（James Bach）说，


“测试是通过对产品进行探索和实验来评估产品的评估过程，其中包括一定程度的疑问，研究，建模，观察，推断等。”


我将使用“重新运行...测试”作为“希望在新的上下文中学习某些东西”的同义词。


“如果他们做了很多更改”，则表示上下文已经发生了很大变化。查找一些新的有趣信息的机会略高。因此，我可能会再次探索某个特定领域很有趣。 />
他们希望该错误消失了


这似乎暗示开发人员总体上不了解问题及其对系统的影响。造成这种情况的根本原因可能是缺少某些关键信息，而您先前的探索并未发现（或未传达这些信息），或者是由于缺乏对这些后果的更深入研究。视情况而定，视错误而定。无论哪种方式，重要的是要反思这个根本原因，以改善团队之间的沟通和效率。 。


如果是这样的话，您将面临团队或公司文化的更深层次的问题。任何分析都是冗长的，无论如何都不能解决您的特殊情况，但是需要解决此问题以便进行任何持续改进。还记得这枚硬币还有另一面（开发人员），因此，有可能他们觉得您的测试反馈（例如错误报告）的编写方式不足够使他们迅速解决问题。再次，团队反思和实验是必要的，这样大家才能发现如何更好地工作。 ;
询问他们如何理解问题并确定问题；
进行有关如何优化错误识别以修复确认过程的对话，不仅涉及文档（错误报告，票证，等）切换。

#5 楼

尽管该问题将其描述为一个问题，并且答案暗示着流程或过程不成熟，但我的经验却有所不同。并且在少数情况下发现该错误需要复杂的执行环境，特殊条件或仅是“测试人员的接触”（请记住，您仍然是团队的测试专家）尊重我们的时间


这不是您的时间，这是团队的时间。如果我们假设一个成熟的团队遵循半体面的开发程序，那么团队或团队负责人将根据工作负荷和能力做出这样的决定。




作为开发人员，我必须承认这只是现实，您可能会浪费时间去研究复杂系统中的复杂bug。而不是用于生命攸关的设备业务（航空，医疗或弹药），那么有时在记住相关风险的同时进行简单重新测试会更有效率-例如，如果该错误是企业存储系统上的主要数据丢失，则仍然应该进行一些调查。

重新测试可能还有另一个好处，例如可以通过比较日志或行为来了解原始问题。


应该怎么回答？


应该如何关闭？ （我们使用：“已拒绝”，“原因”字段=“不再可见”）。完全经过重新测试，并在什么版本和环境上进行了测试。
如果有人尝试收集有关bug的统计信息，请务必小心，他们会看到很多被拒绝的bug。

最终免责声明-我的回答主要与复杂的系统和不重要的错误有关

#6 楼

编程很复杂。停一分钟，想象一下它有多复杂。不，那是它的十倍。不，您只是再次低估了它，它比这还要复杂十倍！每个功能都增加了复杂性，并可能导致无法预料的交互作用和副作用，其中有些是bug（有些是偶然的事故）。因为他们没有时间或领域知识来确定。任何告诉您有可能100％修复特定错误的程序员都在说谎。总是存在一定程度的不确定性，优秀的程序员将对此不确定性诚实。这并不意味着他们没有正确地完成工作！他们的经理可能要求快速解决错误，因此他们可以处理“更高优先级”的内容。他们可能需要更多的时间才能从几小时到几个月不等的时间来熟悉软件或领域。在这种情况下，您（程序员和/或测试人员）要么花费更多时间进行调查，要么“希望”您可以修复生产错误而不重现该错误。需要明确的ROI：投资回报率（时间）。

谁应该花时间了解错误？提供清晰的步骤来重现该错误是测试人员的责任。如果是间歇性错误，他们应该说出它多久发生一次。测试人员的责任不是诊断原因或查明导致该错误的代码行，尽管这样的注释（如果它似乎仅在上午11:00和中午之间发生）可能非常有用，如果它有助于缩小根的位置该错误的原因在于。我发现测试人员经常会错误地分析根本原因，因为这不是他们每天工作的项目的一部分。这并不是说测试人员不应对程序员的工作有所投入，也不是程序员对用户界面等没有任何意见，只是说他们不是负责在其他人的领域中做出决定的人，他们只能提供建议，而其他顾虑可能会推翻他们的建议。测试人员不应该尝试成为专家级的程序员，程序员也不应该尝试成为专家级的测试人员，或者决定哪些错误“重要”，哪些不重要。程序员和测试人员应该共同努力，因为他们有一个共同的目标：发布适合目的的产品。

一旦知道了触发该错误的条件，那么追根溯源是程序员的责任原因，解决问题，使修复程序可以进行测试并通知测试人员。责任分工明确。程序员负责编写适合目的的可维护代码。测试人员负责验证程序员的代码，包括探索程序员没有想到的极端情况。整个团队（包括程序员和测试人员）负责交付有效的产品。

程序员不应该做的就是更改令牌，而不必试图理解根本原因，并将其“扔掉”供测试人员进行验证。确实是不敬的。程序员和测试人员必须同样尊重彼此的时间。管理层也参与其中。一些团队处于高压环境中，当经理们设定了不切实际的期望时，他们试图责怪其他人缺乏时间。不先尝试理解别人的行为就很容易判断。在尝试前进之前，我总是尝试确保所有人都在同一个页面上。在没有完全（重新）测试的情况下意外损坏。希望您拥有可以完成大部分测试的自动化测试。程序员应具有一套单元测试，质量保证应具有一套验收测试。每个步骤也应进行完整性检查。新错误应为它们编写测试，并包含在测试套件中。

最后，如果错误消失了，则不应拒绝。程序员进行了一些更改，使错误消失，因此该错误是“已修复”而不是“被拒绝”。仅当发现错误报告错误或不能在任何环境（包括生产环境）中复制错误时，才应拒绝该错误。有时，可以将错误作为“无法修复”关闭，即，它不被视为错误或不值得修复。

#7 楼

从您的案例中可以看出，您的开发团队的编码纪律很差。我不确定您用于产品开发的方法是什么，但我会与负责您的两个团队（质量保证和开发人员）结果的人员交谈。

如果您有某种效率指标（例如，某些人使用缺陷拒绝率作为质量保证团队工作效率的衡量标准）我建议管理层为开发人员引入某种“质量保证人员拒绝修复”度量。任何“希望错误已消失”的验证并还原为开发人员，都会对开发人员评分产生负面影响。

#8 楼

测试的重点是提供反馈
通常，反馈越快越好（向左移动）
与开发人员配对，直到达到可以运行测试的地步。根据我的经验，分开进行开发和测试是不灵活的。
开发和质量检查的参与最终是一条两条路。开发人员需要使代码可测试，而质量检查需要使测试易于运行。更有用。更有价值。
（要弄清楚）这并不意味着消除质量保证-就像许多公司一样。我仍然相信测试人员的心态和质量重点，并希望QA / QE人员能够满足这一需求。当我亲自（在1天之内）从开发人员切换到测试时，我需要在头脑上“戴上另一顶帽子（角色）”，并开始专注于破坏事物，而不是着重于证明它起作用。
一种更传统的方法QA / QE开拓了自己的空间。这是自己的领地。然后，它进行了严格的防御。这通常不符合公司的最佳利益，而是更有利于在职员工的利益。 ...
通过允许请求者运行测试来响应测试请求
换一种说法，“希望”不是未来不断改进的策略

#9 楼

如果错误确实消失了，应该如何解决？ （我们使用：“已拒绝”，“原因”字段=“不再出现”）。 >