请注意，我在这里谈论的是产品缺陷。因此，即使过程和项目是质量的其他方面，我在这里也只关注产品。
作为一种潜在的解决方案，我建议随机收集50张票证（错误），仔细研究它们，以便我们弄清楚为什么在开发阶段没有检测到它们。
但是，我们还应该做些什么来调试质量检查流程？
#1 楼
我将从收集清理数据开始-不要挑选50个随机错误，而是从手动或半自动分类它们开始，也许使用错误日志中的关键字或信息-错误的年龄，环境，软件模块等。一个错误最终可能属于多个类别。继续前进并寻找数据中的相关性。同样，这可能是使用临时脚本或Excel工作表的半自动化过程。
现在有了有趣的部分。从每个类别或相关性中选择一些具有代表性的错误，然后挖掘以找出潜在的问题。
“问题”而不是“问题”，因为最好问为什么不止一次。五次通常是一个不错的选择。
评论
仔细阅读已经修复的错误列表，并对这些错误出现的原因进行分类可能也很有帮助，例如，开发人员对规范的误解或代码影响了其他未考虑在内的代码等。当然，可能有多种原因但是，对于单个错误，应该可以按来源，来源，方面等对它们进行分类。毕竟，只有在错误修复后才能进行操作
–古努迪夫
19-10-21在21:54
请务必与产品所有者/企业联系，否则您将无法获得对他们的价值。
–迈克尔·杜兰特（Michael Durrant）
19年11月1日在8:24
#2 楼
提出更多问题。严格来说，要获得更高的产品质量，要具有更高的标准
更多的测试
更好的反馈
但是，我将确定您的开发过程的成熟度。
问一些问题，例如：
开发人员和测试人员在一起有多近以分享理解？
当三个朋友在一起时，您将如何做？会发生变化吗？
您的测试金字塔的形状是什么？
您当前拥有什么代码覆盖率？
您当前的集成反馈过程是什么？
您的测试数据准备程序是什么？ ？
积压的订单在增加还是减少？
这些都会影响产品质量。它们当然是关于过程和项目的，但是那些事情会影响产品质量。
还请注意，您的标题当前表示质量保证过程，而细节仅表示产品。
您可以形式化（好的）分析想法通过做一些故障单
根本原因分析
5个为什么
事后调查
找出产品质量差的真正原因，包括所有重要的问题“我们如何定义和衡量质量”。注意诸如“错误数量”之类的统计信息。考虑考虑客户的经验，收入以及内部运营的效率，例如一旦知道原因和解决方案后如何快速修复错误，例如平均恢复时间。
最后，在编写好的产品时，需要更多的业务参与测试，并确保根据其增加的业务价值来衡量测试。切勿将测试次数视为成功的标志。这就像为“代码行”付费一样，因为随着时间的推移，少即是多（更少的测试，从速度上获得更多的商业价值）。
评论
在这种情况下，“三个朋友”是什么意思？可能不是“北美的政治领导人（合起来，墨西哥总统，加拿大总理，POTUS）”或UML的方法论者。
– Peter Mortensen
19-10-21在10:17
这意味着开发人员，测试人员和产品所有者可以共同讨论内容-无需整个团队开会
–迈克尔·杜兰特（Michael Durrant）
19-10-21在10:25
+1，向正确的人提出正确的问题。
– Vishal Aggarwal
19-10-22在9:36
#3 楼
一般而言，创建软件产品（几乎与其他任何东西一样）具有以下主要步骤。各个公司之间可能会有很小的差异，但是主要思想仍然存在。行为要求-它们主要描述了用户看到的内容以及用户与产品的交互方式；体系结构和设计-指定必须如何构建产品；
实际编码；
单元测试（白盒）；
集成测试（白盒和黑盒混合）；
验证测试（黑盒子）。
每次收到投诉时，您需要做的就是评估上述步骤中造成问题的位置。您必须找到最早的步骤。
此统计信息将告诉您（公司）您需要改进的地方。
收集随机样本的50张门票（错误）并仔细研究它们
这是一个不错的开始，但是可以退后一步。由于样本太小，可能无法为您提供最正确的答案。在整个未来，将程序扩展到所有票证不会有任何伤害。如果您不能从中获得非常有价值的结果，则该方法将被放弃-有了它，您唯一改善的机会。
...并进行研究仔细吗？
实际上，为什么只仔细研究一些问题？应该仔细分析所有问题，以便为每个问题实施适当的解决方案。如果没有良好的分析，就会出现错误的解决方案，弊大于利。 br />也许您想说“我只专注于产品开发”。只是一种产品。是好是坏。完成还是未完成。有错误或无错误。您需要更改开发方式才能拥有更好的产品。
评论
这是瀑布。那不是消极的事情，但是您应该意识到这一点。敏捷（当今行业的主要开发风格）还具有行为步骤（BDD），首先是测试失败，然后是单元测试（失败），然后通过测试，然后BDD测试本身可以通过。 BDD / TDD内部的紧急设计很大程度上取代了体系结构和设计步骤，并依靠最新的技术继续抽象化底层。
–迈克尔·杜兰特（Michael Durrant）
19年11月1日在8:22
不仅瀑布。 V型循环也。实际上，所有过程都遵循相同的主要步骤。不同的是步骤/活动的顺序，时间和采用的名称。而且，仅在某些行业中，敏捷才是主要风格，但并不是全部。
– virolino
19年11月1日在8:33
是的，不是某些行业。我在最近有关非敏捷性主题的会议上的印象是，敏捷性似乎达到了80/90％的水平。听说它已在军队中使用-指挥控制组织的定义-我意识到它已经变得无处不在。这些是我的印象。
–迈克尔·杜兰特（Michael Durrant）
19年11月1日在8:51
我的理解是，在产品/服务无法直接杀死人员的地方，可以成功使用敏捷。如果安全（汽车，飞机）成为问题，那么（至少）某些活动将必须遵循不同的流程，敏捷将无济于事。另外，请带一些附加的“盐”（未提供:)，因为我不了解有关在何处使用哪种模型的统计信息。
– virolino
19年11月1日在9:00
#4 楼
很多好的答案。我也遇到过类似情况，为了克服产品问题进行了过程更改。产品质量问题反映了用于开发软件的过程。
对我来说，我的质量检查哲学是我所说的“质量第一发展”。这需要：
提供卓越的性能：用户不应发现错误。
协作：质量是跨团队的责任。
查找清晰度：降低风险和不确定性通过早期测试并经常进行测试，这将提高信心。
考虑一下观点：关注用户体验，可用性和同理心可以提高质量。成为客户的拥护者。
效率：实现功能效率和长期成功的自动化。
好奇：“为什么”和“如果”是最好的问题。
要问和考虑的一般问题：
测试什么时候开始？
如果仅在开发完成后，您等待的时间太长。在此过程中较早发现的错误，缺陷和故障更容易修复，而且成本更低。我发现一旦编写了故事和要求，请与项目经理，项目负责人，质量保证人员一起对其进行审查，以确保其内容清晰明确。错误发生的原因之一是对开发人员和质量检查人员之间的要求的误解，因此，如果您可以更早解决歧义，则错误发生的机会会减少。
设计样机完成后也是如此。根据需求检查设计，以确保它们匹配。通常，在需求和设计完成之后以及开发者开始之前，我通常可以开始测试计划，测试用例设计。如果您要进行测试自动化，则可以在开发人员开始之前开始创建自动化测试。
您是否每周或定期对错误/缺陷进行梳理？
这可以帮助设置错误优先级，严重性以及开发冲刺的错误。错误整理包括质量检查人员，开发人员和用户/客户发现的所有错误。找到所有错误后，您需要找到根本原因分析。这是白盒测试和代码库知识可以提供帮助的地方。
我也喜欢测试部给出的关于修复错误的建议。
是否遵循了错误模板的错误？
每张错误票编写的方法应相同，并包括尽可能多的信息。这也有助于加快错误的梳理速度，并有助于加快根本原因分析。
当确实发生错误时，找到根本原因。挖掘代码，使用5-为什么。最终，您想了解错误的发生过程，错误发生的原因以及如何预防该错误。
您的测试自动化金字塔是什么样的？是否已完成单元测试？集成测试完成了吗？是否进行了UI，端到端测试？如果没有自动化，就该开始了。
开发人员是否使用棉绒工具并遵循短绒棉布中的相同规则集？ ，但它们可以帮助所有开发人员使用相同的编码标准并遵循相同的规则。它们还可以帮助尽早消除bug。
团队对bug的态度如何？ QA是否因为没有找到最终生产的错误而受到“责备”？如果是这样，这种“责备与羞耻”就必须停止，因为它降低了团队的士气。错误将会发生。我们都是人类，这是创作过程的一部分。您如何处理它们很重要。
根据我的经验，当我帮助开发团队进行这些更改时，投入生产和由用户/客户报告的错误数量大大减少了，也意味着客户/用户满意度提高了。
#5 楼
所以现在产品上线了吗？因此取缺陷漏率。发现的后期制作/客户或利益相关者中的缺陷数与质量保证团队发现的缺陷数。在这里，您可以分析错过了多少，并找到造成这种情况的根本原因。拥有相同的pareto图表。找出80:20的原理。然后处理这80％的问题并采取纠正措施。#6 楼
随机样本会给您带来不良数据，因为一方面存在缺陷，这些缺陷会产生大量低影响力的低价罚单，另一方面，存在一些缺陷，它们只会产生一张影响巨大且需要付出巨大努力的故障单解决。如果您只是随机抽样，那么您的选择将偏向第一个，而您真正想要的是后者。因此，第一步应该是对票证进行分类并创建缺陷列表。这些是这些票的原因。然后将这些缺陷从影响最小的分类到影响最大的缺陷。
当您拥有影响最大的缺陷时，您可以开始查看质量检查流程，并尝试找出应该发现这些缺陷的步骤，他们为何找不到它们，以及如何更改流程以便将来发现此类缺陷。
#7 楼
根据您的流程更改的频率，我可能不想查看历史数据，或者想要限制我追溯历史数据的时间。相反，我将建立一种方法来查看新问题并对其进行因果分析。根据发现问题的时间进行优先级排序-在生产或部署后发现的问题是分析列表的顶部，然后从那里开始进行上游处理。您可以应用多种技术了解为什么要注入问题，为什么要发现问题而不是在过程的早期，或者要强调导致问题的所有促成因素。
#8 楼
我认为您应该将重点放在主要问题上，即客户不满意。换句话说，客户希望您的产品如何运作以及产品如何开发运作（产品团队的观点）存在偏差。鉴于您的产品非常庞大，很可能在产品开发过程中逐渐曲解客户需求。我建议您从存在的错误列表中找出这些偏差。破坏的另一点可能是它们之间存在冲突的功能（或需求）。这就导致了错误的应用程序模型本身的创建。在这种情况下，诸如Alloy之类的功能可能会有所帮助。来自软件测试解决方案的以下链接也可能会有所帮助，https://blog.qasource.com/resources/comparing-a-test-plan-vs-test-strategy-for-software- qa
https://blog.qasource.com/resources/enhance-your-software-quality-assurance-and-testing-in-5-steps
https://blog.qasource.com/ resources / compare-software-testing-methodologies-for-your-needs
https://blog.qasource.com/resources/plan-your-software-testing-life-cycle-for-total-coverage
我受雇于QASource。
评论
请透露您与QA Source的隶属关系。通过您雇主网站上的大量链接，人们很可能会将您的答案标记为垃圾邮件。您可以阅读sqa.stackexchange.com/help/promotion以获取有关如何避免被误认为是垃圾邮件发送者的更多信息。
–凯特·保罗（Kate Paulk）
19-10-22在11:48
#9 楼
在我看来，您已经发现了公司的弱点，就在您的问题表达方式上：破裂（甚至存在）流程。说了算，一件产品和一件产品的质量就是导致其创建的过程的总和。
在软件中，这些过程可能包括：
正确收集并理解客户的需求和需求
将客户的需求正确地转换为可操作的需求（指定要采取的行动，从而导致预期结果的需求）
正确地将需求编码为软件产品（并拥有您的代码的所有权）
持续监视产品的状态和对要求的遵守情况
考虑客户的测试；有足够的文档和支持，有条不紊地发布给客户。
反复冲洗。
您的老板可能不喜欢这个答案，但是如果不提高整个公司的流程，您将永远无法生产出更高品质的产品。
是的，是简单的因果关系。
是的，如果尽管您已进行了所有测试，但仍有许多问题无法通过所有这些测试并被客户发现...我猜您根本没有任何流程（或者，您确实有流程，并且它们都被破坏并错误地完成了）。
最后一条未经请求的建议是：如果您的经理没有想提高自己的游戏水平并改善整个公司的流程吗？我会开始在别处寻找。
问题如此之多，其中大多数是在生产中发现的，而且经理人很不情愿，寻找替罪羊是一个时间问题，并猜测会是谁？ ？
#10 楼
产品受影响的区域这是我建议应用80 20规则，了解产品问题并尝试了解受影响的区域，这些将是您受影响最大的关键区域。任何类型的现有指标都可以帮助您做到这一点。
测试数据
如果可能，分析prod中使用的数据并将其与您使用的数据进行比较，可能会有很多差距在较低环境的测试和实际产品场景之间进行操作
自动化
如果尚不可用，请尝试使关键区域回归案例自动化并按计划或在部署基础上运行，这将帮助您快速失败和功能性资源可以执行更多的探索性测试。
评论
您能否详细描述如何在您的环境中实现PDCA？没有它，您的上下文就几乎隐藏了，问题是“范围太广”。谁编写测试？
“弄清楚为什么我们不能提供优质的产品”是一个只有一个答案的问题。如果不允许您解决此问题，我将看不到您如何取得成功。
经理根据数据确定“我们未能提供优质的产品”，这是一个很好的起点。
您是否在这个过程中让客户参与？到目前为止，您问他们什么？