测试人员是否会为发现产品中的太多缺陷/缺陷感到难过？

#1 楼

在一种情况下，测试人员应该对在产品中发现太多错误感到内，那就是，发现的所有错误都是相同错误的症状。

里面集成了有关超链接的帮助，并且存在一个错误，即如果您单击超链接，它将转到主页而不是正确的页面。我们有一个测试人员决定针对每个超链接提交一个错误，而不是针对根错误。我们发现的问题。其中一部分涉及确保我们的信噪比达到我们所能达到的最佳。

#2 楼

您的工作是找到可能会对使用该程序的人产生负面影响的错误，并且在健康领域，这些错误也可能也会对患者产生影响。解决后，您应该标记它们，故事的结尾。在产品发布之前进行的纠正越多，初始销售就越好，产品的接受度就越好。回应你。他们会努力地做自己的工作，而让某人发现您的工作存在缺陷（同样是个人经验），这对自我/自豪感是打击。但是，只要您不摩擦这些缺陷，或者在事情上表现出高高无上的力量，任何摩擦都应该过去。他们可以确保发布的产品处于最佳状态。

不用担心，一般公众会发现甚至您都错过了的错误。 （又是个人经历，哈哈）

#3 楼

我要讲的是我在房间里的大象，因为其他答案都没有真正提及它。请注意，此答案基于问题的措辞。我可能会误解此措辞，这是我基于单词选择和句子结构得出的结论。

查找错误很好，因为这就是您需要付费的东西。

我认为这里的真正问题不是您发现了这么多错误，而是发现这些错误给了您一定的自我提升。通过阅读您的词汇选择（“出色的工作”，“对他人的工作安全的威胁”，“我正在揭示他们的错误”，...），我对您有一定的印象。我得到的印象是，无论是在测试部门还是在开发部门，您都认为自己比同事要好得多。而且因为您认为自己更好，所以对我们和您的同事都表现得更好。关键是您的同事不喜欢您，因为您似乎在炫耀自己脸上的发现，而没有表现出谦卑的态度。这不是“我的工作太擅长”的问题，不是“我的靴子太大”的问题。只要您表现得像您是唯一胜任的人，您的同事就不会喜欢您。像这样的人通常是重组过程中最先成为目标的人之一，因为它们对同事的士气和生产力有很大的影响。表现得很出色，因为您发现了很多错误，并且在同事面前擦了擦，这是不好的，也不应该发生。

#4 楼

是否有人负责确定应修复哪些错误？如果是这样，他们对此有何看法？

是否存在该软件未满足的规范？

您需要记录实际上是错误的所有内容。您应该记录最终用户认为是错误的内容，即使它符合规范。是否应该解决这些问题是一个讨论，您必须选择自己的战斗。

您可能需要调整方法。我发现最主要的问题很有效：嘿，我注意到这件事令我感到困惑，这是原本打算的吗？是一种协作的努力。

#5 楼

显然，您不应该为自己的工作而感到难过。

关于感觉良好并确保您确实做得很好，但是您还可以考虑其他很多事情。专注于以下一些方面，将极大地帮助您解决不足和被不满意的感觉：


