有时，我的质量检查小组会报告错误，但是我或他们都不知道如何重现错误。这导致非常长且令人沮丧的调试会话，有时甚至无法产生结果。

我的软件与专有硬件紧密相关，因此错误可能一次来自多个方向。

我应该对他们期望比“按下按钮时您的软件崩溃”还要多，还是应该自己弄清楚发生了什么？

编辑：

我的一位同事指出，我们可能是这里的所有开发人员，因此结果可能会出现一些偏差

质量检查人员应始终尝试使错误尽可能地容易再现，并且错误描述应包含已采取的步骤。

但是，如果他们不能轻松地重现该错误，则仍应使用适当的标题/标题以及其导致错误的原因的完整说明，将其输入到错误数据库中。错误描述应明确指出他们无法重现该错误（也许在“尝试5次，发生一次”的注释下）。这样，如果其他人看到相同的错误，他们可以将他们的发现与发现一起添加到错误数据库中，并且您将获得尽可能多的信息，这对于节省您的时间来追踪问题至关重要。

此外，您还可以过滤信息-在不同的系统中可能存在很多错误，您都知道这些错误都与（例如）代码的一个区域相关联-如果质量检查未报告任何内容（因为它们无法重现它们） ），则此信息不会传达给您。

您的质量检查部门似乎进行了过多的探索性测试（即，他们没有好的测试计划）。

探索性测试是好的，可以识别问题区域，但是应该从那里定义可复制的测试用例（即测试计划），以执行那些可以揭示特定错误的测试。

有很多原因需要进行正确的复制（不仅好，而且是必要的）：

1. 您必须进行复制，以便可以调试/查找原因。
2. 完成后，质量检查人员将需要能够验证此修复程序。
3. 进一步的测试通过将需要对以前的错误进行回归。
4. 如果曝光量太小或再现不太可能，则可以丢弃已知的错误。

因此，正如SteveCzetty指出的那样：以无问题的方式关闭它，然后重新开始工作。

如果无法始终如一地复制该错误，质量检查人员将如何知道它是否已修复？

是的，您应该对他们有更多的期望。他们应该能够说：

1.启动程序的新实例
2.我按下了按钮A
3.在表格1的“测试名称”字段中输入“测试文本”
4.按下按钮B
5.观察到该程序因该消息而崩溃（请参阅随附的屏幕截图）。

如果他们说的只是“崩溃”，那么他们就不是很好。即使上述步骤不是100％可重复的，一旦检测到某种模式，这些崩溃的足够大的样本可能有助于缩小原因。

我的建议是阅读这些错误并给予他们良好的旧思维。如果您找不到潜在的原因，请暂时将其忘记。

质量检查人员应该记录发现的每个问题，即使他们不知道如何发生。尝试重现问题是QA的工作，但实际上这并非总是可能的。有时，这与他们在最近10分钟内所做的没有任何关系。一天前某事进入了无效状态，由于最后10个步骤之一，它才变得显而易见。

对于这些“千分之一”的错误，质量检查人员应该尝试重现它们。如果没有成功，则应记录该错误，然后再尝试一点。

他们之所以应该尽早输入错误，是因为程序员比QA更了解代码，并且可能会立即知道问题。可能是他们重构的代码。可能是他们一半实现的功能却忘记了。他们可能不知道，但是测试人员浪费了几个小时试图重现对编码人员来说显而易见的问题。测试人员以后总是可以向错误添加更多详细信息。

该错误应包含尽可能多的信息。测试人员所能记住的有关问题前兆的任何内容均应详尽地写下。任何崩溃日志，数据库快照或相关的屏幕快照也应附加。

如果该错误从未被复制过，那就太好了！在数据库中存储它不会有什么坏处。如果该程序已发布并且用户以后报告了类似的错误，则可以将他们的经验与报告中的内容进行比较，并查找任何相似之处。

根据我的经验，从以下测试计划中找不到最有趣的错误。有时，您必须让事物旋转几周，以使月亮和星星对齐，从而导致令人讨厌的错误。如果质量检查人员可以做一些侦探工作并找到一些可能的原因，请轻拍他们的背面。但是有时候，谁知道发生了什么？

