采访中的问题是：
计划明天发布产品。质量检查发现了一个严重的错误。开发团队正在努力修复此问题，但他们远没有解决方案。市场营销团队正在要求发布产品。

作为负责的质量检查人员，我应该拒绝发布该产品
还是应该将该发布与已知的产品一起发送给营销团队
虫子？如果您拒绝发布，则会影响您的年度评估。

有什么可能的方法来处理这种情况？

评论

是否告诉过您是否要回答营销团队的问题？
@corey是的，我说过我将向市场团队发送一封电子邮件，其中包含发行被拒绝的发行说明。
“如果拒绝发布，将影响您的年度评估。” -大概这意味着它将增强您的年度评估。质量检查人员的工作是拒绝。
每个软件的每个生产版本都有错误。这恰好是您要发布它之前发现的。确实，答案取决于组织“关键”的含义。它的意思是“在固定之前不发货”，或者只是情绪化的语言，实际上并没有任何意义。
我会用这个故事来回答：我是在线发票软件的快乐用户。然后它被“现代化”。结果太糟糕了，我不再使用该软件。当我向我的会计师询问替代方案时，她也很熟悉这种变化，“是的，我们遇到了很多类似的问题”。我敢打赌，卖方失去了，不是少数，而是大多数顾客。可用性等方面的差异很大，公司必须意识到他们正在推出劣质产品。但是他们做到了。那是一个非常糟糕的主意。

#1 楼


作为质量检查负责人，我应该拒绝发布该版本，还是将其发送给具有已知错误的营销团队

都不是。您应该让所有相关人员知道存在此类错误。您应该向客户和其他使用该产品或以某种方式参与其中的人（利益相关者）清楚地告知该错误的含义。

最后，提出这个问题的人告诉我，如果我拒绝发布，也会影响我的年度评估。

嗯，这是一个奇怪的系统，“质量保证”人员因不及时发布决定而受到惩罚，因为他们不应该一开始就做出决定，而且不仅是他们可以对产品做些什么。我可以看到在这样的工作场所中向其他人隐藏重要信息的潜力，因为当人们了解到他们无法一手改变某些东西但仍然受到惩罚时，隐藏信息就更容易了。

评论

奇怪的系统。一个人想知道他们是否想要答案：“您激励质量检查团队不要发现错误。认真吗？”

–richardb
20-09-11的19:04
继续强调：开发团队的成员也是利益相关者。他们具有技术专长，可以识别软件系统和开发团队长期健康的风险，并且有义务将这些信息传递给我们。开发人员不会被聘为是人，无论如何都可以运送。业务/产品人员依靠他们的专业知识来突出这样的技术风险。

–亚历山大
20/09/12在17:23
@richardb下一级别的质量检查是指它们有助于防止在第一次出现臭虫时就把它们弄成臭虫（这意味着他们没有找到它们）。但这不是此处描述的内容。

– DarcyThomas
20/09/14'7:24
@richardb他们激励质量检查小组不要拒绝发布。巨大差距。这导致“是的，它存在此错误，该错误会格式化用户的硬盘驱动器并使其计算机着火，但是您激励我从不拒绝发布，因此我没有这么做。”

–user253751
20/09/14在10:10


#2 楼

这主要取决于风险。我可能会考虑成立一个工作组来决定不去的情况。一些示例风险：

技术风险：我们可以稍后再解决此问题吗？缺陷可以破坏数据吗？
商业风险：由于这个问题，我们会失去客户/用户吗？
营销风险：如果不立即发布，增长会停止吗？

也许您可以传达已知问题，也许有解决方法？也许不是。
如果我可以进行良好的风险分析并且我们根据数据做出集体决定，我希望这会对我的年度评估产生积极影响。
如果我的年度评估依据关于我拒绝的发行数量，我将尝试更改该指标。看来具有风险后果的游戏性，主要是我可能将已知的缺陷投入生产，以便短期内我可以获得更多的钱。如果我有债务或其他财务问题，肯定会成为一个问题。

#3 楼

