Revised: Apr./24th/2004
まとめると次のようになります。他にも、PM、サポート部門など異なる観点から取り 組む項目があると思います。
バグにはシンタックスエラーとロジックエラーの二通りがあって、Javaの場合は、コンパイル時エラーと実行時例外とロジックエラーに分けられます。
言語仕様／API の不適切な記述によるエラーです。
シンタックスエラーの場合は、とにかく何らかのエラーメッセージ、例外情報が得られるので、それにしたがって、変数の値を逐一追跡すればデバッグできるでしょう。
EclipseなどのIDEのデバッグツールか、System.out.println() でコンソールに吐き出すのが一般的だと思います。SDK 1.4ならアサーションを使います。一般に、オブジェクト指向言語は、複数のオブジェクト間を行き来するので、単純なプロシージャ型に比べて、ロジックを追いにくく、デバッグが困難だと思います。
何れにせよ、それほど時間をかけずにデバッグできるはずです。
動作／データが期待通りでないというバグです。例えば、スレッド間の同期化が不味くてデータ破壊が起こる、意図したアクセス権が侵害されるなどです。
ロジックエラーの不味い点は、手遅れになってから発覚することが多く、修正範囲が広範囲にわたったり、原因の特定が困難であったりして、長期化する懸念があることです。
影響度／修正難度の点でシンタックスエラーを大幅に引き離します。関係各位のうんざり感もぶっちぎりです。そのときだけは本気モードになるから面白いという方もいらっしゃいますが :-)
ロジックエラー回避の方策は、開発実施に至る前、プロジェクトの早い段階、設計段階で品質を作り込むことだと云われています。各フェーズごとに、バグを作りこまない、後工程にバグを持ち越さない開発プロセス（設計とテスト計画とドキュメンテーション）が大事です。
次のどこで発生するかによって重要度が変わり、後ろへ行くほど修正困難でマンパワーが掛かり被害が大きくなります。
コードレベルのデバッグ作業に至る前に、プロジェクトの早い段階から品質を作り込むのが基本です。
それでも発生するのがバグで、ST (System Test) フェーズ、運用フェーズで発生すると障害と呼ばれます。障害解析の第一段階は問題判別 (PD: Problem Determination) であり、アプリ（適用業務）とプロダクト（製品）の何れが悪いのか、それが仕様なのかを切り分ける必要があります。
そのためには、各種ログやスレッドダンプなどの資料の種類と採取方法、ロジックとの付け合せ方を知っている必要があります。PD機能は、各製品ごとに独自に実装しています。製品バグであっても、修正困難、あるいはサポートが切れている古い環境であったり、そもそも延長契約してなかったりする場合は、アプリ側で回避する必要があります。いかなるバグであっても、影響度の判定と、根本的な本格対応に至るまでの一時対応の策定が必要になります。
関係ないのですが、最後に、私が知っている冗談で、こういうのがあります。
「ソフトウェアの三大要素は、データとロジックと、それにバグ」