了解质量的业务指标是什么。
确保错误尊重业务优先。对某些企业而言，影响新注册的错误比影响新订单的错误更为重要，反之亦然。他们还可以在公司生命周期的不同阶段具有不同的优先级。与大型公司相比，对于初创公司来说，应加以解决的错误通常会有所不同，这是因为可以应用的资源和需求所致。
请记录要修复的错误的类型。随着时间的流逝，您将开始对公司所重视的解决方案有所了解。重点关注那些错误报告，而不是尽管您提供了最佳的呈现和解释却无法修复的错误报告。
提交良好的错误报告。等等都有据可查。确保重现步骤清晰易懂。让初级开发人员更容易理解。
不要指望开发人员会对质量工程师的方式产生的错误感到兴奋。
QE人员在发现真正奇怪，晦涩或困难的情况时可以大开眼界。 -重现错误。开发人员更有可能对它们进行打孔。 haha
获得良好的反馈。
每周与管理层会面，并确保他们正在做自己想要的事情。然后减少对那些开发人员的担心。
成为质量倡导者。
推动更多的QE参与，推动良好的标准和好的想法，表明您在乎自己的工艺。 。
说出他们的观点-并不是您发现下拉菜单很难使用，而是企业拥有广泛的用户多样性，包括浏览器放大的老用户，并且下拉菜单不适合他们设计的布局框，来换行，等等，”忠实于您的信念，随着时间的流逝，您将被信任并依靠它来履行自己的职责。
了解后端。
尽力而为，您可以尝试学习后端的功能。细读日志检查数据库，查看浏览器的网络请求对于开发人员了解您的错误非常有用
学习并应用自动化。
它可以利用和补充您的QE手动测试知识。使收入增加一倍也是常见的-以防万一您感兴趣。
请耐心等待。
我最近在现场工作导致80％的UI错误在6个月内积压。然后招募了员工，赶上了。需要很大的耐心。可以将这样的积压工作视为增加更多开发人员和qe雇工的理由，并更多地强调质量前期。
在讨论错误时要注意语气。
请确保您批评功能并说为什么不这样做。人或您可能会（正确或不正确）感知到的动机。
忽略偏执的想法
与老板交谈，并确保您正在做他们想要的工作。
成为专家在业务领域中
了解行业，业务和客户的详细信息，以便在提交错误和进行讨论时，可以将这些额外的知识带到对话中，而开发人员可能没有。
br />希望与开发团队互动，而不是坐在另一个地方。
通过新的测试方法，新的测试设备，新的使用方法不断创新。
学习，教导并与其他质量工程师专业人员联系。

记住要思考增值。
在任何特定的测试或错误报告活动中，请考虑是否要在业务衡量时为业务增值。我力求更好的Webform错误报告（更好的可用性和可访问性）。我公司测算出每年增加的收入100万美元。我正在帮助他们实现他们的主要质量目标。

#6 楼

简单回答“不！”

复杂回答“不，只要您正在执行以下操作...：”


您正在报告相关的错误（即偏差）需求）或可能影响系统功能或非功能方面的事情，不仅仅是您认为应该更好的事情
您没有在复制错误
您正在报告此类错误以便使开发人员可以轻松地重新创建该错误，以便他们可以轻松找到根本原因。您报告的是应用程序问题，而不是开发人员问题。责备是坏事。

评论

---

我有点不同意＃1…并非所有相关的bug都只是对要求的偏离…通过经验，客户知识等，有些东西您认为应该更好。

– JeffC
17年1月24日在20:52

---

@JeffC，观点很好。编辑了我的观点以反映您的评论。

–坚韧不拔
17年1月25日在8:16

---

关于＃1的要点：开发人员讨厌的一件事是错误报告，仅指出“ X应该更好”，而没有指定X应该如何。当然，这不是质量检查的工作，但是质量检查将满足草率的要求。

–古兰经
17年1月30日在10:13

---

@古兰经我同意。质量检查人员绝对不能说他们“只是认为应该更好”。如果作为质量检查人员，我认为某些事情可以/需要做得更好，那么我需要证明这是如何以及为什么如此。我需要提供证据。但是，如果系统按照要求运行，则不管我的意见如何，这都不是错误。

–坚韧不拔
17年1月30日在10:36

---

@Tufty这不是绝对的，恕我直言。我完全不介意质量检查指出没有破坏明确规范的缺陷，但是我确实希望质量检查能使开发人员了解这些缺陷（除了回顾或类似的内容）。这些发现必须带给产品管理人员或类似人员，他们有权改善规范，而不仅仅是执行规范。

–古兰经
17年1月30日在13:13

---

#7 楼

您不应该停止发现错误。