都不行正确的答案是正确告知每个有利益关系的人（因此，负责修复的营销团队和开发人员，以及发现该错误的QA成员以及您作为此项目的QA负责人的人）尽快安排会议，以确定该错误是否值得延迟发布。作为质量检查人员，您在这里要介绍的唯一延迟是阻止发布，直到做出正式的通过/不通过决定为止。
如果计划发布发布以解决bug，则应该然后与市场营销团队协调，以确保用户正确了解该发行版存在已知问题，理想情况下包括有关解决方法的建议。
如果该发行版由于错误而被延迟，则应保持与开发团队密切联系，以便您的质量检查团队可以在可能的修复程序可用时立即开始对其进行测试，并最大程度地减少任何延迟。

另外，拒绝质量检查的事实会影响您的年度评估可能会或可能不会是一个危险信号。如果是必须证实为什么您拒绝发布作为评估的一部分的情况，那是一件好事，并表明他们让员工适当地承担起责任。但是，如果这对您的评估是自动否定的，那将是一个巨大的危险信号，因为这意味着他们或者没有正确理解应该进行的质量检查，或者他们根本不在乎质量检查，在这种情况下我建议您避开该公司。
我建议如果提供这样的信息，您会问到拒绝发布会如何影响您的绩效审核，尽管我强烈建议在回答他们的问题后这样做，以便避免他们的回应可能会以某种方式影响您答案的任何印象。

#4 楼


质量检查人员发现了一个严重的错误。

我可能在这里遗漏了一些东西，但是，答案是否仅此一个就不能完全确定？ “关键”一词不是意味着它可以防止释放吗？如果可以发布，那么它就不是关键，而只是严重。
如果不是，那么，您将确保所有相关利益相关者都得到了通报和咨询，并且公司整体将决定是否释放，比较释放和不释放的可能影响。但是，在将错误归类为严重错误时，是否还没有有效地完成所有这些工作？

#5 楼


明天计划生产发布。质量检查人员发现了一个严重的错误。

在那之前，做到了。这就是我们过去处理类似情况的方式。
计划在午夜左右为我负责Lead QA的一个项目上线。大约凌晨2点，我们发现了一个严重的错误。最佳做法-将新闻“正确传达”给您的产品经理，计划负责人和其他执行伙伴。建立了一个快速作战室，发现无论团队多么努力，都不可能修复。下一步-再进行1个小时的讨论，以考虑所有解决方法的可能性。幸运的是，我们找到了解决方法。进行了代码更改并进行了全面的测试。此缺陷（由于变通办法，现在不是很严重的缺陷）已在发行说明中发布，因为该应用程序大约在上午6点上线。我应该将带有已知错误的版本发送给营销团队吗？

IMO，无论您是负责任的质量检查人员，实际的决策取决于“客户/客户”和关键堆栈持有者。但是，您始终可以协助并影响该“决定”。

#6 楼


明天计划生产发布。质量检查人员发现了一个严重的
错误。开发团队正在努力修复它，但是他们
远没有解决方案。市场营销团队正在要求发布产品。

我们是否在谈论面向互联网的应用程序，例如网站？然后就不应该故意推销一个有严重缺陷的应用程序。

如果您拒绝该版本，则会影响您的年度评估。 ，因此该公司更有可能遭到黑客攻击。这意味着需要花费大量时间和精力进行清理，更不用说声誉受损了。另外，如果您的客户数据被黑客泄露并泄露，则承担法律责任。从伦理上讲，我的意愿是保护公司免遭破坏。也许您必须对管理层采取立场，以保护他们免受自身伤害。
如果发生最坏的情况，您认为您的年度评估会如何？您会因为批准该死的事情而没有对风险进行足够的评估而受到指责。
有足够多的被违反公司的例子让他们三思而后行。只需考虑一下，Equifax不及时修补其系统以解决已知漏洞所需要的费用。这不是只发生在别人身上的事情。即使不是大多数公司，很多公司都在某个时候被黑客入侵，并且可能仍然在他们的系统中藏有后门程序，这是他们所不知道的。我认为问题更多是关于个人道德或风险管理，而不是问答。

#7 楼

我的方法是：


评估更改的重要性；


给开发人员一个时间表来尝试解决该错误（例如2业务天）；


如果错误仍然存​​在，开发人员是否不将发布分支中的更改包括在内（是否存在预发布分支？），否则请优先进行测试/质量检查变更；


通知营销团队产品将发生什么变更/功能。


作为多角色开发人员，在工作时在一个小公司里，这就是我采用的方法。它曾经使想要说“我们拥有功能x”的营销人员烦恼，同时隐藏了功能x实际不起作用。