从事测试开发那么长一段时间，一直不知道怎么去评价和衡量这个职业的目标是什么，超高的自动化测试覆盖率？或者超稳定超包容的自动化测试框架？
怎么才算得上是一个优秀的测试开发人员？上周有机会去听了阿里 2 天的公开课，好像明白了一些，拿来跟大家分享一下。
内建质量
在微软有一句名言：“质量是设计出来，而不是测出来的。”当然，这是理想情况，如果产品经理都这么优秀，这个世界早就和平了。
今天我们不说产品经理，我们从测试和开发的角度看，怎么内建质量。
让测试内建质量
为了内建质量，测试同学就要尽可能早地干预开发写 bug，让 bug 死在摇篮里。换句话说就是让开发不要写出可以避免的 bug：
- 产品，开发，测试应该同时参与需求评审会议，澄清需求，达成共识
- 将关键测试点作为需求的一部分，让开发同学交付需求时完成自测
让开发内建质量
从开发的角度看，要提高代码的质量可以有很多种方式：
- 提高自测意识，借助单元测试或者质量分析工具
- 真正理解需求和技术架构，进行 Code Review 或者结对编程
- 评估代码质量或者 bug 数量，跟绩效挂钩
排除开发的自身能力问题，80% 的 bug 都是需求理解不准确的问题，如果开发不愿背这个锅，那就甩给产品经理吧。
由此可见，如果测试不想看见这些 bug，那么你就要帮产品表达需求，帮开发理解需求。
测试左移
上面我们说内建质量其实已经涉及到了测试左移，例如让 QA 在参与需求研讨时提出问题，列出测试点其实已经开始在进行测试了。
为什么我们要测试左移呢？因为发现问题的时间越晚，修复的成本就越高。
图中橙色线条代表了传统测试发现缺陷的时间，大多数 bug 都是在功能测试和集成测试时发现的，最后导致的结果就是发布前加班加点，祈祷不要有 bug 漏到生产环境。
如果我们能把测试活动向左移动，那么就意味着修复成本大幅下降。
但是谈何容易？想要把大部分测试点放在单元测试环境完成，非常依赖成熟的开发环境和极其资深的开发人员。
在阿里是这样实践的，让测试给开发赋能。
开发赋能
从字面上解释就是，测试同学给开发赋于一定的能力，让他们有能力去完成测试，比如：
- 降低测试门槛
- 使用测试工具（自动化）
- 获取测试数据
- 培养测试意识
举个例子，开发同学在完成需求代码后，可以点击一个按钮得到测试数据，再点击一个按钮验证测试覆盖点，喝杯咖啡后就可以看到测试报告。
从上面这个例子看，开发同学其实他并不需要懂测试数据的设计，自动化测试的开发，测试报告的编排，但是他依然可以快速完成需求测试（门槛低），只要他养成习惯（培养意识）。
那么你就会说，这对测试的同学要求是不是很高啊？对啊，回到开篇的问题，如何评判一个测试人员的能力？在我看来就是评判他给开发和团队赋能的能力。在阿里是这样，在微软和谷歌也是这样。
一个优秀的测试人员将测试左移时，并不会将负担转移给开发。相反地，而是帮开发写出更高质量的代码，更高效率地交付需求。
那么测试能左移到什么程度呢？比如让开发在 Coding 时就发现问题，或者还没 Coding 就发现问题，那应该是极好的。
怎么做到呢？刚才已经说过了，测试即需求，把 bug 扼杀在摇篮里。
实践方法
想实践测试左移可以有很多种方法，每个组织需要根据实践情况进行裁剪和调整。
- 参与需求评审，帮助开发理解需求
- 参与架构、设计分析，提早预防问题
- 践行 BDD，TDD
- 单元测试提案，接口测试提案
- 提供模拟数据能力，测试工具
- 制定提测标准，拒绝低质量代码
- 回归测试自动化
- 静态代码分析，单元测试覆盖率
测试左移的概念给整个测试角色带来了巨大的转变。软件测试不仅仅是“发现 bug”，而是致力于“尽可能早的检测和预防 bug”。
参考资料
- 培训课件：阿里 Devops 体系和实践.svg
- 参考文章：What is shift-left testing?
关于作者：
Toby Qin, Python 技术爱好者，目前从事测试开发相关工作，转载请注明原文出处。
欢迎关注我的博客 https://betacat.online，你可以到我的公众号中去当吃瓜群众。