用户报告错误，先发送给质量检查人员还是程序员？

#1 楼

取决于
每个公司都有自己的流程来处理客户报告的缺陷。我最熟悉的一个或多或少如下：

客户支持人员尝试重现缺陷并使用任何其他信息更新报告
客户支持或产品负责人搜索缺陷管理确定先前是否已报告缺陷的工具。在大型/复杂的应用程序中，通常会针对同一问题进行多次报告
，如果在此阶段将缺陷确定为真正的缺陷，则将报告移交给产品开发团队。它可能会进行测试以获取更详细的再现，也可能会进行开发以进行更正，或者可能会进入一般的待办事项以进行修饰和估计。
紧急情况通常会通过立即再现，估计并计划进行尽快修复，以最大程度地减少客户问题。不太重要的缺陷将通过正常的估计和计划过程进行。
如果缺陷是紧急修复程序，则可能会在补丁程序部署中发布，具体取决于当前的发布时间表以及是否需要立即修复。 br />
其他一些影响客户报告缺陷处理方式的因素：

如果该软件不是多租户SaaS产品，则可能会向客户提供特殊的补丁程序版本（s）受到影响。
如果该软件是多租户的，并且具有处理a / b功能的能力（即可以将软件的更改推广给一小部分用户，而其余用户则可以继续使用） （使用以前的版本），则该修复程序仅可用于该客户，以便更详细地检查该修复程序不会对其他客户造成问题。
如果客户具有将对当前功能的更改请求报告为错误的历史记录，则可以将更改作为错误修复进行，但不优先考虑立即发布（这种情况经常发生。这种情况有时发生的频率很高。） />这离完整清单还有很长的路要走，但是它应该使您对客户报告缺陷时所发生的决定有一些了解。

#2 楼

如果有，这取决于您的政策。
也可能是它进入了采购订单，他们应该在继续修复或将其放入积压之前批准它。

#3 楼

这取决于公司与公司之间的关系以及组织的工作文化。
在我目前和以前的公司中，
当最终用户首先报告错误时，它会去/指派给质量保证团队。
然后质量检查小组会尝试在较低/测试环境（沙盒）中复制它。
如果是有效问题，则质量检查小组会记录重现它的确切步骤，然后将其分配给开发人员/程序员进行解决/修复。
如果无效，则将其传达给用户。此过程将减少程序员的时间。

#4 楼

首先，用户应该使用报告系统进行报告，他们不应该知道报告的去向。
从那里开始，它取决于公司的规模，产品和成熟程度，您所承诺的SLA，公司拥有的资源以及您期望的问题类型。能够解决简单问题的第一线响应者，因为他们认为大多数问题实际上是用户错误，配置错误或未阅读手册的人员。产品经理会收到有关更严重问题的警报，他们会首先对将其转发到何处进行分类。没有足够的带宽来查看用户问题，因此开发人员每天早晨都要检查外部问题公告板，如果问题似乎需要重现，则测试人员将对此提供帮助。


一家中型公司交付安全性至关重要的软件时，必须迅速解决问题，因此整个开发组织都应在召集职责下检查每个问题的到来。如果在工作时间内遇到问题，则待命人员会尝试对其进行分类，如果问题太重而无法重现，请寻求测试人员的帮助。 ，问题是通过社区论坛报告的，其中许多问题是由社区成员回答的。产品经理或具有特殊角色的人员监视论坛并查找需要开发人员注意的问题。已将邮件发送给整个相关团队，团队负责选择将其分类的人。

#5 楼

通常，即使仅由一个人执行，在处理错误报告时也有3个“阶段”。它们是：

尝试重现该错误，确定是否可以原样重现该错误，或​​者是否需要更多信息，需要采取什么步骤，仅仅是用户错误等。
确定这是否是需要纠正的行为，以及是否如此紧急/重要
如果确定了实际问题以及何时需要优先级，请解决问题并确认在步骤1中确定的行为不再产生错误，并检查是否引入了其他非标准行为。

在许多开发人员很少的小型公司中，倾向于直接跳到第二阶段-开发人员认为他们知道错误是什么（通常假设最有可能是用户错误），并在尝试重现它之前确定是否值得跟进。他们只有在（如果有）对其进行修复时，才返回到第1阶段。如果错误报告首先发送给测试人员，则他们更有可能执行第1阶段，因此这是首先将所有报告发送给测试人员的一个论据。但是，测试人员可能会花费大量时间尝试重现开发人员可以立即说“这是XY系统的限制”或“是的，我知道，这是修复列表中已有内容的副作用”的错误“
，所以我建议开发人员和测试人员都可以看到最初的错误报告并希望就此进行交流，但随后，测试人员有责任在对阶段2进行评估之前重现/确认错误。

