测试左移，如何移？

Google曾经公布过一组数据，Bug在不同阶段被发现后修复的成本。从需求、编码、测试、上线，每晚发现一个阶段，修复Bug的成本都要乘以5。那么结论就很明显了：要降低成本，就需要尽早发现并解决Bug。由于开发的流程一般表现为从左到右的一个时序，那么测试工作就要往前移，也就是左移。

其实测试左移并不是什么新鲜的实践，只是一个新词而已。具体在极限编程的语境里，有多个实践都是和测试左移相关的。做好极限编程实践，测试自然就左移了。不要听个名词就自己脑补，然后脑补出一个奇葩的测试左移。

实践1：测试驱动开发（TDD）。TDD要求我们在编写代码之前，先编写测试代码。这就将开发阶段的测试，移到了不能再左的程度。极限编程之所以称为极限，是基于这样一个原则：如果一个实践是好的，那么我们就做到极限。既然测试左移是好的，那么我们就移到头。移到头就是编码前先写测试代码。

实践2：验收条件。那么开发前我们能做什么呢？就是这给出需求（用户故事）的时候，编写详细的验收条件。这样需求这进入开发阶段前，产品、测试、开发，就这个用户故事要做到什么程度，就达成了一致。开发按验收条件开发，当所有验收条件都过了，开发就完成了；测试和产品按验收条件验收，不会多出额外都奇思妙想。这样开发、测试、产品，在这个功能如何做这个问题上，就没有根本性都矛盾，不需要再去争论这是个Bug，还是需要个新Feature这个问题。

实践3：持续集成。在团队工作的时候，成员不断提交代码到版本库，每次合并新代码，都需要进行回归测试。在自动化测试都保证下，持续集成可以做到非常频繁，甚至一天数次地集成。在提交可测试验收前，确保程序运行正常。

所以如何做好测试左移，提高生产效率，答案就是极限编程。做好极限编程，测试自然左移。