现在，管理层将其视为一件坏事。他们联系我，想知道为什么我错过了这个缺陷。毕竟，我拥有此功能区域，因此他们希望我应该找到该缺陷，而不是其他任何人。我认为这种期望是不现实的。现在，我需要向管理层解释我错过了该缺陷，因为我正忙于另一项质量检查活动。
作为质量检查成员，我们至少参与了以下两项活动每天：
几乎每天（手动）运行健全性测试（可以在当天的任何吊舱上进行-质量检查吊舱，临时吊舱，生产吊舱）
测试修补程序进入生产舱
处理出现的客户问题
在您自己的区域执行完整的测试用例回归（需要2周）
将要进行的ER /新功能下一个版本并理解它们
为ER编写测试用例/对其进行审查
执行ER测试用例
探索发现的缺陷并详细记录问题
缺陷验证并进一步修复程序合并到代码中后，对它们进行完整性测试
所以这是我的问题：
首先，管理层的期望是n现实吗？
如果不是，那我该如何向他们解释？如果我告诉他们我在这里写的内容，在我看来，他们会将其视为低效率的雇员。
#1 楼
让我们暂时搁置所有防御。为什么实际上找不到缺陷？有时候，“因为我还有很多事情要做”实际上是“因为任务的自定义优先级不合适”或“因为我的测试不够深入，无法发现问题”，或者其他原因您的控制权。在争论您有太多事情要做时，请小心-这是一个很微弱的论点，您很少会获胜。每个人都有太多事情要做，没有足够的时间。每个经理都希望您了解最重要的是什么，什么才是“很高兴”。
相反，请考虑一下可以让您在其他任何人之前发现该错误的原因。也许要进行更强大的健全性测试，或更早的回归测试，或者其他您可以控制的事情？
尝试以一种非防御性的态度与管理人员进行讨论，或者提出一种解决方案。您的管理层将不胜感激。
您可能要考虑的一件事是事先阅读Gerald Weinberg的“ Perfect Software：以及其他有关测试的幻想”。那里有一些很好的讨论要点。请记住，管理人员并没有问您为什么该软件不完美。相反，他们是在问您，为什么您没有在软件的特定部分中发现错误（对或错）以为您应该发现该错误。也许他们的感觉是合理的，也许不是。尝试深入挖掘并找出自己是否正确。
评论
“发现产品功能实现中的错误似乎就像是一个不同的抽象层，最好由质量保证部门来完成，这是他们唯一的工作。”在我的商店里，这不是我们唯一的工作。
–乔·斯特拉泽（Joe Strazzere）
2012年7月20日在16:08
抱歉!现在看来，我的评论仍然没有抓住重点。 = /
– Anton Strogonoff
2012年7月21日在14:11
#2 楼
给定无限的时间和无限的资源，您将永远找不到功能或产品中的所有缺陷，击键或条件的某种组合可能会引起问题，但并不总是可再现的。如果管理层希望您发现某个功能中的所有缺陷，那么它们给您不切实际的目标，如果它们允许您通过调整测试作为“获得”的条件来适应过程以捕获缺陷，那么您可以继续改进并确保“这一个”不会再出现。您可以向管理层解释，并使用发生的任何重大中断或缺陷，是测试是适应性的还是进化的处理。甚至Microsoft也会发布针对其软件中不断发现的缺陷的补丁程序，如果Microsoft未能找到每个缺陷，您期望如何？您无法找到所有内容，尤其是当您执行多种测试类型和方法时，但是您始终可以重新评估测试并改进发现的内容。在这种情况下，如果发现缺陷并被其他人发现，则提出重要问题，为什么会遗漏呢？为什么不熟悉该产品的人找到它？您可以添加什么测试用例以确保它不会再次发生？
最终归结为您的管理层愿意听取您和您的疑虑，并希望您的方法能够起作用，但始终需要进行一些调整以保持检查状态吗？
评论
在无穷的时间和资源的情况下，您可以在一个软件中找到所有缺陷。
– pgraham
2012年7月10日15:28
@pgraham我从未同意这一点，因为您总是可以找到不起作用的新东西。
– MichaelF
2012年7月10日在17:38
我出价无穷大+1！ :)
–乔·斯特拉泽（Joe Strazzere）
2012年8月31日23:04
#3 楼
除了其他人所说的以外，还有其他一些要考虑的因素：您的经理是否知道软件的复杂性级别？鉴于您的团队已分配到产品领域，这听起来好像您要支持的软件非常复杂，这意味着从物理上讲不可能捕获所有内容。如果管理层不了解复杂性级别的影响，则可能需要为他们提供一些示例，以了解实际情况。
您的管理层是否了解您和您的测试人员的日常工作？如果没有，这将是一个对他们进行教育的好机会：如果他们将您的团队视为一个黑洞，使代码可以进入并且质量（希望）得到体现，他们很可能会认为您每天都在创造奇迹（您可能可以，但不是您的管理人员认为您正在做的那种。）
您有“管理者发言人”吗？根据我的经验，担任管理职务的人所讲的语言与测试人员所讲的语言不同。他们两个听起来都像英语，但是很多单词的含义都不一样。
您能为您的管理层或您的发言人向管理人员解释机缘巧合和探索性测试的力量吗？从您的描述中，听起来好像发现了您的问题，这是您的常规测试计划无法找到的，或者直到周期的更晚才找到的：这意味着其他人正在做某事，注意到了一些奇怪的事情，并认为“嗯真可笑。我想知道如果...会发生什么呢？”发现一个错误正如您所认识到的那样，这是一件好事，但是由于这不是计划的活动，因此具有管理背景的人可能没有某种引导和背景就无法真正理解。
您能否同时指出完整的时间表和在周期的某个时刻会发现此问题的测试用例？虽然这很麻烦，但是您还可以使用这些信息来证明您的团队人员不足，因此任何人发现的任何问题都会给您带来好处。 （我不知道是否是这种情况，但此刻我正在处理这个问题，因此我对特定的论点很熟悉。）
我希望其中一些建议对您有所帮助。
#4 楼
这似乎意味着您的组织中的管理层希望QE团队成为守门员，因为它不应成为导致缺陷遗漏的罪魁祸首，而不是为什么首先引入缺陷并由团队集体调查其出现的根本原因。 。接下来是我们如何防止将来出现此类错误。#5 楼
我们努力寻找每个缺陷，但是由于种种原因，错误总是会漏掉。一般来说，（1）要求客户在开始使用某个功能时就没有缺陷，或者（2）希望您是唯一发现功能缺陷的人，这是不现实的。 >孤立地看，您的经理的反应听起来不合理，但是可能需要考虑其他因素。例如，您曾经和这个经理一起发生过这种事吗？
您的质量检查团队中的其他人是否遇到过这种情况？
您的经理有不好的经历吗？和效率低下的测试员在一起？
您是否让您的经理有理由相信自己效率低下？
您的经理是否面临提高其团队质量或生产力的压力？
您的公司是否处于压力之下？您的客户需要提高质量的压力吗？
与其他功能相比，您的功能有多复杂/可测试？
工作中可能还存在一些文化问题，这些问题在印度的工作环境中是独一无二的。无论如何，更多地了解经理反应的根本原因可能有助于您制定适当的应对措施。
#6 楼
问他们为什么开发人员造成了缺陷而没有告诉您！您的管理层期望不切实际，但并不少见。我们每周处理一次。您永远找不到每个错误，因为您永远无法完成每个测试。我从Kem Caner和James Bach那里学到了一些东西。
评论
我会问开发人员，他们如何设法说服管理人员，让他们首先编写无缺陷的代码是可以的。