您可能需要调整报告方式。正如RomSteady指出的那样，当所有失败的链接都有相同的根本原因时，为每个失败的链接创建票证是没有效率的，它看起来就像是测试人员试图增加所报告错误的数量。更好的方法是报告一个bug，并在该bug报告中列出所有已知链接（或您的情况包括的任何常见元素）。

您是否在一个敏捷的团队中进行培训？如果是这样，您是否对接受标准提出意见，以及如何测试功能？如果是这样，您将使开发人员更好地了解他们的代码需要通过哪些测试才能通过QA。他们应该已经知道了，但是有时他们只专注于幸福的道路，而不是质量保证将应用的所有测试。所有这些都是真正的错误，但是如果您的团队致力于使逻辑正确，并且将来会涉及GUI，那么您可能希望减少对GUI测试的关注。与质量检查经理或产品负责人进行讨论，应弄清每个阶段的预期结果（假设您具有不同的阶段）。

查找错误的替代方法是让客户找到错误。没有人想要。

#8 楼

如果这是医疗应用，那么您正在谈论的是严肃的东西。如果错误影响了真实用户怎么办？如果开发人员威胁生命，或者管理层必须退役产品或公开借口，他们将不那么高兴。如今，对于具有小错误的软件来说，这是相当标准的，但是医疗应用程序应尽可能地减少错误。一位优秀的经理已经知道软件开发的工作原理，因此，除非确实有必要，否则不要给团队施加太大压力：


产品发布之前就被抓住了
这是非常标准的对于每天都要修正错误的程序员来说，
如果您必须专注于编程，那么也很难集中精力进行测试
测试人员总是报告错误
普通用户通常不会（除非特别生气或坚定）
如果用户是您的客户，他将报告错误，并且如果该项目已经花费了他很多钱或需要大量时间，他将不高兴。

从字面上看，该项目至少每周不报告错误：


项目太简单：没有其他公司可以轻易创建更好的产品的价值lone
项目使用率不高：也许有错误，但其中没有人发生。
不良管理：如果没有错误，是时候继续进行进一步的工作了（额外的功能或不同的项目）。 />错误修复程序应该推动开发，它们给出了正确的方法，哪些应该起作用，什么不起作用，这可以管理修复程序和功能之间的优先级
在重要项目中，添加自动化测试是有意义的，因此每个修复程序和功能带有新的测试，可以避免破坏现有功能

#9 楼

不，当然不会，即使您在已经测试且未更改的应用程序中发现缺陷也不会。以这种方式思考，您将不断成长和学习。因此，您将找到更好的发现缺陷的方法。除非您懈怠并故意使用快捷方式，否则您可能会感到难过。

与开发人员交谈，为什么他们会忽略您。询问他们如何更好地帮助他们。了解什么能最好地改善您的过程以防止缺陷，而不是在编码后发现它们，而是尝试在编码过程中或编码之前防止它们。

作为测试人员，您具有信令功能。您发现的任何缺陷都是通过质量过程得到的信号。只要确保您不怀疑自己即可。如果您认为它是缺陷报告，请注意！

一些信号：


可用性/ UX缺陷，也许您需要一个更好的设计器
功能缺陷，也许开发人员需要更好地测试他们的工作
需求缺陷，也许企业需要与开发人员进行更多的交流
业务逻辑缺陷，也许开发人员需要编写更多的单元测试
临时缺陷，也许您需要在开发人员得到缺陷之前对缺陷进行分类
重复出现的缺陷，也许您需要自动化（第2到第2端）测试
安全缺陷，也许您需要进行外部安全审核
不可复制的缺陷，也许您需要编写更好的复制步骤，以防止与开发人员打乒乓球。我建议对您的缺陷进行根本原因分析，并尝试找出真正的根本原因，而不是解决症状。

与整个开发团队一起制定质量标准。其中包括开发人员，测试人员，还包括业务人员，赞助商和经理。写下期望，并在过程中的每个缺陷出现后继续改进您的质量过程。只是确保每个人都有相同的目标，以防止您描述的事物。自然，我认为每个人都想提供高质量。

