一個產品的質量是這個產品的靈魂。
不能在最后才開始做測試
很多時候人們理所應當覺得測試應該在項目的最后階段進行，但是這樣的策略存在以下缺點：
- 很難改進現有產品質量
- 在測試之前一直有錯誤，但是未被發現
- 項目的狀態難以測量，一次性發現的大量錯誤難以估計修復時間
- 錯失反饋時機
- 因為后期的項目壓力，測試可能會被削減
所以我們需要利用Scrum將測試融入在整個項目的行進過程當中。這樣進行的項目有如下特點：
- 程序員和測試人員之間每天都會打交道，不存在“交接”的說法，這樣一起工作的團隊更有協作能力，同時大家可以一同討論項目的趨勢。
- 在Sprint的第一天和最后一天有著同樣多的測試活動。
自動化測試
這里要提到一個自動化測試的金字塔模型，從下到上分別是：單元測試，服務測試，UI測試。分別對應我們項目當中的UT，IT以及NightWatch測試。
單元測試
單元測試是整個自動化測試的一大基石，非常重要。它不但能夠保證最小粒度上代碼的正確性，而且效率非常高。我們的經驗是，一個產品的初期可能會花費相對大量的時間寫UT代碼，并且效果并不是很明顯。但是隨著產品的增強，項目的進行，初期所寫的單元測試將會發揮巨大的作用。
服務測試
即對應我們項目當中的IT測試，是針對整個服務進行的測試，程序員編寫測試代碼直接對于服務的功能進行測試。這樣做的測試能夠直接驗證服務的正確性，并且成本較低。
UI測試
書中提到UI測試應當適當少的進行（不是盡量少）。因為UI測試相對于服務測試具有以下缺點：
- 脆弱，因為功能的小改動可能給UI測試代碼帶來巨大改動。
- 成本高，相對于服務測試，UI測試代碼確實需要更多的時間去寫。
- 耗時，運行一次UI測試往往需要更多的時間。
從我們項目的經驗來看，UI測試確實存在以上的問題。但是在大家做總結的時候發現UI測試其實是必不可少的，因為書中的觀點只是試圖通過UI測試發現服務端有哪些Bug。但是我認為UI測試另外一個非常重要的功能（可能是最重要的功能）就是保證UI的功能的正確性。實踐中我們覺得UI測試確實起到了這樣的作用。
手工測試
自動化測試并不能覆蓋所有的測試點，而且有些時候自動化測試比手工測試成本更高。手工測試應主要作為探索性測試。另外在一個Sprint當中，開發出來的新功能應進行手工測試。
技術債務
技術債務指的是在開發過程中，如果出現了不良的設計或實現，則是“欠債”。后面需要一些時間精力來修復，即“還債”。
并不是所有的技術債務都是不好的。比如說在項目快要交付的時候，有時候為了修改一個問題可能會引入稍欠考慮的實現，但是這樣的技術債務是利大于弊的。但是對于所有的債務，應當盡快的解決。“只要快速的歸還，小的債務可以加速開發”。
