技术债，这个概念源于Ward Cunningham，他最早提到代码“不成熟”或“不太正确”所导致的成本增加（1992）。这个术语现在通常指的是：做一个设计很差，代码写得很差，包括未完成代码或者任何其他缺陷的系统所涉及的成本。Cunningham提醒我们积累技术债务带来的后果。
不偿还技术债务时，会引发危机。花在“不太正确”代码上的每一分钟被算作该技术债务的利息。在一直存在技术债务的压力下，整个工程组织会变得停滞不前。（1992）
Cunningham提出技术债已经过去26年了，回头来看看如今IT研发的团队中最常见的技术债务：严重缺乏自动化测试。不管这个团队是打算实施Scrum，Lean Development或者DevOps。
债务，最终都要归还，请牢记Cunningham的观点：“只要快速地归还，小的债务可以加速开发”。
让一个团队能够保持敏捷继续前行，并不意味着他们必须把所有的债务都还掉后才能开始，这可能意味着整个团队都要花费大半年的时间来不做任何新功能，这对哪一个老板来说都不是一个好消息。
我们需要考虑的是，怎样在可承受的情况下尽量多偿还技术债务。一般来说，团队可以考虑从以下三个步骤来入手：
- 止血
- 维持现状
- 还债
“止血”的方式有多种多样，不过在第一步的止血之前首先要甄别出系统的出血点，也就是团队的测试活动中最耗费人力和时间的地方。
Brian Marick（测试权威专家和敏捷宣言的起草人之一）有一个“挂在低处的水果”的有趣理论。他说：真正挂在低处的水果往往不是自动化测试执行过程，而是自动化其他的测试任务，比如填充数据库或者自动导航到开始手工测试的页面。手工测试的数量没有减少，但是减少了用来执行它们的总时间。
等团队已经找到了足够的“挂在低处的水果”，用来抵消掉需要花在新增手工测试上的时间，再出发到第二步：维持现状。
在这个阶段里对于每一个迭代里新增的功能都会尝试去开发自动化测试。这时没有更多的债务累积下来的情况下，状态不会过于恶化。当团队的人员的技能已经达到一定的熟练程度，项目时间足够允许的情况下，我们才可以继续的Move On。
当达到最终“还债”阶段时，同大多数的系统开发类似，自动化测试可能也会面临考虑重构的情况。比如之前是用行业主流的ATDD框架RoboertFramework来进行的ATDD，随着时间的推移和对之前的系统的考虑，也许就能允许团队采用自研发框架的程度。
质量，是需要团队共同努力的过程，不断学习，不断获取新的测试技能用以偿还技术债，持续改进，是任何一个想获取成功的团队的基石。当下一次kick off 会议开始的时候，问问自己，这次我们有什么债是需要还的呢？
