专业测试人员路在何方？-InfoQ

“架构师 Jack”在自己的博客里发表了一篇文章，探讨专业测试人员的未来发展和不同测试的相应分工，该文章在微博中引发大家讨论。

他在博客中指出：

未来的 IT 世界有可能会发展出一种新的场景和分工：

基本的功能测试设计执行和白盒测试技能应该让所有开发人员都所具备，然后才能解放出专业的测试人员去做复杂的测试工作（非功能测试、beta 测试、测试执行平台打造等），有时间去研究如何提高整个研发团队的测试质量与测试效率，更好地辅导开发人员掌握基本测试技能，当然开发人员依然要通过交叉测试来解决测试心理学的问题（不能自己测试自己）。开发将对自己的局部代码质量负责，测试专注整体架构的质量与团队的整体测试体系建设。

这种模式的收益：团队中功能测试人员的数量会减少，研发中的很多低级 bug 会尽早在开发团队中被发现从而减少 bug 后期发现的成本和沟通成本，既减少研发成本又能加快研发速度。

这样一种测试分工模式成为现实后，测试人员的工作会更有创造性更有趣，更偏重脑力劳动，而简单的测试工作岗位会更少，市场会需要更多测试专家，简单的测试设计和部分手工执行会由开发人员担当，更多测试执行由自动化来实现，而这也正是敏捷开发模式中的现象。

未来某些公司中 tester 会出现少而精的状况但是不会消失，当然由于各个公司组织能力建设的程度不同，吸引中高端人员的能力不同，现有的测试模式和新的测试模式会长期共存，而那些能吸引中高端人才的公司则会出现更高效率的研发团队，结果是测试人员的工作更多是技术创新，开发人员测试工作的技术顾问和执行复杂的测试任务。

他的这篇文章在自己的一条微博中发表，并引发讨论。

柴阿峰指出：

在互联网企业是这个意思，在传统 it 企业，军工，安全，金融类企业不一定。

架构师 Jack 的回复是：

冷静想想，传统 IT 企业，电信企业，金融类也是可行的。让测试专注非功能专项测试和探索性测试，验证测试开发团队完全是可以做的，让开发者自己对自己的代码质量负责，不让测试与开发猜谜语。

对此，柴阿峰认为：

传统 it 的弊端在于开发被需求和进度拖着走，时常拖到项目发布前夜。所以开发团队疲于应付进度和变更，一旦让他们转换为测试开发结合模式，来自开发人员的阻力就出现了。还有就是，传统 it 从业者素质和互联网企业比，略低。

土司阿哈也回复了柴阿峰的说法：

最后一点貌似和你说的有出入，以银行和电信行业为例，她们所聚集的专业人才和 it 支撑人才觉得不必任何一个互联网企业的人才要少，看看四大行和其他股份至银行以及三大运营商的招人条件，只不过是体制、行业特点或者其他原因，没有充分调动他们的潜能而已。

柴阿峰也觉得自己这么说有点偏颇了：

确实当下传统 IT 士气低落，人员潜能没有充分挖掘。其实测试是典型的工程管理分工。非独立测试向独立测试转型以后，出现了一些弊端，所以现在趋势有些反转。不过有个观点我认同，就是测试并不能把本省很烂的代码测成高质量。

我是猪小能提到的测试流程与人员的问题：

目前在公司推测试驱动设计的早期测试出现瓶颈。测试需要提前开发半步，需要积极的拥抱需求，不停的重构测试方案，而开发会保证得到一个相对稳定可靠的环境。不过队伍带出来了，大家都觉得很爽，喜欢这种模式。不过会出现推太紧了，开发没空交流，早期暴露的问题仍然无法完全解决，依然会流入后端。

架构师 Jack 回复：

不过会出现推太紧了，开发没空交流，早期暴露的问题仍然无法完全解决，依然会流入后端－－－与我过去的实践经历一样。是正常现象，针对早期测试活动要有一个好的心态，尽力而为推动开发解决问题。人性的弱点是要亲眼所见羊跑了才会去补牢。要体谅大部分人都只是凡人。

