这是来自Reddit上的一个提问。
背景如下：一名QA在整个组织的各层都进行了相关测试，包括用户验收测试（UAT）在内。同时也在 prod 环境中进行了可用性测试，但非完全测试。在prod环境部署完成后，QA 报告了一个prod环境中的bug。开发经理将责任归咎于QA，因为他认为这应该在可用性测试期间发现。
我的问题是，为什么要在 prod 中进行可用性测试？可用性测试并不能确保彻底测试以发现细微的bug。在UAT完成后，难道开发人员不应该负责正确地在prod环境中部署代码吗？
针对这个提问，我们来看一些点赞数较多的评论，看下大家是如何思考这一问题：
Raijku的评论
这里有两件事, 首先：
无论问题是如何进入到线上环境的（除非QA明显在撒谎），如果一个开发经理或开发人员只是指责QA，他们其实是在试图摆脱责任，以显得自己没有问题，但这样做的结果会更糟......这不仅对他们个人不利，也对整个团队不利，质量是每个人的责任，那段代码经过了开发、审查、合并和测试......所有这些步骤都未能发现问题......
现在，优秀的管理者都知道不应责备他人，并且会建立相应的制度以避免类似问题再次发生，所以整个责备的过程只是让愚蠢的人参与愚蠢的游戏。在许多组织中，这种行为会被迅速制止......
不管怎么说，写一份报告，解释为什么问题只会出现在prod环境中，以及是如何发现的/部署后花了多长时间发现的，看看是否有什么办法可以在测试环境下重现这个错误。如果有任何可以预防的措施，那就开始做；如果没有，那就接受这种黑魔法问题时有发生的事实。
其次：
可用性测试在prod环境中应该始终执行，但仅仅是为了确保部署后的主要功能可正常运行。90% 的情况下，如果在测试环境下一切运行良好，就应该没有问题，但 10% 的情况下，一些黑魔法会发生，不同的 prod 数据、不同的机器规格或错误的部署都会破坏 prod 的运行。
所以，考虑到这是最后一步，而且是面向用户的环境，你必须确保它 “活着”（指：正常运行），以防万一。
Confident_Panda3983的评论
产品质量是整个团队的责任，而不是一个人的责任。话虽如此，如果这只是一次性的事情，那可以理解。但如果这种情况以前也发生过，那么最好还是回到起点，分析测试过程，不幸的是，QA必须承担这个责任。因为作为QA，你的工作就是找到测试过程中的bug，并积极采取行动。很抱歉听起来这么严厉和直接。以下几点肯定会对你有所帮助：
- 在自动化方面投入时间。越多越好。
- 编写详细的测试用例，涵盖负向Case、边缘Case、BVT（Build Verification Testing—构建验证测试）、关键业务路径、正向Case。定期审查和更新。记录测试运行情况。
- 提高Prod环境中的测试覆盖率。
- 如果可行，建立一个与Prod环境相对应的预生产环境。这样就可以在不影响实时系统质量的情况下进行测试。
SiegeAe的评论
绝对不是，实际上整个团队都有责任，但指责毫无意义，而且, 我们不可能找到所有的bug。
唯一能做的就是看看它是如何被漏测的，并尝试改进测试过程，以便在类似的问题进入prod环境之前更有可能被发现。
MareDoVVell的评论
如果你的公司试图将一个bug归咎于某个人，而不是理解它其实是软件流程的一部分，那么这是一个根本性的误解，需要加以解决。
Ok-Arugula-4489的评论
每个人都有责任。不仅是QA团队。QA不是bug的守门员。实际上，参与项目的每个人都应该进行测试。而QA应该负责流程改进、测试自动化、培训和协助开发人员如何进行手工测试，但他们不负责prod环境中的bug……这是肯定的。
Jext的评论
在prod环境中总会出现不同严重程度的问题。把重点放在指责不同的角色上，是确保这种情况尽可能少发生的最没有成效的方法。
在我的工作中，如果这个bug严重影响了用户，我们就会进行事故处理流程，然后就流程或技术解决方案进行讨论，以确保降低类似事件的风险。
我们从不指责或争论细节（当然，只要流程是可靠的）。当开发人员第一次严重破坏prod环境时，Slack 频道中也会有一些有趣的事情发生。人们会把它变成一个有趣的事件，并正式欢迎他们加入开发部门，并告诉他们有关他们生产事故的故事。
我们从不指责或争论细枝末节（当然，前提是：流程是健全的）。当开发人员第一次严重破坏 prod 时，Slack 频道中也会出现一些有趣的事情。大家会把它当作一件有趣的事情，正式欢迎他们加入开发部门，并与其他人分享自己的生产事故。
这样，你就能获得自主权和责任感，但又不会感到焦虑不安。这样做还能消除很多关于指责的负面情绪，通常最终都能找到更好的流程解决方案，确保风险得到降低。
