#1 楼
我要处理其他任何错误-进行报告，编写错误报告。评论
我不同意。有人问我如果发现一个小错误该怎么办。我提供了答案。您可能不喜欢它，但这是一个答案（也是正确的答案）。
–伴侣Mrše
19-09-26在9:44
支持这一点。同意伴侣。我在这里看不到任何批评。质量工程师应报告缺陷的严重程度。管理的任务是分类和确定优先级。
– Alexey R.
19/09/26'9:54
可以扩展答案，但是，是的，这是一个非常有效的答案，并且总结了我也会做的事情。
–凯特·保罗克♦
19-09-26在12:38
完全同意这是一个有效的答案。除非OP不仅在质量保证中，而且要管理开发中错误修复的优先级，否则报告完全是他们的职责。
–乔治M恢复莫妮卡
19-09-26在22:52
更不用说缺陷报告所提升的工作安全性了……为什么有人将缺陷报告作为其工作描述的一部分，却不报告？
–user41726
19-09-27在8:43
#2 楼
100个用户中的1％与1,000,000个用户中的1％是完全不同的问题-让您的团队和利益相关者知道该问题（最好以书面形式提供缺陷报告），然后他们可以决定问题。对您来说可能是一个小问题，但对公司来说却是一个大问题。
评论
这也取决于您的100位用户为该软件支付的费用。 Crytek3的价格为120万美元（2019年），您可以确定受示例中的错误影响的用户希望对其进行修复。您应该使用公司的错误跟踪系统并与其他任何错误一样报告错误。
– TomToberhard
19-09-26在23:01
@TomEberhard我不确定价格是否真的相关。如果我在e-bay上购买了价值5美元的商品，但该商品无法正常工作，我倾向于做与1000美元的商品相同的事情：抱怨，直到我把它固定或退款为止。
–德米特里·格里戈里耶夫（Dmitry Grigoryev）
19年9月27日13:00
@DmitryGrigoryev价格非常重要：对于5美元的项目无效，我诅咒了我的运气，并从其他供应商那里购买了类似的项目，希望这次能够奏效。对于$ 1000的商品，如果可以选择的话，我会一直抱怨直到解决，否则退回以获得退款。
– TomToberhard
19-09-27在19:14
我最喜欢的引用来自linux（以及android）写时复制内核功能的作者：“此代码在超过70亿个设备上运行，每百万年一次的错误，每次都会被击中20次天。”
–林登·怀特（Lyndon White）
19-09-28在22:15
#3 楼
这就是所谓的风险分析。在本书中，过于简化的步骤是分析影响x频率。很少发生但影响很大的事情可以被优先考虑，而影响很小但太频繁的事情可以被优先考虑。
对于更深入的了解，我建议观看迈克尔·博尔顿关于风险分析的演讲。他在这里质疑我们可能会引起您进行浅层分析的偏见，并提出了如何讲述风险故事的建议，以便您使利益相关者意识到风险：
评论
就测试而言（据我对Michael Bolton的理解），风险分析与设计和确定测试的优先级以及报告问题有关。这不是决定下一步该做什么，这是产品经理要负责的事情。
–Rsf
19-09-26在10:11
问题问“应该进行质量检查吗？”我的建议是进行风险分析，以产生风险故事。
–JoãoFarias
19-09-26在10:24
知道了，尽管我从未听说有人使用过这个术语或以这种方式提出它-它应该只是（任何？）错误报告的组成部分
–Rsf
19-09-26在10:28
#4 楼
已经有2个正确答案，但我对此压力还不够。您发现了一个错误，提交了一个错误报告。怎么样。可以想象，它可能会影响0个实际用户，并且仍然是一个错误，并且您仍然提交错误报告。
QA的工作不是确定是否或快速修复错误。质量检查人员的工作是查找错误并告知已发现错误。
评论
提交该错误也很重要，这样它才能最终出现在内部文档（有时间我们会修复的问题），外部文档（已知的bug！）中，并在可用时分配资源。一个“在雷达下飞行”的错误将被遗忘，并且不会受到应有的关注（即使只有很少的关注）。错误跟踪系统必须具有一种将错误标记为“已延迟”的方法，这意味着它们不会在日常会议等中显示，但是无论如何都会被跟踪。
–彼得-恢复莫妮卡
19-09-27在13:12
@ PeterA.Schneider而且很重要的一点是，即使原始的报告人已经厌倦了等待并停止使用该产品，它也要保留在文档中，直到经过适当的调查为止。
– StackOverthrow
19-09-27在16:24
同样，下一次质量检查无需花时间和精力来记录相同的错误
– xyious
19-09-27在19:12
作为开发人员-是的！即使它不一定影响真正的用户，我也想知道这一点，因为它可以很容易地向我显示代码中的问题区域，将来可能会爆炸。
–烟斗
19-09-28在8:27
#5 楼
关于所有用户的重要性，这里有很多答案。本质上，这是关心罕见bug的一个很好的理由，但是我认为我会就其他一些原因给出开发人员的观点。纠正我的想法很重要，这样我才能纠正我的其余代码。我曾经有一个错误，在少数情况下进度条没有及时消失。作为开发人员领导产品的那部分工作，我意识到这表明整个系统的清理例程比我认为的要晚一些，并且需要先运行。偶尔的用户界面故障似乎是一个小错误，但它揭示的问题是绝对定时炸弹。 。我是一个非常有能力的错误编写者。所有开发者都是。我已经写了几百本书，那只是我所知道的！因此，如果有一项政策仅对影响超过1％的错误进行了标记和修复，则几乎所有用户都有可能会遇到无法消失的错误。第三，即使是那些不要立即证明修复是值得知道的。如果事实证明此错误确实很难解决并且不是紧急的，我可以标记为不会修复。即使这样，当我由于其他原因有机会进行大块重写时，我会保留缺陷清单并避免它们。但是，如果我不知道，我将无法为其设计。
#6 楼
它实际上取决于许多不同的事物，例如：此错误的严重性是什么？
修复该错误的工作量是多少？
有1％用户？
还有很多事情要考虑，但错误就是错误。它需要报告，并且决策应该由管理者做出。因此，我只想报告一下。
评论
您的要点与质量检查工程师应该做什么无关。它们与您的上一段无关。
–chepner
19-09-27在15:17
#7 楼
您怎么知道错误仅会影响1％的用户？即使错误严重性较低（如您所说，影响的用户数量很少），像产品所有者这样的企业也可能会提高错误优先级并进行修复。如果不为其创建错误报告，则它们将丢失有关SUT的重要信息。
找到错误后，应始终报告错误。
评论
它会影响1％的用户，因为该错误可能在用户ID的后两位为42时出现。
–詹斯
19-09-27在16:04
我似乎想起了ID是否以24结尾。
–迈克尔·卡拉斯（Michael Karas）
19-09-29在6:14
#8 楼
今天被认为是较小的错误明天可能变得至关重要。例如，许多外部硬盘仅正确地实现了USB大容量存储，而USB连接的SCSI实现却有问题。在UAS驱动程序进入Linux内核之前，这是一个小问题，导致数据丢失或更新后无法在Linux PC上使用此类驱动器。未修复比发现错误要好得多，要发现错误，才报告错误并忘记它，直到它回来的那一天，然后您必须重新搜索根本原因。#9 楼
正如许多人在这里所说的，我要做的是编写一个错误报告。在其中，您可以描述其产生的影响（不仅在受影响的用户方面，而且在造成的原因方面）以及发生的频率。接下来做什么。也许业务代表或团队决定此漏洞的优先级。然后，您（最有可能是开发人员）可以开始进行开发，或者将其留待以后使用。 br />您没有提交错误报告-您冒着实际上是一个严重问题的风险，而您只是没有找到它的所有影响；在这种情况下，它会事与愿违。
您首先与团队的其他成员谈论它-仍然优于1。因为其他人可能对该主题有重要的投入，但是您仍然发生风险在讨论之后忘记了它
...我们也许可以提出更多建议，这些似乎是最常见的建议。
评论
您对缺陷的正常处理方式是什么，为什么现在会有所不同？影响与发生的频率是同一严重性度量的一部分。您可能有一个影响到每天使您的程序崩溃的人的错误，或者仅影响您所有用户的0.00001％的错误，但是会在发生错误时启动核对……这两者共同决定了您需要解决该问题（或不解决）
您是在问是否应否否决产品（独立质量检查人员可能拥有的功能）？您的产品安全性相关吗（汽车，铁路，电力等）？在现场更新产品容易还是困难（假设这是软件错误）？当我们编写用于汽车收音机的软件时，至少要满足以下两个要求：（1）不要耗尽汽车电池的电量。 （2）在现场可更新。 （尤其是不必接收广播或发出声音！）
1％的用户有多少？ 100个用户？ 100,000个用户？
我很震惊，这个问题遭到了投票。