楼主新入职的公司是金融行业，相关产品都是外包的，即开发和测试都是由外包公司完成。产品测试质量一般，上线后多多少少还是会有一些生产问题出现。
请教下各位测试朋友，特别是有相关经验的测试朋友，对于这种情况，作为甲方的测试管理人员以何种方式介入产品测试，在项目开发上线各阶段怎样去参与并高效管理、提高产品质量呢？
补充下，我们基本上是产品外包，外包人员在其公司完成产品的开发和测试，部分情况下会驻场测试。所以我想从制度上进行约束，并参与到产品研发测试全流程（可以试着出一些质量规约指标要求等），在各阶段监督测试工作，把控测试质量。
欢迎大家不吝赐教，谢谢！
以下是个人愚见，供参考。
1.需求阶段：
提前介入需求分析，组织需求评审会议，参会人员：业务（产品）、甲方项目（开发）经理、甲方测试经理、外包开发、外包测试。目的是让各方对业务需求达成共识。会后要求测试人员产出测试大纲文档。
2.设计阶段
（1）组织需求反讲会，需求反讲主要是让开发人员根据需求规格说明书讲解自己所负责需求的实现。目的是编码前再次确认需求，如遇到开发人员理解有误的地方，可以及时纠正。
（2）组织用例评审会，建议测试组内自评后再召集项目经理、业务、开发一起评审。可安排在需求反讲会一起。
3.测试阶段
（1）每个发布版本，要求外包测试组长给出测试计划。
（2）要求外包测试组长每天发日报，日报主要内容：各个需求的测试执行进度、是否按计划顺利执行、风险提示、缺陷情况等。
（3）测试数据要求留存，以便发布前的抽查；同时也是用例执行的证明，后期追溯生产问题可作为依据。
（4）推进产品人员参与 UAT 测试。
（5）待外包回归测试通过后，特别重要的功能或流程自己可以测一下。
4.持续优化与改进
（1）测试资产积累：测试用例库、数据流图、系统架构图等测试资产进行持续的积累与维护，做为测试工作的重要资产，用以测试需求分析、用例设计、新人培训等。
（2）生产问题复盘：对于因各种原因造成的测试漏测缺陷，要进行详尽的分析，并制定相应的改进措施，形成问题的 PDCA 闭环管理，避免同一类型问题重复发生。对于生产问题，需要制定一定的惩罚机制。
我的建议是重测一遍，不能保证质量的情况下，只能依赖自己（甲方测试）。外包可以视为保底测试，然后在适当时机把自己（甲方测试）发现的问题同步给外包测试，修复完毕后要求重测；多次发现重大问题的，可以把压力给到他们
果然外包是不能呆的！
没有这方面经验，纯 YY，当做脑暴就好。
1、看楼主甲方这侧有多少资源，是否能重测。能重测最好是重测，掌控能力最强，但估计既然都找外包了，内部应该不会留这么多资源可以支撑重测。
2、无法完全重测，那就做抽验，可以以验收的名义让业务人员来试用下，相当于多把一道关。
3、通过看外包的用例设计、用例执行数据等来确认外包的测试范围情况。异常场景是否有考虑齐全，出过生产问题相关的范围是否有考虑到位，对于设计考虑比较齐全的部分外包同学给予一些嘉奖，促进大家做更全面的用例设计提高质量。
4、适当的考核机制给到外包质量压力，比如生产问题出现问题及级别达到一定程度，需要外包承担部分损失等。
陈恒捷
回复
你的建议挺好的，谢谢！
补充说明下，我们是产品外包的，外包人员不是驻场办公，所在我在想如果能在制度和整个研发测试流程上加强对外包测试工作的引导、质量的监控就比较好了。
虽然没这方面经验，但经历过某次迭代需求（未涉及到大的复杂逻辑），找别的项目组人员请求支援
当时是支援人员验证完了，准备上 UT，我们就走了下冒烟测试用例，发现大多都走不通，当时时间又紧急，就几个人拿下去分下，加班加点赶着上线。
觉得这个需要对方提供每一条执行结果；
每天同步进度和 bug 情况并同步给相关人员和领导；
每天晨会或语音会议；
告知上线跟进，出现线上问题也要负责，减少因测试方出现的漏测和场景未考虑全情况；
其实这种问题在外包项目中很常见、以下几点是个人的一些看法以及之前遇到的过的一些解决方案，欢迎大家补充更正和完善
个人觉得要从源头开始解决问题
1：需求文档交付之后，你要求对方测试人员需要准备测试方案 OR 测试 CASE 的评审，其实这个过程你是可以参与甚于连产品也可以参与，在整个评审过程从 CASE 上也能发现很多不足或者欠缺
2：最好要求有上线前的验收工作，这项工作肯定是甲方来完成的，大部分情况会给到产品、设计等来完成，这个过程你可以参与或者给一些注意事项给到你们的验收人员让他们参照去验收
3：针对项目完成出现了问题，不论是测试原因还是开发原因都要做记录给到你们对接外包的相关人员、去施压一定压立、不然也没人把问题当回事
1.回来先评审需求吧，都实现没有，正向流程，逆向流程，是否形成闭环
2。再测试人员进行一轮测试或者说验收
以下是个人愚见，供参考。
1.需求阶段：
提前介入需求分析，组织需求评审会议，参会人员：业务（产品）、甲方项目（开发）经理、甲方测试经理、外包开发、外包测试。目的是让各方对业务需求达成共识。会后要求测试人员产出测试大纲文档。
2.设计阶段
（1）组织需求反讲会，需求反讲主要是让开发人员根据需求规格说明书讲解自己所负责需求的实现。目的是编码前再次确认需求，如遇到开发人员理解有误的地方，可以及时纠正。
（2）组织用例评审会，建议测试组内自评后再召集项目经理、业务、开发一起评审。可安排在需求反讲会一起。
3.测试阶段
（1）每个发布版本，要求外包测试组长给出测试计划。
（2）要求外包测试组长每天发日报，日报主要内容：各个需求的测试执行进度、是否按计划顺利执行、风险提示、缺陷情况等。
（3）测试数据要求留存，以便发布前的抽查；同时也是用例执行的证明，后期追溯生产问题可作为依据。
（4）推进产品人员参与 UAT 测试。
（5）待外包回归测试通过后，特别重要的功能或流程自己可以测一下。
4.持续优化与改进
（1）测试资产积累：测试用例库、数据流图、系统架构图等测试资产进行持续的积累与维护，做为测试工作的重要资产，用以测试需求分析、用例设计、新人培训等。
（2）生产问题复盘：对于因各种原因造成的测试漏测缺陷，要进行详尽的分析，并制定相应的改进措施，形成问题的 PDCA 闭环管理，避免同一类型问题重复发生。对于生产问题，需要制定一定的惩罚机制。
以下仅是个人意见，仅供参考：
情况一：如果外包同学的能力一般，那么就由全职的同学产出 case，根据 case 的核心程度以及优先级对外包同学进行划分并且执行，并要求每条 case 需要进行标记（执行人，执行结果，备注等），便于追踪每条 case 的执行情况及定责任，全职同学在上线前进行核心功能 case 的验收
情况二：如果外包同学的能力也很好，由外包同学产出 case,全职同学 + 外包同学一起进行 case Review, 并对 case 进行划分组吗，进行执行，验收
