从人性的角度来看，开发人员通常是属于“创造性思维”，自己开发的代码就像是亲儿子一样，怎么看都觉得实现很棒；而测试人员则属于“破坏性思维”，测试人员的职责就是要尽可能多的找到潜在的缺陷，而且专职的测试人员通常已经在以往的测试实践中积累了大量典型的容易出错的模式，所以测试人员比起开发人员，往往更能客观且全面做好充分的测试。
开发为什么不自测？
- 时间和进度太紧（包含开发评估时间不准、拖延症、无规划无预留时间）
- 对自己的代码过于自信，自认为很健壮，无需验证
- 认为是测试的责任，过度依赖测试（实际测试是防范开发自测遗漏或精准测试）
- 不知如何有效自测，覆盖不全或覆盖太全
思维转变
开发质量实际上贯穿影响整个项目流程，项目质量一般由产品设计质量、开发质量、测试质量、验收质量构成，不单单取决于测试质量。开发质量可以细分到代码质量、自测质量、Bug修复质量（包含自测Bug、测试Bug、验收Bug修复）
开发自测是趋势
开发人员做好自测，非常必要，也是大趋势。在Google公司，纯粹的测试人员很少，前期都是开发自测（包含必要的测试），后期才是用户体验方面的测试；从成本上分析，Bug越晚发现修复成本越高；从修改的效率来讲，越早处理会越快。另外，写出高质量的代码，是能力的体现，专业的体现，自身价值的体现。一个优秀的开发者，自测的Bug一定会多于测试发现的Bug，也就是轮到测试的时候Bug数量相当少，呈漏斗状过滤。
测试左移&测试右移
软件工程传统瀑布模型 V模型 - Paul Rook
www.stickyminds.com/article/shi…
“测试左移”正是在弥补瀑布模型的不足，即不要让测试工作只成为交付前的最后且唯一的质量保障手段，应该往前提，需要贯穿于整个软件研发生命周期中
测试左移不是测试工程师左移，而是测试工作（质量保障工作）左移！
有哪些方法和工具？
测试左移
有哪些活动可以提高质量上限（举例）？
- 健康的项目流程（合理并且严格遵守的项目流程）
- 合理的需求分析（评估需求的质量，分析需求的合理性以及完整性）
- 出色的系统架构
- 完整的系统设计（评估设计的质量，分析需求的合理性以及完整性）
- 充分利用静态代码扫描
- 进行研发标准的定义
- 更早的测试分析（先于开发完成需求的分析，做好各种评审的准备）
- 尽早的测试执行（提早参与测试执行，在集成前就发现一些问题）单元测试、BDD、TDD
- 有哪些活动可以提高质量下限（举例）？
- 健康的测试流程
- 优秀的测试用例
- 合理的测试计划
- 合适的自动化
- 适当的探索式测试
- 开发自测（TDD、BDD，测试提供更好的用例、技术支持）
- 团队质量意识的培养
- 参与需求评审，帮助开发理解需求
- 参与架构、设计分析，提早预防问题
- 践行 BDD，TDD
- 单元测试提案，接口测试提案
- 提供模拟数据能力，测试工具
- 制定提测标准，拒绝低质量代码
- 回归测试自动化
- 静态代码分析，单元测试覆盖率
测试右移：
- 闭环的线上问题反馈-检查-解决-更新流程
- 更便捷的日志查看、回传服务
- 丰富有效的log，便于问题的快速定位
- 丰富的监控指标（例如业务异常点指标）
- 成本监控（例如短信发送等）
- 关键指标每日监控（服务器指标）
参考：
炮轰“ 测试左移” ，向软件测试领域的“ 歪理邪说” 宣战 | IDCF-技术圈（推荐）
都在说测试左移和右移，只有这篇文章说明白了] （推荐）