#10 楼

我建议您重新考虑什么是错误，什么不是错误。

也许您的同事只是懒惰或受到批评的伤害。如果那是唯一的事情-那就是他们的问题。

但是也许其中一些不是真正的错误或问题？特别是如果他们想拒绝它吗？

您将某些事情视为“业务流程问题”。但是，也许有某些真正的原因（您可能没有注意到的特殊情况）为何按原样制造它，否则就无法做到？

也许存在一个问题，您不了解打算做什么的方式？在那种情况下，您提交了“这做错了”，而实际问题是预期的工作流程不够清晰。看到“ GUI缺陷”？

如果发现错误，请报告。如果您发现流程问题，则应该以一种讨论的方式提出它：“为什么要这样做？在我看来，如果这样做就容易了”。不要仅仅坚持自己是对的，并且知道应该怎么做。

#11 楼

通常，您应该提交所有错误，只要它们是唯一的，并且描述得好，包括复制方案和任何其他相关数据。管理层不允许提交超过X个开发小时的有价值的bug，也不允许我们提交无法计划的bug。因此，我们不得不与开发人员进行非正式交谈，以评估每个错误的预期时间。而且在一个程序包上，由于负责任的开发人员根本无法解决问题，因此我们无法提交任何错误。

#12 楼

很难发现产品也可能存在缺陷，这是完全可以理解的：人们更喜欢为获胜的团队加油。

团队不是测试部门，而是公司。因此，如果您发现自己可以比开发人员更快地完成工作（以及进行新的开发），那么这就是使团队陷入困境的过程的一部分。

没有理由高兴。因此，您需要弄清楚如何才能为改善团队绩效做出最大贡献。这意味着要对错误进行优先级排序，尝试找出可能的根本原因，或找出可能最适合该错误的人，在可能的情况下，尝试将多个症状归为一个错误，排队可能由其他修复程序或您个人未来的发展所解决的错误-checked-later队列，以便最大程度地提高发现的工作负载的效率。

基本上，由于团队中的工作量而导致的工作负载，您希望最大程度地提高产品的性能工作（不仅仅是您自己的工作时间）。

有充分的理由将被测产品视为黑匣子。但是不要将您的团队视为黑匣子。

#13 楼

绝对不。如果测试人员发现某些有意义的缺陷，则有时开发人员会感到恼怒，但测试人员不应担心此类事情。并始终提供他们的建议和对上级管理的改进。

#14 楼

绝对不是，测试功能和发现缺陷是测试人员的工作。试想一下，在产品交付最终用户之前发现的缺陷越多，产品的稳定性就越高。请记住，在测试阶段修复缺陷的成本要比在将产品提供给最终用户之后修复缺陷的成本要低。因此，最好早点找到它。

#15 楼

我认为，如果每个bug报告为：不是多余的，也不是以不同的形式指向同一核心问题，则没有测试者应该为发现更多bug感到难过。
为整体产品质量增加更多的商业价值。
以中立的客观方式，而无需指出某人。
通过提供尽可能多的信息来帮助开发人员进行修复。

#16 楼

首先，您应该为自己感到骄傲，因为您发现了一个大号。错误。解决所有错误后，将有助于提高产品质量。不用担心别人怎么说。查找错误并将其归档是您的工作。及时做您的工作，您肯定会得到赞赏。

#17 楼

发现太多错误应该不会感到难过。
首先，有多少错误？两个错误太多了吗？ 200个错误太多了吗？您的发现可能是错误，也可能不是bug，请报告。
其次，您可能需要考虑报告对开发人员的社会影响。也许向一个人或一个团队报告200个bug，可能会使它们看起来很糟糕，或者使您看起来很敌对。在这种情况下，请尝试将多个错误归为一个报告，并可能不报告某些错误（保存以备后用-也许在修复了前178个错误之后，其余22个也将神奇地消失了-也就是说，如果已修复错误不要创建一批新的错误）。