#6 楼

为了增加“取决于”答案，我想说的是，为您的公司/团队确定适当流程的主要指标是如何使利益相关者（最终客户和公司）最快地解决问题）？
对我来说，这意味着确定将问题正确且适当地分类的原因（即，这是仅会影响单个客户的罕见情况，还是会影响每个人，但有明确的解决方法，是吗？需要尽快修复的内容等）。分流的下游，即确定漏洞的优先级，进行工作等也是要定义的其他步骤，但找出分流该错误的最佳方法是第一步。

#7 楼

通常，与测试人员相比，程序员是一支更熟练，更昂贵的劳动力。因此，我认为，为了实现最佳的工作划分，测试人员应该收到所有错误报告。然后，测试人员应该处理那些他/她可以解决他/她自己的错误，并且仅将困难的错误传递给大手笔/程序员。这样，程序员可以花更多的时间进行编程。

#8 楼

在理想的世界中？您的支持升级过程涉及检查可重复性；用户错误非常普遍，您既不想花费质量检查，开发人员或PO / BA资产来过滤掉简单的内容。但是，您也永远不想告诉客户“我们无法复制它，我们忽略了这个”。人们显然不喜欢被汽油打扰，这就是它将如何发生的。一旦排除了明显的用户错误并将支持提升到最高级别，下一步通常是以下四个步骤之一……理想情况下，这四个步骤中的哪一个应该对上下文敏感：

如果有理由怀疑它应该是可重复的，但他们不知道该怎么做，请标记一个质量检查资源以帮助进行简短的咨询。这条路径是关于利用QA丰富的经验来执行系统的极端情况，并且在客户尝试“做一些奇怪的事情”时特别有用，而这很可能使系统的较少使用部分得以行使。
如果有理由认为它可能不是系统支持的用例，请标记PO / BA以检查它是否是实际的错误，或者仅仅是功能不足。使用设计良好的软件，这实际上应该很少见，因为系统应该清楚地告知用户，他们的尝试功能尚不受支持（但是），但是总会有一些错误。
如果似乎是“有点古怪”，或者出现了一些意外情况，例如堆栈跟踪（即“一开始就永远不应该发送给客户端的东西”），请标记开发人员来承担此责任检查。许多公司选择在技术支持/内部升级不提供支持的情况下选择一名待命的开发人员（而不是管理人员/“客户在尖叫血腥谋杀和诉讼”升级）。
如果所有其他方法均失败，尤其是当它击中路径1或路径3并且需要进一步升级时，请致电您的专家/“疑难解答”。这是您组织中的人，即使是最复杂的问题，也具有接近神秘的能力，并且至少知道一些可能出问题的地方以及如何开始尝试进行诊断。如果没有人，而且您的组织规模很大，则应预算以解决此问题。您不会经常需要它们，但是当您这样做时，它们绝对可以节省您的培根。请注意，尽管这可能是“高级开发人员”，但通常他们更接近DevOps，因为解决达到此级别的问题通常需要多元化的背景。产品，我会说您确实确实需要一套适当的分析工具。并且可能会花费开发人员的资源来“完全”连接它们，尽管即使仅提供基础知识也将比大多数人意识到的多。没有这些，尝试诊断SaaS环境中的任何复杂问题充其量要比需要的痛苦多得多，并且在最坏的情况下简直是令人难以置信（甚至什至根本不可能）。

#9 楼

当用户报告问题时，质量检查人员/测试人员应对其进行审查并在理想情况下将其重新创建，然后再让开发人员接触该问题。除非用户是软件的代码级专家，否则他们将仅从其知识领域进行报告。任何直接遇到该缺陷的开发人员都需要在修复该问题之前重新创建该问题。在用户和代码之间拥有所谓的QA层，可以确保正确报告缺陷，从而及时修复和发布缺陷。

#10 楼

听起来您好像缺少生产支持/问题跟踪过程，因为生产问题永远都不要直接进行开发或测试。
即使没有人扮演正式的支持角色，一个好的问题跟踪过程和系统也可能以可重现的方式帮助捕获问题。写得好的问题报告应该像一个很好的测试案例一样阅读。开发人员可能是个好主意。

#11 楼

在“我的当前项目”中，由于需要快速处理问题，因此将其同时分配给开发人员和质量检查人员。质量检查（QA）尝试复制问题，而开发人员（Developer）尝试进行彻底的代码检查以确保其在给定的情况下可以正常工作。有时质量检查首先解决问题，有时是开发人员首先解决问题。不同组织的过程有所不同，而且还取决于质量保证/开发人员当前的工作量。最后，团队的努力才能提供高质量和出色的用户体验。