如果软件测试员在生产中经常丢失缺陷/错误该怎么办？

#1 楼

我认为他们的工作应该是找到将影响用户和业务的重大问题

我认为“做好工作”的意义不仅仅在于点击每个项目并在每个字段中输入错误的信息。在应用程序的上下文中，行业，用户，任务应该是一个重要的问题，它会影响用户完成任务的能力。

我会考虑做一些事情：


进行审核以讨论票证的分类方法，这对您的公司来说很重要。在查看任何特定情况之前，请大体上以抽象方式进行此操作。
查看您具有故障单的类别，并确保有方法将故障单标记为“ ui问题”，“鼠标单击问题”等。
有一个定期安排的“错误审查”会议，您可以在压力较低的环境中检查发现的错误以及将来如何避免它们。让包括开发人员在内的团队共同努力，即不要针对QA人员。
在QA内部定期安排一次“ bug审查”会议，以便在与更广泛的团队进行上述小组审查之前对票证进行审查。
使用方法例如“ 3为什么”和根本原因分析，以找出问题的真正原因。
（每个人-分析人员，开发人员，质量检查人员等）都将重点放在测试上，并在此过程的早期谈论测试和测试计划-通常称为“左移”。最好的错误是永远不会发生的错误，这是因为在编写任何代码之前都会先进行一些有关功能和测试的关键对话。正在签字，例如顺畅的流程，难过的流程，不同的设备，可访问性测试等。
寻求将错误与公司使命联系起来的方法。例如，如果一家公司衡量每日收入，则考虑进行分析和AB测试以显示已修复的漏洞的金钱价值。这涉及大量分析和设置，但在决定应采取的措施方面可能是金牌。
考虑定期进行积压会议，查看旧票，看看它们是否值得修复或应该关闭。这有助于加强公司认为值得记录的内容。
确保明确定义和传达公司的质量指标。

#2 楼

分类他遗失的错误和设法找到的错误，它们有什么共同点？


对于他设法找到的错误，低优先级视觉错误，浏览器特定的行为错误，复杂的（但发生的可能性很小）错误，包括使用多个并发用户，不良的网络连接，疯狂的快速“网络风格”点击等。人，并且能够采取不寻常的方式来发现不寻常的错误。该测试人员可能无法确定任务的优先级。他并不认为关键功能很关键。
他一直缺失的错误的其他共同特征是什么？
您是否可以为他提供任何培训/辅导，以帮助他克服缺点？此指导过程可能需要有经验的测试人员与他进行配对测试，这可能需要一些时间。

#3 楼

是否有人审查测试人员的测试计划或测试用例？在审查期间，是否有人对计划的测试用例应用80/20规则？

您知道测试人员计划在其测试中涵盖的要求吗？

您是否知道？有明确定义的要求？

您的测试人员实际上知道如何使用该应用程序吗？他们是否曾向您寻求帮助来定义和设计测试数据？

您的QA环境是否得到管理和维护，以确保它与生产环境相匹配？是在质量检查环境中可重现的生产问题。

坦率地说，您的问题始于很多指责。我并不是说您的质量检查资源没有错，但如果您不对某人的工作负责，那么您可能会不满意结果。您是否声明过要执行特定类型的测试或验证特定功能？如果不是这样，并且您的资源缺乏经验/学科，那么您可能会遇到很多低优先级或增强错误。

#4 楼

每当存在生产缺陷时都应该提出这个问题。不是因为对QA玩家进行责备游戏。但是要确定在我们的软件开发和质量保证流程中出了什么问题。
在我之前的工作中，这是我们曾经进行根本原因分析和CAPA（纠正和预防措施）的地方。在最近的敏捷和左移测试策略中，我要坚决地说，不能简单地仅对QA提出这个问题。应该向该功能的开发人员以及负责该功能的代码审查的首席开发人员询问。
此外，在进行根本原因分析时，您不能仅仅停留在第一个答案上。您应该根据答案不断提出问题。
例如：
如何在质量检查中遗漏了此缺陷？
-我们的测试案例中没有涵盖这种情况。
-另外，开发人员还没有编写适当的单元/集成测试来涵盖这种极端情况。
为什么这种情况未包含在测试用例中？以及为什么在测试用例审查时会漏掉这种情况？
为什么开发人员没有为这种极端的情况编写任何单元/集成测试？
-我们没有足够的时间来涵盖更多的情况或做适当的测试用例复审或编写单元/集成测试用例。
为什么我们没有太多时间进行此活动？
在Sprint计划中，我们从积压的订单中提取了很多案例/功能对于此sprint，实际上为开发人员和质量检查人员都设置了一些时间限制。
我们已根据每个功能/故事的故事点从待办事项中获取功能。那么，为什么我们没有为这些功能正确分配故事点呢？
-是的，在为每个冲刺要开发的功能/故事分配故事点时，我们应该格外小心。
最后答案是CAPA，我们必须非常仔细地研究一下，并且应该在以后的每个冲刺中都实施该CAPA。
免责声明：答案仅适用于那些胸怀宽广，愿意接受自己的错误并愿意尽早纠正错误的人和组织。
不适用于某些对以下内容更感兴趣的公司/人：玩政治指责游戏，或者在他们希望将质量检查作为生产缺陷的替罪羊的情况下。

