@matrix1010
“首先，程序员是很容易犯低级错误的，就算是老司机也经常因为低级错误翻车。如果你的低级错误直到 QA 阶段才被发现是很严重的内耗，也会降低团队间的互相信任。”
//对不起，我看到的是单元测试发现的低级错误本身也是极其稀少，更多的低级错误可以通过代码审查、集成测试轻松地发掘出来。因为没写 UT 而让低级错误流到 QA 阶段，本身就反映了团队的能力堪忧。

“真的无能为力吗, 还是只是你们团队的技术水平不太够，或是你只是为了糊弄一下随便写个测试？”
//或者，能否请你举出些实例，关于单元测试能发现设计问题、性能问题、并发问题？在多线程 /进程下跑的用例还算单元测试吗？

“敏捷开发配合自动化测试配合严格的 Code Review ，再加上技术实力靠谱的团队，这样才能实现真正的高质量快速迭代，你可以专注于迭代新功能，而不是担心别人加了个功能 /改个功能把你原来能用的东西改坏了。”
//技术实力真的靠谱的话，没有单元测试照样能写出高质量代码。反之，如果水平有限，靠强制式的单元测试约束也没法阻止烂代码的产生。你不能把高水平个体的脑力劳动成果归结于单元测试流程的功劳。

“也别总是黑印度工程师，国内很多工程师可能并不如印度工程师。另外国内大厂很多是依靠很大的 QA 团队进行人肉测试，才确保了你用到的东西没问题。”
//我算黑他们吗？凭实际输出的代码质量客观评价而已。很大的 QA 团队进行人肉测试，在你这里成了减分项了是吧？别忘了 Windows 10 缺陷如此之多，原因之一是因为笃信自动化测试，解散了曾有的人工测试部门。我举的例子里的印度团队，也是漂亮的自动化测试指标霸榜，可是被发现的 Bug 们可以都把人蠢哭，但凡有个人类测过一遍也不至于那样。