軟體測試的方法中，有一種是叫作 Code Inspection，測試的流程就是請工程師根據 Checklist 和人工 Walkthrough 程式邏輯去找出程式碼中的錯誤。按照 Wikipedia 的定義，流程可以分為：
- Planning: Moderator 負責計畫 Inspection 的內容和時程。目的是 Initiate 和 Follow 一次完整的 Inspection。
- Overview meeting: Author 簡介自己的程式碼。目的是先幫助 Inspector 可以更快進入狀況。
- Preparation: 每個 Inspector 在舉行 Inspection Meeting 之前先要閱讀程式碼並且標記所有找到的錯誤。目的是先將所有的錯誤找出來。目的是要 Identify 出所有的 Defect。
- Inspection meeting: 舉行 Meeting 時，Reader 負責 Walkthrough 程式碼，Inspector 此時就將找到的錯誤提出來，然後討論是否為 Defect。目的是要 Confirm 和 Prioritize Defect 然後產生 Action Items，並且決定誰來審查 Author 接下來的 Rework，同時也會討論此次 Inspection 的離場標準。
- Rework: Author 根據最終的 Action Items 去修訂程式碼。
- Follow-up: Reviewer 根據 Action Items 重新審查所有的修訂。
角色可分為：
- Author: 撰寫程式碼的作者。
- Moderator: 計畫並協調審查流程的主持人。
- Reader: 負責在 Inspection Meeting 上帶著大家閱覽程式碼的人。
- Recorder: 負責在 Inspection Meeting 上當會議紀錄。
- Inspector: 負責在 Preparation 階段詳細審查程式碼，並且在 Inspection Meeting 中指出錯誤的人。
很幸運的，最近有機會親身體驗 Code Inspection，感受比較多的好處大概就是：
- 就像是閱讀小說可以增進寫作的能力一樣；閱讀別人的程式碼，也可以幫助提升自己寫程式的能力(或者是作為警惕)。
- 平常大家都在自己手上的模組工作，設計藍圖也可能已經過時。經過 Inspection，所有成員對於整體的流程會有更實務的了解。
- 可以建立團隊的 Coding Standard。通常 Defect 的發生，很少是獨立的事件，多會有一定的模式。例如說，參數的 Nullity Check，或者是 Buffer Overrun ，然而這些問題都只要遵守簡單的規則就可以避免。若是可以把這些解決方式回饋到團隊的 Coding Standard，在撰寫程式碼都要遵守這些規則，減少愚蠢的錯誤發生。在下次的 Inspection 時，把 Coding Standard 當作 Checklist 就可以更快也更容易認出看起來有問題的程式碼。
當然 Code Inspection 不是軟體測試的萬靈丹，在審查某些程式碼的時候，若是 Inspector 對於程式碼沒有足夠的深入的了解，大概只能做到片面的審查。例如：
- 多執行緒的程式碼：用其他的 Modeling Tool (UML?) 來表達多執行緒的運作，會更容易檢驗。如果程式語言本身是 Multi-thread Friendly，也許可以直接讀程式碼。
- 用他人不熟析的程式語言或 Domain Knowledge 所撰寫的程式碼：這個可能需要在 Overview Meeting 之前需要另外的 Meeting 先幫大家做教育訓練。絕不可以因此就放棄 Inspection，這是絕佳的提升團隊能力的好時機。
- 沒有明確 Testibility 的程式碼：通常發生在設計階段就沒有良好定義的模組，不知道可以丟什麼東西進去，也不知道要輸出什麼樣的東西。這種情況通常需要的是更 High-Level 的 Inspection，Code Inspection 不能解決什麼。
以上就是一些感想，就先分享到這邊啦。
參考資料：
Wikipedia: Software Inspection
