软件测试员应如何处理生产中遗漏的缺陷/错误？

#1 楼

公司付钱给我测试好而不是粗心。


您在这里问这个问题-您不是粗心的，您在乎自己的工作和所从事的事情可以改进。

不要以个人为中心并且要专业。

发现bug的目的不是责怪任何人，而是要提高产品的质量。如果您的经理个人责备您，那是不健康和令人沮丧的情况。这适得其反。应该把重点放在如何避免将来发生这种情况上，而不是由谁来负责发生的事情。 -生产中总会出现错误，它只会发生。

这是一个机会

我不会太在意您错过了一些缺陷这一事实。相反，将其视为机会。向您的主管展示您为改进质量控制和测试所做的工作：


调查导致这些错误和缺陷的原因，找出问题-缺少某些测试，用户案例和测试案例，验收测试，负载测试等
考虑系统中可能发生此类问题的其他地方-您可能会在产品的其他部分发现类似的问题，并可能显示并声明“ ”。对于您的主管来说，这可能是一个好兆头，因为您已经学到了教训，并试图改善这种情况。
为这些缺陷创建自动测试用例-确保下次再次发现它们时不会被发现，并且不会进入生产阶段
收集覆盖率和复杂性报告-检查系统中是否有关键而复杂的部分未被测试覆盖
查找替代测试方法，例如基于属性的测试作为常见示例的替代方法基于测试的测试
，如果要进行手动测试，请尝试扩展您使用的技术，以下是一些后续资源：


测试启发式备忘单
可以在测试中使用哪些解决问题的技术？
软件测试人员如何使用“开箱即用”的思维方法来发现更多错误？ />

忘记您的标题-争取“零”目标


我早在几个月前就已经找到了那些。我不初级，我是一位可耻的高级分析师。


不要让担任高级职位的压力对您产生负面影响。争取零，倾听，观察，提供和建议。我从克里斯·哈德菲尔德（Chris Hadfield）的《地球上的生命宇航员指南》中学到的东西：


在任何给定的情况下，根据哈德菲尔德的说法，你要么是-一”，“零”或“减一”。如果您是加号用户，那么您就是在积极地增值。如果您为零，那么通常您就会胜任
，并且不会妨碍您。负一负很烂，因为您负有责任，并会积极地引起问题。

但是，如果您是一个加号
，并且遇到一种情况来证明自己有多出色，那么您
可以从加号减为负一个-您的“我明白了”的心态
可能很容易激怒并对动态有害。

那么，
在新情况下要做的最好的事情是什么？争取零。听。观察。
提供建议。不要试图掌控一切。如果您知道自己在做什么，则无需告诉别人自己是加人。
他们会知道的。

#2 楼

请不要辞职。

正如alecxe在他的帖子中所说，Perfect Software是一个神话。 ：很难看到测试人员的贡献。例如一个可单击的按钮。
但是当给测试人员一个任务来测试功能时，很难告诉我们从这个测试人员的工作中可以得到多少结果。为什么？当某件事出了问题时，它可能以十亿的方式出错。鉴于有限的时间和精力，我们被人类所允许，因此我们无法捕获所有错误。以一个可点击的按钮为例，我已经看到一个可点击的按钮，当它被精确地点击了56次后，却没有被点击。该按钮在单击1000次后会失败吗？第99999次点击怎么样？我们永远不会知道。

软件测试的目的不是捕获所有错误，而是在有限的时间和精力范围内提供对软件质量的信心。

我想在这里提出的一个建议是：可以根据需要将记录用作尽职调查的证明。

#3 楼

正如其他答案所言，不要怪自己。没有人可以完全测试任何软件，没有任何人可以编写完全没有错误的软件。它太复杂了。

我将引用我在测试部Dojo撰写的一篇文章中的一个示例：关于软件测试的十个误解。引言摘自一节，解释了为什么生产中的错误并不意味着测试人员失败。


认为测试人员应该能够捕获程序中所有错误的东西真是愚蠢。 。使用具有或不具有科学或其他高级功能的
基本计算器应用程序。现在考虑
加法函数。要测试仅完全将两个整数相加，
您必须测试将计算器能够使用的每个数字相加
到计算器能够使用的每个数字上并确保结果
是正确的并且显示是正确的。