#5 楼

所有错误都是好的

如果我们将错误队列重新定义为记录特定输入行为的数据库的错误队列，然后采用“数据库中的数据越多越好”的概念，一种在当前和将来的迭代中评估“产品的最大价值”的更好方法。

换句话说，养成“编写尽可能多的错误，因为这最终是好的”。队列中的所有数据都将得到审查并不断确定优先级。对所有错误的评级仅集中于对产品最重要的那些。那些评级不够高的项目将移至待办事项列表中，以免被遗忘，但不会被遗忘。

测试深度必须不断提高
琐碎的错误一旦进入数据库就不再记录，因为“我们不会编写重复的错误”。这意味着必须提高测试的深度。解决方案就在其中：所有测试也应不断进行审查和批准。使每个测试计划（测试集合）在迭代计划会议上获得批准。

测试计划仅针对那些对于任何给定迭代对产品最有价值的用户案例和错误。默认情况下，每次迭代的测试计划本身都会不断改进，仅仅是因为过程需要它。

总体方法必须改进

，这反过来又改善了整个流程和策略。质量保证小组会随心所欲地建立起来，从而为标准化操作提供了最佳方法。如果发现差距（如您所述），则可能是针对流程本身编写了一个错误，该错误可能很简单，例如“在给定的上下文中创建其他培训或教导新方法”。

不断改进测试的各个方面都具有深远的意义。

#6 楼

在Live环境中发现的缺失缺陷可能会对软件质量保证公司造成损害。如果万一软件测试人员经常缺少这些功能，则可以采取以下步骤找出原因并加以改进。

测试人员应具有要实现的功能的需求文档。
测试人员应对使用中的应用程序有完整的了解。
应针对应用程序优先考虑进行详细的测试和用例。
如果使用多个模块，测试人员应该知道如何执行集成测试。
测试人员应退回已修复的缺陷，并测试已修复功能的相关区域。
应在将应用程序部署到实时环境之前和之后执行完整性测试。
应使用暂存环境进行检查如果功能已正确实施和测试，并且一旦在质量检查环境中发送，就可以反映该功能。

#7 楼

尝试找出不良测试背后的隐藏因素，并从结构上进行修复，以使此人走上正确的道路，而其他团队成员也不会犯同样的错误。

回到您的缺陷存储库并找出缺少的缺陷
，然后将它们链接到测试用例存储库，并找出测试用例中缺少哪些类型的测试。
尝试找出2-3种重复模式：是有一个模块比其他模块更容易被遗漏，或者他在某种需求/功能或任何其他趋势上被遗漏。
进行团队讨论，并告诉您的团队有关薄弱环节的信息，并且您想通过更全面的测试覆盖范围来加强此功能
修改测试用例存储库并在下一个测试周期中自行检查/批准测试用例，以确保您不会丢失这些类型的测试用例

为了能够执行上述分析和操作，您应该有一个易于访问且可维护的测试用例存储库，一个系统，您可以通过该系统批准一个新的测试周期的测试用例，以及一个项目中下一个测试周期的测试用例的可重用性系统。
那里有一堆测试管理工具，可以帮助你。 TestLink是开源的，在测试用例的可重用性方面很好，但是不允许您将测试周期与缺陷链接在一起。 HP ALM是一款全面的企业级工具，具有您可以想到的所有功能，但是学习曲线却很高，如果您不是一个非常大的组织，则可能会花费很多。 Kualitee是一个相对鲜为人知的工具，它是一种更全面的工具，可让您维护测试用例存储库，批准新的测试用例并且使用相对简单。