一个产品的质量是这个产品的灵魂。
不能在最后才开始做测试
很多时候人们理所应当觉得测试应该在项目的最后阶段进行，但是这样的策略存在以下缺点：
- 很难改进现有产品质量
- 在测试之前一直有错误，但是未被发现
- 项目的状态难以测量，一次性发现的大量错误难以估计修复时间
- 错失反馈时机
- 因为后期的项目压力，测试可能会被削减
所以我们需要利用Scrum将测试融入在整个项目的行进过程当中。这样进行的项目有如下特点：
- 程序员和测试人员之间每天都会打交道，不存在“交接”的说法，这样一起工作的团队更有协作能力，同时大家可以一同讨论项目的趋势。
- 在Sprint的第一天和最后一天有着同样多的测试活动。
自动化测试
这里要提到一个自动化测试的金字塔模型，从下到上分别是：单元测试，服务测试，UI测试。分别对应我们项目当中的UT，IT以及NightWatch测试。
单元测试
单元测试是整个自动化测试的一大基石，非常重要。它不但能够保证最小粒度上代码的正确性，而且效率非常高。我们的经验是，一个产品的初期可能会花费相对大量的时间写UT代码，并且效果并不是很明显。但是随着产品的增强，项目的进行，初期所写的单元测试将会发挥巨大的作用。
服务测试
即对应我们项目当中的IT测试，是针对整个服务进行的测试，程序员编写测试代码直接对于服务的功能进行测试。这样做的测试能够直接验证服务的正确性，并且成本较低。
UI测试
书中提到UI测试应当适当少的进行（不是尽量少）。因为UI测试相对于服务测试具有以下缺点：
- 脆弱，因为功能的小改动可能给UI测试代码带来巨大改动。
- 成本高，相对于服务测试，UI测试代码确实需要更多的时间去写。
- 耗时，运行一次UI测试往往需要更多的时间。
从我们项目的经验来看，UI测试确实存在以上的问题。但是在大家做总结的时候发现UI测试其实是必不可少的，因为书中的观点只是试图通过UI测试发现服务端有哪些Bug。但是我认为UI测试另外一个非常重要的功能（可能是最重要的功能）就是保证UI的功能的正确性。实践中我们觉得UI测试确实起到了这样的作用。
手工测试
自动化测试并不能覆盖所有的测试点，而且有些时候自动化测试比手工测试成本更高。手工测试应主要作为探索性测试。另外在一个Sprint当中，开发出来的新功能应进行手工测试。
技术债务
技术债务指的是在开发过程中，如果出现了不良的设计或实现，则是“欠债”。后面需要一些时间精力来修复，即“还债”。
并不是所有的技术债务都是不好的。比如说在项目快要交付的时候，有时候为了修改一个问题可能会引入稍欠考虑的实现，但是这样的技术债务是利大于弊的。但是对于所有的债务，应当尽快的解决。“只要快速的归还，小的债务可以加速开发”。