即使使用不显示指数符号的非常简单的计算器
，并且只能将-999999添加到999999，也可能是1999998
整数以添加到1999998可能的整数-
或（1999998）^ 2。如果平均只需要5秒就可以执行
计算并检查结果，那么您仍然需要超过300000
年来测试两个数字的所有可能加法（即
工作24/7/365）。没有人有那么多时间。

即使您实现了自动化并且可以将平均测试时间降低到0.1
秒，您仍然可以看到数千年，甚至数千年。 >计算机，然后再测试所有可能的组合。而且
请记住，除了加两个
整数外，它甚至没有涉及任何其他方面。加小数后会怎样？其他操作？比两个数字更多的
？可能的结果数量并不需要很多。
接近无限。


（我引用此文件的主要原因是因为它比释义更容易）

现在，考虑一下：



您在生产。不是客户。这意味着它们在被“暴露”给外部用户之前仍然被捕获，并且这意味着如果有任何客户举报他们，公司可以说“是的，这是一个已知问题，我们正在为将来的版本进行修复” 。那不是失败。

您做了负责任的事情，并在发现问题后立即报告了问题。这样，您可以限制公司所承受的风险。
如果您的经理和利益相关者期望完美，他们将感到失望。您没有导致错误出现在代码中。您的开发人员也完全没有这样做：这些错误很可能是由于规格不明确或产品所有者与开发人员之间的沟通不畅造成的。或者它们可能就是我所说的“隐身增强功能”，即产品并未按客户期望的那样正常工作，因此即使他们在用例文档上签字，他们仍将其报告为错误。在这之上击败自己是你奉献精神的标志，而不是你失败了。失败不在乎。
你是超人吗？神？当然不是。期望您能够捕获到几乎具有无限可能的用户路径的软件中的每个错误（尤其是当您考虑撤消/重做任何次数的能力时），这使您期望自己是某种可靠的人。

说服您的经理支持您


责备自己接受是的，错误会潜入生产环境，但不要接受这会使您不可靠。您在遇到的情况下会尽力而为。

演示数学向您的经理显示我在示例中使用的数学-甚至更好，为您的软件做类似的示例。如果您说10个独立的正确/错误配置标志，则要使用每个可能的配置标志测试应用程序中的每个功能，您必须测试应用程序中的每个功能1024（2 ^ 10）次。如果花5个小时才能完成每个功能，则需要进行超过5000个小时的测试。我相当怀疑您的经理想要您这样做，并且我保证您不想这样做。繁琐的工作使人麻木。问题“如何对未编写的代码负责？”可能会很有用，就像可以回顾一下您无法测试所有事实一样。

责备会起到反作用

[在第2点中编辑数学以更正错误]

#4 楼

您对自己太苛刻了。

让我为您提供一些有关测试的见解：您可能想知道为什么测试人员甚至存在：如果每个人都做得很好，就没有必要使用测试人员。这是真的？不，这完全是胡扯！
为什么？仅仅因为一个人倾向于忽略自己的错误！

现在，这也朝着他或她自己的方向回击：就像测试人员的工作一样，测试开发人员所要做的事情不考虑，由开发人员/项目负责人确定测试人员没有考虑的领域！

，换句话说，我建议您执行以下操作：开始编写测试文档，描述您要测试什么，您将覆盖哪些领域。项目负责人需要批准该文档。该文档可以并且将在项目进行过程中进行更改，因此就像需要定期更新一样，定期更新审阅也需要更改。

如果您不打算测试某些文档，可以使用这种方法。领域，负担不会完全落在您身上，这将是共同的责任。

在向您的经理介绍这一想法时，您可以说以下话：“尊敬的管理层，事实在测试阶段我错过了某些地方，这让我心情非常不好，经过一段时间的停机之后，我开始思考如何将这种失败变成机会，以便将来避免这种情况并提供更好的质量。在此我的建议是：“（您将对测试文档及其定期审核进行解释。）

