軟件開發人員通常不會考慮的一種測試形式-人工測試。
大多數人都以為，因為程序是為了供機器執行而編寫的，那么也該由機器來對程序進行測試。這種想法是有問題的。人工測試方法在暴露錯誤方面是很有成效的。實際上，大多數的軟件項目都應使用到一下的人工測試方法：
1. 利用錯誤列表進行代碼檢查
2. 小組代碼走查
3. 桌面檢查
4. 同行評審
代碼檢查：
所謂代碼檢查是以組為單位閱讀代碼，它是一系列規程和錯誤檢查技術的集合。
一個代碼檢查小組通常由四人組成：
- 協調人：以為稱職的程序員
- 該程序的編碼人員
- 該程序的設計人員
- 測試專家
用於代碼檢查的錯誤列表：
- 數據引用錯誤
- 是否有引用的變量未賦值或未初始化
- 下標的值是否在范圍之內
- 是否存在非整數下標
- 是否存在虛調用
- 當使用別名時屬性是否正確
- 記錄和結構的屬性是否匹配
- 是否計算位串的地址，是否傳遞位串參數
- 基礎的存儲屬性是否正確
- 跨過程的結構定義是否匹配
- 索引或下標操作是否有“僅差一個”的錯誤
- 繼承需求是否得到滿足
- 數據聲明錯誤
- 是否所有的變量都已聲明
- 默認的屬性是否被正確理解？
- 數組和字符串的初始化是否正確？
- 變量是否賦予了正確的長度，類型和存儲類
- 初始化是否與存儲類相一致？
- 是否有相似的變量名？
- 運算錯誤
- 是否存在非算術變量間的運算？
- 是否存在混合摸式的運算？
- 是否存在不同字長變量問的運算？
- 目標變量的大小是否小於賦值大小？
- 中間結果是否上溢或下溢？
- 是否存住被0除？
- 是否存在二進制的不精確度？
- 變量的值是否超過了有意義的范圍？
- 操作符的優先順序是否被正確理解？
- 整數除法是否正確？
- 比較錯誤
- 是否存在不同類型變量間的比較？
- 是否存在混合模式的比較運算？
- 比較運算符是否正確？
- 布爾表達式是否正確？
- 比較運算是是否與布爾表達式相混合？
- 是否存在二進制小數的比較？
- 操作符的優先順序是否被正確理解？
- 編譯器對布爾表達武的計算方式是否被正確理解？
- 控制流程錯誤
- 是否超出了多條分支路徑？
- 是否每個循環都終止了？
- 是否每個程序都終止了？
- 是否存在由於入口條件不滿足而跳過循環體？
- 肯能的循環越界是否正確？
- 是否存在“僅差一個”的迭代錯誤？
- DO/END語句是否匹配？
- 是否存在不能窮盡的判斷？
- 輸出信息中是否有文字或語法錯誤？
- 接口錯誤
- 形參的數量是否等於實參的數量？
- 形參的量綱是否與實參的量綱相匹配？
- 傳遞給被調用模塊的實參個數是否等於其形參個數？
- 傳遞給被調用模塊的實參屬性是否與其形參屬性匹配？
- 傳遞給被調用模塊的實參量綱是否與其形參量綱匹配？
- 調用內部函數的實參的數量、屬性，順序是否正確？
- 是否引用了與當前入口點無關的形參？
- 是否改變了某個原本僅為輸入值的形參？
- 全局變量的定義在模塊間是否一致？
- 常數是否以實參形式傳遞過？
- 輸入/輸出錯誤
- 文件的屬性是否正確？
- OPEN語句是否正確？
- I/O語句是否符合格式規范
- 緩沖大小與記錄大小是否匹配？
- 文件在使用前是否打開？
- 文件在使用后是否關閉？
- 文件結束條件是否被正確處理？
- 是否處理了I/O錯誤？
- 其他檢查
- 在交叉引用列表中是否存在未引用過的變量？
- 屬性列表是否與預期的相一致？
- 是否存在“警告”或“提示”信息？
- 是否對輸入的合法性進行了檢查？
- 是否遺漏了某個功能？
代碼走查：
代碼走查不同於僅閱讀程序或使用錯誤檢查列表，代碼走查的參與者“使用了計算機”。被指定為測試人員的那個人會帶着一些書面的測試用例來參加會議。在會議期間，每個測試用例都在人們腦中進行推演，也就是說，把測試數據沿程序的邏輯結構走一遍。程序的狀態（如變量的值）記錄在紙張或白板上以供監視。
這些測試用例必須結構簡單，數量較少。因為人腦執行程序的速度比計算機執行程序的速度慢上若干量級。因此，這些測試用例本身並不起到關鍵的作用。它們的作用是提供了啟動代碼走查和質疑程序員邏輯思路及其設想的手段。在大多數的代碼走查中，很多問題是在向程序員提問的過程中發現的，而不是由測試用例本身直接發現的。
桌面檢查：
可以視為由單人進行的代碼檢查或代碼走查。
同行評分：
同行評分是一種依據程序整體質量，可維護性、可擴展性、易用性和清晰性對匿名程序進行評價的技術。
- 程序是否易於理解
- 高層次的設計是否可見且合理
- 低層次的設計是否可見且合理
- 修改此程序對評審者而言是否容易
- 評審者是否會以編寫出該程序而驕傲