单纯经验交流一下
我遇到正常的软件UT与品质验证流程吧：
1.开发者写完程式码与UT。
2.在自己电脑上跑UT。
在自己电脑上跑UT，是部门不认的UT。
没人知道你自己电脑的环境与有没有动手脚。
3. Commit and push 到 repository 开发分支。
4. 启动 CI ，CI有个stage会去跑开发者的UT。
由于UT已经不在开发者的电脑或环境跑了。
所以有许多优点：
a. 环境是独立的，而且通常设计成接近 release后的环境。比较容易提早发现问题。
b. 开发者有没有做好UT，Pass UT，是有自动记录，而且自己没有权限修改的。避免了前
5. 所有CI流程都过了，UT过了，开发者以外的工程师或主管，才开始审核程式码 code review。(正常情况，至少两人)
这时审核的人，系统都会自动纪录。
比较大的公司也会有规定，或惯例该review哪些重点。
6. Code review 过了，系统才会自动 merge到 "开发"分支。(因为还没给QA测过，没办法release)
7. QA 测试前，先再次跑CI流程，包含UT，确认开发部门有按照基本品质要求走。(避免被Dev部门黑)。拉取程式与自己的测试程式，在接近生产环境的设备上测试。
8. QA测试出报告，有问题，提issue修改。没问题，上系统或出Mail说验证通过。(为品质背书)
9. 程式码品质Ok了，要将 dev merge到release分支。开发者根本没这权限。只有技术的owner或 Tech lead 有merge权限。有merge权限的人，要对这程式码品质负责。
以上的流程，已经简化蛮多细节了，而且变化很多，同家公司不同部门细节也不同，但大原则没变。
看似复杂冗长，其实大多机器自动化去做，大多写程式就能完成自动化，习惯了就好。两个星期跑release 一个线上版本很正常。
线上系统出问题，谁有责任：
开发者，owner，开发者主管，测试QA工程师，QA工程师主管，PM都可能会有责任。
大家不是靠嘴去争的，拿出Log与证据来讨论吧。
自己开发电脑上有没有Bug或 Log根本没人看。
Bug是否产生，所有Log，都在第三方电脑(或云端)，而且是接近Release环境的。
以上的流程与技术其实也不难，open source都搭建得起来，流程摸久也就习惯了。
简单成本就能大幅提高软件品质与工作效率。最大差异在于，你有没有待过这样的工作环境，学习到这种工作观念而已。
(可以思考一下，以上有哪些点，怎么改善自己工作流程，不用硬套别人公司做法)