祝您好运

#5 楼

您和您的经理似乎期待您的完美。如果可以在员工中实现完美，那么您将失业，因为他们只会聘请不会带来任何缺陷的完美开发人员。

听起来您要么开始抑郁-这是一种需要治疗的医疗状况-或管理正在虐待您。或两者。通过QA认证并不意味着没有bug，每个人都知道这一点，包括经理在内。 >
我建议不要采用方法1、2和3，而是建议：


看看什么是抑郁症，并考虑去找心理健康专家。
并报告发现的错误。
根据发现新缺陷的方式，调整测试计划。

#6 楼

任何使测试人员（或与此有关的开发人员）对发现错误感到不快的雇主都应让所有测试人员离开并找到更好的雇主。每个人都应该对发现错误感到满意，无论发现过程的哪个阶段。如果人们对发现错误感到内gui，他们将停止发现它们，这是您想要的最后一件事。

#7 楼

团队应该拥有质量，而不仅仅是“测试人员”。团队包括所有相关方（下午，开发人员，质量保证，团队负责人，甚至是利益相关者）。 / o测试，然后“扔到墙上”让测试人员说它可以工作。

不要低着头。您并不是创建该bug的，而是您找到了它。

关于是否应辞职……听起来，您的工作环境主要集中在责怪而非寻找解决方案上。如果那是你的茶，那就留下来。如果那不是您赖以生存的公司文化，也许是时候寻找更有意义的东西了。

快速补充说明一下：我在怀疑自己的能力的同时是否真的是高级职位？

#8 楼

兄弟，每个像您这样的质量检查人员，在职业生涯的早期阶段都会面临类似的挑战。最初，每个人都很粗心，因此他们会这样做，这很正常。

我建议不要更改项目或组织，因为您现在已经拥有很多产品知识。通过每天做出色的工作来信任管理。.发起一些您组织中未曾做过的事情。尝试自动化容易出错的测试用例。尝试自动化回归套件。将每日报告发送给经理等。这将为您重新建立信任。.

从现在开始确保了解范围内和范围外项目，浏览器，要测试的设备，完全了解FS的时间表以及时间表等的全部功能。没有像QA这样的工作。

非常好。

#9 楼

我不想重复已经讲过的所有内容，但请记住您的ISTQB-不可能进行详尽的测试！ />这使我明白了要提出的观点。听起来您是该项目的唯一测试人员，并且这将减少人为场景的场景覆盖范围-没有人会想到每个场景。这就是测试人员喜欢加入团队的原因，因此我们可以检查彼此的工作。没有人是完美的。

就您和管理层之间的信心而言，您需要进行审核以备不时之需。无论如何，在开始一个项目之前，您应该已经让管理层签署了您的测试计划，但是如何让高级质量检查人员或分析师来检查它呢？到目前为止，您已经具备了进行质量检查所需的条件。不要放弃，您会习惯的！

#10 楼

简短摘要：您的老板真的期望100.00000％的工作代码作为您的输出吗？好吧，那么他是无能的，不是你。

我的忠实建议是：你不能做到完美，所以不要那么认真。

但是，如果您认为该公司显然是在试图让您成为替罪羊（看来），并且可能会损害您的职业生涯，请在找到其他同等或更好的工作后尽快辞职。 。如果有的话，现在是经济仍然强劲的时候了。在我的工作领域，我经常接触质量控制问题。而且我经常听到老板声称他们的工人很完美（他们会说，由于其他一些有趣的原因，例如，由于客户的完全不合理的要求，他们只需要使质量控制自动化：）看来您的老板就是一个这样的人。

这是胡扯。人不是万无一失的，某些因素使他们更容易犯错误。这就是存在质量控制的原因！您的工作是捕捉其他人的错误，而不是使事情100％正确，而是将错误的发生率从说成的99％减少到99.9％。他在您当前的工作场所。

