洞见101之测试左移实践
前言
在以前传统的软件开发流程中，大部分项目都是使用瀑布模型来进行开发。瀑布模型中最为典型的一个步骤就是将大规模的测试工作放在软件功能开发完成之后。但是随着软件规模的增大和业务需求的不确定增多，测试工作越来越困难，成本也越来越高，导致测试效率越来越低。并且随着公司对于研发效能的追求，所以业界有些公司发起了去测试化的活动，并且裁掉大量的在传统研发流程中只做手动测试的测试人员。那么在当前这样的情况下，测试人员应该如何体现自己的价值，并配合研发效能的改进，是一个需要重要关注的一个问题。在各种测试方法和实践中，测试左移也许是最有效配合研发效能的一种方法和实践。
什么是测试左移
测试左移并不是全新的测试方法，而且已经出现了很久了，早在2001年，Larry Smith就在他文章《Shift-Left Testing》中就提出了测试左移的概念和相应的实践。测试左移最主要的方法就是将所有测试相关的工作左移到研发过程中的某些阶段里面去，比如将单元测试左移到编写代码的过程中，将用户验收功能测试相关的一些工作左移到用户需求分析和设计的阶段去做等，基于V字模型的测试左移工作可以见下图：
为什么要做测试左移
众所周知软件开发中最大的浪费就是返工（rework），不管是因为修补Bug而返工，还是因为理解错误了需求而写错了代码而返工，都是巨大的浪费。解决这些浪费的一个有效实践就是测试左移。除了消除浪费，测试左移还可以对于问题早发现早修复，节约修复成本；促使测试人员、研发人员和业务需求人员更好的协作；能很好的增加测试的有效性，并且还可以帮助团队开发出更好的自动化测试。
测试左移最主要的实践
如果想要有效的实施测试左移，就需要相应的一些测试实践，其中最为重要的几个测试实践就是测试分析与测试设计，提高软件可测试性，有效的实施ATDD和UTDD。
1. 测试分析 与 测试设计
测试分析与测试设计是测试领域的基本功，也是最重要的部分。如果没有良好有效的测试分析和测试设计，那么后面所有相关的测试工作都可能无效或者效果不好。所以在测试左移中，测试分析和测试设计也是最为重要的实践。其中测试分析包括分析产品，分析业务，分析业务架构和技术架构等，而设计则包括设计质量体系，设计测试策略，设计测试用例和设计测试架构等。这些相应的工作都是需要左移到相关的研发阶段中去。
2. 可测试性
提高软件可测试性也是测试左移中重要的一个实践，因为它可以有效的帮助团队设计适合团队的有效的测试策略；需要测试人员参与到软件的架构和设计工作中，并提出相关的可测试性需求，帮助研发人员设计出易于测试的软件架构和代码模块，从而增加测试工作的效率和有效性。提高软件的可测性，还可以增加研发人员实施ATDD和UTDD的效率和有效性。
软件的可测性一般包含可控制性、可观察性、可隔离性、可理解性、可自动化性、关注点分离、异质性等。如果在测试左移的实践中有效的提升软件的可测试性，则测试工作的效能也能得到极大的提高。
3. ATDD & UTDD
对于开发人员，测试左移中最为重要的实践则是TDD（包括ATDD和UTDD）。如果想高效的实施TDD，是需要统一实施ATDD和UTDD，通过ATDD有效的传输业务知识和验收条件，再通过UTDD完成符合验收条件代码设计和代码编写。具体的实践步骤见下图：
由此可见，ATDD和UTDD可以帮助开发人员梳理和理解需求，还可以帮助开发人员获得更好的代码设计，并且可以有效的减少返工（Rework），然后获得大量有效的测试用例和自动化测试代码，最后可以实现快速反馈，提高软件内在质量，从而提升软件的研发效能。
测试左移动的前提
测试左移虽然有这么多收益，但是并不是每个团队都可以实施。如果团队不满足一些前提条件，那么测试左移一定会遇到各种阻碍，从而事倍功半。
如果要高效的实施测试左移，团队一般需要具备以下几条前提条件：
- 整个产品研发团队的测试部门和研发部门没有部门墙，测试人员、开发人员和业务人员能直接协作进行工作
- 如果是测试人员来实施测试左移，则需要测试人员具备业务分析能力和软件研发能力，包括能做一定的业务分析，能看懂业务架构和技术架构，甚至能分析代码逻辑等
- 整个团队认同软件功能完成开发工作之前尽可能预防缺陷，而不是追求在开发完成工作之后去发现缺陷
- 整个团队抵制任何形式的返工（Rework），追求尽可能一次性完成正确的工作
总结
随着软件研发效能被重视的程度越来越高、越来越广，测试左移一定会成为提升研发效能的重要方法和实践，也是对测试人员的一次洗礼和机遇。测试工作永远不死，但是如果不持续学习，也不会拥抱变化的测试人员们，也许在不久的将来就会被淘汰。