软件产品发布后缺陷，一贯的思维都是测试组对其负责。
毕竟最后是从测试人员手中出去的软件，而我们需要养成对每个发布后的问题“感兴趣”。
下面我们分类来看看：
1、已知的问题，一切都在情理之中，测试组没有什么好担心的，反而有些成就感；
2、对于一些难以重现的问题的已尝试过的办法或者是怀疑出现问题的环节是需要共享的；如果重现了较难的问题则重现过程必然是值得大家学习的，包括如何分析问题的。
3、对于未测试到的问题，测试组可以从多个角度去分析：a、测试组自身那里需要补漏；b、其他职能组对应的环节如何改善。
对于测试组自身来说，是否按用例执行了？用例是否覆盖到了？异常情况如何汇总？可能在发布后出现的风险如何应对？在多重分析的基础上可以改进组内的测试方法、执行力、测试深度、测试范围、检查预防机制、工作流程、产物要求等等。
对于其他职能组来说也会有很多的分析点，产品组：是否抓住了用户的核心需求，符合市场及外部规律，使得需求变化控制得力，给后端带来的变化少？是否设计了易用的软件？是否对于用户的使用和应用场景有了较深入的调研给后端的开发、测试、部署提供了明确的依据？项目管理组：是否留有时间给测试组执行相应的用例？需求的控制、分析是否做到位了，而不是把问题全部推到后端造成需求引起的问题？整个项目的节奏、目标是否使得项目组成员是否都清楚，方便了开发的设计、测试重点的把握？开发组：是否是设计上的问题？是否是手误如何避免？开发组如何提前发现代码中的这些问题？开发人员如何避免这样的缺陷不再发生？运维组：部署过程是否合规并严格的执行？发布流程中运维组是否严格执行？
以上都是测试组通过发布后缺陷的收集对其他职能组可以做分析的思路，并且也可以要求其他职能组做相应的预防或检查机制。
所以对于发布后的缺陷的分析其实是对整个研发流程的分析，对于各个职能组都有实际的意义！所以希望各个测试人员遇到发布后缺陷后都要仔细思考，不要轻易放弃任何一个缺陷。
当然想做好发布后缺陷的分析就要先做好研发阶段缺陷的分析工作，而这项工作就要从每个Bug的分析开始，从每个Build的TestNotes开始做逐步养成习惯，这样才能逐步提高分析总结能力。
现在所有的职能组都在问测试组，你们能给我们提供什么更高的价值？我想除了不断发现缺陷外，总结分析软件中存在的通病顽疾，提供经验总结和预防措施，一定是体现测试组高价值的途径之一。