如果您错过的错误在软件运行时没有引起任何问题，则无法评估它们的影响，但它可以忽略不计。 >
如果公司想要军事级的可靠性，那么他们将需要改变其流程，这可能意味着要雇用其他测试人员，并为其分配冗余任务（例如，代码测试人员与其他人员进行交叉检查）。他们不愿意为此付费吗？好吧，那么他们将不会获得99.99％。或99.999％或他们的目标。

我认为您既是有缺陷的生产/测试过程的受害者，也是管理不善的过程的受害者。但是我不认为您有能力改变这一点。

#11 楼

其他答案清楚地表明了软件的“根本就没有完美的软件”这一事实。我的回答基于您的第二点，


我应该采取更加明智和明智的行动。我应该在生产中没有发现错误
，应该保持安静吗？为什么我要突出我的错误并得到管理层的注意。


是的，你应该表现得更加聪明和明智。关于您的承诺超出了预期。我个人曾遇到过这样的情况（其他工作领域）以提供卓越的表现，但我也相信您的真正努力，只有您知道，其他人才认为这是工作的一部分。我并不是说这不是工作的一部分，但是您确实做了超出预期的非凡工作。让它暂时保持管理层和利益相关者的信心，并更正官方补丁或下一版本中的内容。因为，嘿！该代码已经正常运行了几个月。

但是，另一方面，还必须考虑这些错误的影响。例如，如果您的代码在工业机械或涉及公共安全的区域中运行，那么显然期望对代码进行完美测试。我的回答假设工作的性质不是那么关键。我敢肯定，您可以自己决定。

所以，请不要退出。尝试遵循其他答案建议的最佳做法，并谨慎对待仅因他人不理解而破坏您的形象。

#12 楼

软件始终会发布包含错误的信息。这是正常的。有时，甚至在没有人注意到的情况下，已经生产了数年的小错误。如果您在客户未注意到之前就发现了错误，那么您就已经为公司赢得了胜利。

如果我可以编写完美的无错误代码，那太好了，但是我不能。这就是为什么我需要质量检查。如果QA总是发现每个错误，那将是很棒的，但是您找不到，因为您没有比我更完美的了。

作为开发人员，我不想让您遇到个人危机，我只想让您向我报告错误，以便我有机会修复它们。

#13 楼

没有人能建立的系统是完美的。看看您的应用程序在手机上被更新了多少次，而这些都是候选版本。 ％正确；交付时没有任何形式的计划（即``我现在想要这个新功能，但您也需要完成其他任务''）;并期待昨天一切都没有加班费等额外诱因。他们无法理解这些要求不仅是不可能的，而且令人沮丧。

他们还批评我们是否失败或发现了错误，以至于我们开始掩盖一个事实，即当我们发现错误时，我们只更正了那些对我们的工作环境有帮助的错误，而留下了那些改进了产品的面向客户的部分。恶意，幼稚且非常糟糕的做法。

他们也没有听有关引入诸如敏捷开发，Sprint周期乃至某种折衷形式的项目管理和交付周期之类的杰出建议的建议-尽管有该软件团队竭尽全力介绍和使用此类工具。

如果熟悉的话，您可以做我所做的事情-我离开了公司。

#14 楼

犯错误是生活的一部分。接受这一事实，不要灰心。每次遇到这种情况时，下次您都会更加小心。它可以提高您的技能并增强专业水平。将其作为宝贵的经验教训。

#15 楼

这取决于风险。与这些缺陷非常高相关的成本是多少？公司现在破产了吗？你杀了很多人吗？如果不是，那一切都很好。人们会犯错误，这只是人为错误。进行根本原因分析，并防止将来再次发生类似错误。您最好避免这种情况，因为您已经从这些错误中吸取了经验教训。聘用新人可能会因经历相同的学习周期而再次导致相同的错误。仅仅因为您的头衔告诉您的专家，并不意味着您是专家。真正的高级专家和大师已经就该主题写过书，不是您吗？您和我以及其他所有人每天仍在学习。这是学习，掌握并成长为真正的大师的好机会。

质量是共同的责任。你没有犯错。开发人员做了，还是他们？是老板给团队施加压力，还是他？测试只是防御的最后一道防线，除非您进行正式的验证，否则期望会遇到错误。普通公司买不起的东西。