本文序
上篇提到了測試價值的部分，瞭解了導入測試能夠帶來什麼樣的價值。然而，若我們想發揮測試的最大效用，我們需要試著在合適的時機來加入測試。
本文接下來會分成兩種探討的方向來說明我心目中加入測試的時機：
- 專案性質
- 產品階段
依據專案性質選擇加入測試
「為什麼平常開發時都很順利，感覺不需要加入測試啊？」會發生這種情況，很有可能就是因為該專案的性質，加入測試的效益不高，所以才會發生這件事情。
但是每家公司的產業別不同，關注的焦點也就不同；甚至，同公司中不同專案之間重視的程度也會有所差別，因此我以幾個指標來供大家自行權衡哪些專案加入測試對是有益處的：
生命週期：一個產品從創建後到維護，最後消亡的時間。
專案稍縱即逝：
有時候我們可能會承接到來至行銷部門的廣告宣傳頁。而對於廣告宣傳的走期來說很有可能只有短短的兩週不到，這種專案加入測試後可能還沒有機會被測試守護到，線上的頁面就要銷毀了。
專案會長達一段時間：
假若處理的專案是屬於平台類型的網站或產品，撇除掉一開始開發的期間，往往上線後可能就進入長達數年的維運期，這類型的專案由於在產品生命週期中的維運期較長，非常有可能會遇到經手維護人員的更換、既有功能的調整甚至於共用元件邏輯異動等情境，此時除了仰賴規格書來傳承專案中的領域知識之外，就可以藉由測試來防禦意外發生的錯誤。
維護頻率：專案初步開發完成後，後續維護的頻率。
近乎不需維護：
有些專案放上線後⋯⋯對，沒有然後了，這種專案甚至不在公司的戰略目標上，只因為「某些特殊理由」需要存在，比起測試我更懷疑將來打開後會啟動不了專案的可能性還高一些，因此補足必須的專案文件（如 Readme.md 該如何啟動專案）都比測試更為需要。
維護頻率適量：
假若一個專案上線後，每個月都仍有改善服務功能等等需求，那麼加入測試就可以鞏固既有的部分不會被牽連到。
專案規模：產品在規劃需求階段後，所評估出來的專案規模大小。
小如芝麻：
一頁式的活動頁等等，如果內容都純屬文案與圖片，比起測試我可能會請相關業務單位仔細審查其文案是否正確、該有的連結有無放錯等素材確認，畢竟寫了測試去對照連結是否錯誤，結果一開始給的就是錯的，以解決問題的觀點來看，此時測試的效益就會低。
功能多到需要安排多人協作：
有些專案非一己之利能夠完成時，或是遇到需要團隊配合的情況，這時候品質佳的測試能夠防止雙方無意中更改彼此共用的邏輯。
需求穩定度：需求衝突時的間隔時間。
方案上午剛確認，下午又變更：
偶爾公司應戰略目標考量，在看不到終點雛形的狀態下就要開始開發了，且戰且走的情況下，就會容易因各種原因導致需求不斷變更，更甚者推翻之前的規則，此時加入測試就得衡量其他要素看看是否真的需要，否則很容易遇到測試程式碼不斷被拋棄的狀況。
資源分配：進行開發前的前置期需求規劃是否足夠、開發人員配置與時間是否充沛。
資源嚴重不足：
因應需要得在有限的情況快速開發，光是開發產品程式碼本身就快來不及的情況下，必要時先捨棄撰寫測試程式碼是一種考量，但如果後續想加入測試就會遇到重重困難。
有喘息的空間：
開發期給予的時間合適，若有需要就可以考慮加入測試。而熟練測試後，導入測試所增加的開發時間就可以降低不少。
產品階段
把專案以產品的規格來看待的話我們能加入測試的環節主要是落在初期開發與上線後的維運階段：
專案本身剛進入開發階段
若是產品剛進入開發階段的話，此時要加入測試是非常容易的，甚至透過像是前一篇文章的所採用的測試驅動開發（TDD, Test-Driven Development）的開發模式能從測試中得到更多回饋。
然而這階段可能比較容易遇到的就是需求不穩定的情況，即便在需求規劃期開發者可能與整理需求的人員已有過會議討論可行性，但難免還是會有部分需求要在實際執行時才會發現需要變更作法，因此測試程式碼需隨著產品程式碼不斷調整是可預期的狀況。
專案本身已進入維運階段
若產品本身已經開發了一段時間，此時很多功能都是沒有受到測試保護的，根據 《Kent Beck 的測試驅動開發》一書中， Kent Beck 對於這種情況則是表示我們不應該為所有產品程式碼都補上測試，對於沒有需求更動的地方我們應該保留原始的狀態。
因此，我們能做到的應該是對將來需求更動所影響到的地方開始慢慢加入測試，或是依靠其他可信賴的方式，比方透過團隊成員 code review 等等方式逐步前進。
以上便是目前我衡量何時該加入測試的基準，也歡迎大家留言提供自己是如何決策何時該加入測試的方式。
而在確認測試的價值也已經做出決策要在哪些專案加入測試之後，明天我們將開始關注在思考如何撰寫測試的流程，並從測試類型與對應的測試工具開始分析。
作者悄悄話：其實測試寫熟了之後大部分比較像是你願不願意寫