デバッグ：バグの発見
テスト
特定の目的に特化したプログラムならば普通に実行してみるとバグが見つかって修正を強いられるのですが、それが汎用的になればなるほど検証すべきパターンは膨大になり、手当たり次第ではとても追いつかなくなります。
その為、大規模なソフトウェア開発に於いては系統的なテスト（test）によりバグを発見する必要があります。
機能による分割
モジュール化されたプログラムのテストは、各個のモジュールの機能のテスト（単体テスト）と複数のモジュールの協調動作のテスト（結合テスト）に分けて行う事ができます。
ブラックボックステスト
ソフトウェアの仕様に着目する場合、例えば「購入金額 3000 円以上で送料無料」な通販サイトのシステムならば
- 3000 円未満の注文
- 3000 円以上の注文
の二つを試せば少なくとも送料が切り替わっているかを検証できます（同値分割法）。また丁度 2999 円と 3000 円の注文を試せば、他でもない 3000 円を境として判定しているかを検証できます（境界値分析）。
ホワイトボックステスト
「あらゆるパターンの網羅」をコードの面から考えると、
- コードの行（命令）の何割が実行されたか
- 条件分岐のパターンをどれだけ試したか
といった点がテストの質を左右すると言えるでしょう。
静的解析
プログラム自体を実行しなくても、コードの解析によって
- コーディング規約の統一性
- アンチパターン
- 未初期化領域へのアクセス
- メモリリーク
- 脆弱なライブラリ関数の使用
などを調査し怪しい部分を見つけだす事ができます。
参考
- ソフトウェアテスト基本テクニック（gihyo.jp）
- ネット上のこういう整理された解説は割と貴重な気がします。