我是猪小能求助：

目前我们也在让开发逐步具备这种有效自测试的能力。靠做出可测试性极强的预测试用例，配合代码覆盖率的度量进行。感觉比较大的问题其实都不是方式方法的问题，而是开发个人综合能力的问题，主要是执行力和意识，认为这些都不是我该管的，我只想纯编码。又不能强硬的用 KPI 度量。挺麻烦，求老大支招。

架构师 Jack 认为自己之前发布的一条微博可以解决这个问题：

基本的功能测试和白盒测试技能应该让所有开发人员都具备，才能解放出专业测试人员去做复杂的测试工作，去研究如何提高团队的测试质量与测试效率，更好地辅导开发掌握基本测试技能，开发还需要交叉测试来解决测试心理学的问题。开发对自己的局部代码负责，测试专注整体架构的质量与团队的整体测试体系。

我是猪小能认为：

将守护质量的事情丢给开发，测试只做提升质量的事情，能力会更专一。尽可能的把 verification 和 test 剥离开，各司其职。这两个方向上的度量标准都不同，培养人的能力模型也不同。保证开发高质量自测目前我想的是，自测就只做验证，守护质量。验证现有质量能否达标的一个较好的衡量标准就是代码覆盖率咯。

对于架构师 Jack 的文章，土司阿哈提到：

是不是可以这么理解，目前测试人员对业务验证的部分交个开发人员去做，对开发设计验证的部分让测试人员来做？如果是这样的话，那么一个银行业务可能涉及到金融学，会计学，统计学，审计学，税务等等，那么一般人员是可以完成这个任务？目前银行测试时通过详细的分析设计，详尽的测试执行记录来保证质量的。

另外对探索性测试有一个想法，探索性测试实际上是传统意义上自由测试的一种系统化总结，或者说是测试执行的一个实例，而并没有上升到工程理论上，他可以解决强用户特征方面的一些测试问题，但是不是能解决所有问题，值得商榷；觉得目前它的商业化成分比实际价值更多些。

架构师 Jack 认为：

如果是开发金融学的代码就有其对应的开发团队利用功能测试的方法做基本的功能实现代码的验证，再由懂金融学的 tester 运用探索性的方法做超出代码实现的测试看软件设计是否存在问题。非功能测试还是由专业 tester 来做。

探索测试实施要分几个不同层次，执行测试补充仅是最初的层面但总体而言我的经验是更多用于功能测试阶段，可以代替目前绝大多数的功能测试用例。在某些产品的功能测试甚至用探索性测试所覆盖到的代码和场景比传统的功能测试设计的用例更宽和更全，更别说对测试设计和测试维护效率的提升。

吴穹 adam 提出了自己的看法：

同意 Jack 对未来团队中开发测试协作模式的判断，我目前的思路是让开发人员负责持续集成环境下单元测试，自动化功能测试脚本的更新（功能测试基本框架已由测试搭好），测试人员在此过程中提供必要的功能测试方面的技术支持，而测试人员则负责预发布环境下的自动化测试以及其他未测风险的手动测试。

但是我不同意这个所谓测试心理学问题,“自己不能测试自己”（我知道这个说法也不起源于 Jack），开发这时做的是一个自我验证，我交付的代码是否达到了我所预期的效果，这件事自己做最合适，交给他人反而会增加沟通成本。

其实古话还说要，每日三省吾身，开发人员最知道我这段代码是干嘛的，所以自验最容易，当然，这并不是唯一的测试，因为别跟我说这个测试不完整之类的空话，但长久以来的这个所谓公理更让我体会到一种测试是我的地盘，你们开发人员不懂，也不需要懂的味道，说到底还是 Job Security, 这才是心理学。

@段念 - 段文韬也支持吴穹的看法：