今天早上，我重新对其进行了测试，它已通过并随后被关闭。
下午，偶然地，我注意到此功能再次被修复。
向我的项目经理报告此功能后，它又被修复。
关于如何处理此类错误的任何建议？
-更多背景信息-
我们是签订短期合同的承包商，总计6周。
纯手工测试，我们的雇主对任何形式的自动化都不感兴趣。
开发人员也是承包商，他们在异地工作。我们通过电话会议进行交流。开发人员有自己的项目经理，我们也有自己的项目经理。
我们的合同只剩下10天了。
截至2017年6月27日，已提出的bug 104，已修复的bug 26
#1 楼
这是项目管理问题，而不是测试问题。您的操作取决于您的具体情况，例如-大公司，庞大的代码存储库，大量更改-我将对相关团队进行检查，重新打开错误，检查修复并忘记了
如果我一次又一次看到相同的问题，那么我会提出一个更大的问题，支持数据可能来自错误系统查询。
一家小公司，没有体面的质量文化-这将是一个很好的机会来教育其他人
无论如何，通常对于每个此类bug添加测试通常是不明智的。这些错误是由复杂的分支方案和草率的开发人员重新引入的，通常不会将它们“聚集”在敏感区域周围。
#2 楼
为每个缺陷添加自动测试。确保他们再也不会回来。现在这是一个短周期，您很快就抓住了它。我见过很长的周期。一位客户要求删除/更改/修复某些内容。几个月后发布，一位客户抱怨缺少东西。团队将其修复，直到其他客户回来。
您需要某种方式来记录所做的更改。我会说编写一个测试用例，该测试用例在每个版本之前都会重复。最好是自动化的。
评论
很好的建议，非常感谢。但是测试自动化不适用于此项目，很抱歉，我之前没有提出它。
–奥斯卡
17年6月26日在20:54
#3 楼
看来开发人员需要制作发行说明，并通知所有人补丁已应用或未应用。开发人员已修复它，并且由于某些原因未修复它，但是他们从未通知任何人，因为您发现此问题是偶然解决的。
作为一般做法，在应用补丁之前，应该将发行说明发送给所有人。在此发行说明中，它应解决此修补程序解决的问题。
还应发送通知电子邮件。
我个人的建议：
将此问题上报给项目经理，并索取发行说明和通知电子邮件
确保已记录了重新测试的方式，未修复的方式等。如果有，请向项目经理显示。有必要的。
保留自己的重要积木票已解决的个人积压。对它们进行回归测试，以防它们再次变得不固定。
评论
我不确定我是否喜欢在过程中添加额外的选通/步骤，由于一次事件似乎会使您的整个周期变慢，这似乎是过大的选择。我喜欢通过在流程中较早地移动它们来删除高质量的门/步骤。就像让开发人员对出现的缺陷进行自动化测试一样。
– Niels van Reijmersdal
17年6月26日在7:30
@NielsvanReijmersdal，可以添加测试自动化。我从管理角度来看。
–张瑜
17年6月26日在7:52
#4 楼
这样的问题数量不多：因此，根据我的经验，我认为此类问题通常存在于项目中，但数量并不多。
分别跟踪它们并定期进行重新测试
最好的方法是使此类缺陷的ID随手可得，并将其添加到您的监视列表中。一旦错误再次从“关闭”状态浮出水面，则应“重新打开”。即使修正了这些错误，也应该对其进行两次（一周一次或两周一次）重新测试（因为它们是历史记录者：-)）
吹哨
此外，如果您认为需要将此问题上报给经理或其他任何人，则可以提取与该问题的迭代次数有关的数据，以突出显示与此类问题相关的不确定性。
解决此类问题
通常，如果在设计级别存在问题，则会引起此类问题。因此，这些问题根深蒂固，开发人员无法仅通过对代码进行更改来解决它们。通常，此类问题需要扮演技术架构师（或同等职位）的人员的注意。
团队应该坐在一起，以便最终确定针对此类问题的解决方案。提出解决方案时，影响分析非常重要，因为您希望永久修复该错误，而又不希望从一种形式转换为另一种形式。
#5 楼
这些事情的发生和可能的原因是：初级开发人员
超出其领域工作的高级开发人员（请在此处查看输入链接描述）
估计不足项目：人们急于完成工作，所以他们不进行回归测试新代码
庞大的代码库：开发人员不知道如何添加功能而不破坏其他代码
传统代码库：它可能是软件体系结构不是太现代，没有单元测试等。因此很难添加新代码。
从您的问题出发，原因可能是第3点，但显然可以
有一些选择可以避免像您描述的那样的回归：
配对编程，使经验不足的开发人员可以由高级开发人员协助
代码审查。不仅要添加新的代码行，每个变更集还必须至少由另一个人进行同行检查，以确保防止发生错误（但不排除错误！）
开发人员和测试人员都可以编写单元测试，取决于它们的结构。目的是对一项功能进行黑盒测试。这样可以确保它符合实际要求，但是对避免回归很有帮助。确实，如果测试是每个构建的一部分运行，而您不小心更改了某个软件的行为，则单元测试中的失败将突出该问题。
端到端测试：这些测试在以下情况下会有所帮助应用程序与其他组件（也包括第三方驱动程序/软件）进行交互，并再次确保可以很好地测试暴露给客户的行为。端到端测试的编写成本（通常）较高，但是它们节省了手动测试的时间。您需要确定可以进行e2e测试的内容，以及仅委托手动测试更好的方法。通常，如果您不打算更改特定区域的功能，则可以选择手动测试。
构建电子邮件：开发人员每次向测试人员发布新版本，突出显示新功能，错误修复等时，都应写一封电子邮件。这有助于测试人员了解已修复的问题，新功能是什么，等等。它也有助于理解问题的发生率，项目的速度等。
问题跟踪器：Bugzilla是一个很好的例子。它有助于组织软件开发和测试。在您的情况下，可能会发生相同的错误：
在版本1中引发->在版本2中已修复->在版本2中进行了验证->在版本3中重新打开。软件的质量和回归。
测试跟踪器：TestLink是一个很好的例子。它允许您根据构建来编写/运行/记录手动测试用例。它允许您生成报告。就您而言，您可能已经为特定的生成生成了一份报告，说明哪些测试成功和哪些测试失败。如果在进一步的构建中存在退化，那不是您的直接问题。
系统测试：当项目经理认为软件不错时，可以对最后的构建进行系统测试而不是功能测试。系统测试应强调不同类型的问题，例如与网络或内存泄漏有关的问题，但显然可以发现回归。
项目管理系统：Trello是一个很好的例子。它允许项目经理，开发人员和测试人员在同一页面上。它还可以帮助项目经理确定优先级，测量速度，并选择发布中包含哪些功能以及哪些功能可以积压。
对于您而言，我认为值得给项目经理写一封电子邮件说回归是在先前的版本中已经验证了相同的错误之后在一个版本中发现的。
您的行为还取决于您和合同约定的内容，即公司对测试人员的期望。
评论
这是我们要在此处看到的相关问题。但是您没有提到是否有自动化测试。如果您现在不这样做，则有很好的理由向您的经理介绍为什么需要一个。 :-)您确定该错误实际上已修复和未修复，并且不是在某些测试中而是在其他测试中不是随机显示吗？
您知道为什么会重新修复该错误吗？漏洞修复可能会以某种方式被覆盖，例如拙劣的合并或类似内容。还是可能将旧版本的前缀部署到测试位置。
@PaŭloEbermann，是的，这是非常简单的解决方法。没有随机性。
@stannius，我不确定何时以及为何对其进行修复。我们完全没有开发人员的任何沟通。