除非您知道如何修复，否则许多错误是无法复制的。这并不意味着它们不需要修复。去年，我修复了一个我仍然不知道如何复制的错误。这需要精确定时的传输错误与堆栈上某个内存位置中非常特定的垃圾数据的某种奇怪组合。不幸的是，我们的一位客户足够幸运，可以一直处于这种状态。

因此，在可能的情况下，应尽一切可能鼓励质量检查人员包括可重复性步骤，但如果不能，则不要指责它们。有时，它将帮助您知道在何处添加日志记录。有时它所做的只是告诉您什么不会导致该错误，但是错误报告始终很有用。

如果您的意思是说质量检查应该包括重现该错误的步骤（如果可以），那么答案是肯定的。如果您是说只记录它们能够复制的错误，那么绝对不是。错误是错误，无论它们仅发生在满月的午夜还是每次您查看时都发生。有些错误是不确定的（经典示例是未初始化的变量，拾取的值是半随机的），这并不意味着不应该对其进行记录，调查和修正。

不可重现的错误通常应具有较低的优先级，但绝对应该对其进行记录。

海事组织，你应该。如果质量检查人员无法为您提供任何复制步骤，则他们不会做他们的工作。不要浪费时间尝试复制您无法复制的内容，只需将其关闭为“无法复制”并继续。

您的时间比那宝贵得多。

错误报告应包含：

• 重现步骤
• 实际行为
• 预期行为

例如：

• 我从数据库中删除了所有供应商（使用DELETE * FROM tSuppliers），打开了供应商对话框，然后单击了供应商下拉列表。
• 该列表包含以下消息：GUPOS ERROR #0000000: SOMETHING WENT WRONG!。当我单击该消息时，该应用程序从屏幕和任务管理器中消失了。
• 我希望看到一个空列表或（最好是）一条消息，例如“找不到供应商”。单击空白列表或该消息应无效。该应用程序显然在任何情况下都不应消失而不加警告。

因此，是的-它应该包含复制步骤。他们不认为需要包含此功能的事实似乎表明他们认为自己的工作是“破坏软件”，而不是识别故障。

质量检查人员应能够根据输入的步骤重现错误。如果他们努力尝试，仍然无法重现，那么他们仍然应该输入带有时间戳的详细信息的错误，以便开发人员可以查看应用程序并调试日志以获取更多详细信息。

钱在这里危在旦夕。为什么任何团队成员都能够创建定义不明确，成功机会很少的任务，而这却给（希望的）高薪开发人员带来负担？

这与啄食秩序，等级制度，傲慢，我们与他们或诸如此类无关。这只是投资于增加产品价值的活动。

当问题被证明会对产品的价值产生负面和可衡量的影响时，则应对其进行研究，复制和修复。修复产品缺陷管道以滤除噪声。

您的质量检查团队糟透了

去找他们，告诉他们阅读任何专业测试人员都必须在他们的脑海中打印的文档（我曾经是一名测试人员，但现在仍然在脑海中），如何有效地报告错误。

特别是，将他们指向“告诉我如何展示自己”部分：

这是互联网时代。这是全球交流的时代。在这个时代，我只要按一下按钮就可以将软件发送给俄罗斯的某人，他也可以向我发送有关该软件的评论。但是，如果他对我的程序有疑问，当程序失败时，他不能让我站在程序的前面。可以的话，“显示我”是很好的选择，但通常不能。

如果您必须向无法亲自出席的程序员报告错误，那么练习的目的是使他们能够重现问题。您希望程序员运行自己的程序副本，对其执行相同的操作，并使程序以相同的方式失败。当他们看到眼前发生的问题时，便可以解决...

如果他们开始对您大喊大叫，抱怨“错误可能同时来自多个方向”，请告诉他们，它们吸收的能量比您以前想象的还要多。告诉他们可测试性是一项功能，他们应该在其他项目功能中评估这些功能，并应该投入精力以使此功能正确无误。

• 当有专业的测试人员专注于可测试性改进时，可能会像魔术一样。我几个月前才知道这一点。与我们团队合作的质量检查工程师向我提出了一些可测试性要求，以开发应用程序中的某些组件。他问的事情对我来说意义不大，但我只是假设他作为一个专业人士，就把它给了他。我完成后不久，他想出了一种工具，可以将测试工作量减少数量级。他说，大多数情况是基于我实施的这些隐秘请求得出的。