プログラムのミス。
プログラムを実行した時に「期待通りに動作しない」こと、もしくはその動作を「バグ」という。
「100が出力されるはずなのに200が出力される、これはバグだな」といった使い方をする。
　
コンパイルエラーはバグとは言わない。バグは、実行中に発生するものを指す。
ただし、コンパイルエラーを無理矢理解決することで、バグが発生する場合もあるため、プログラムの正しい書き方を学ぶことで、バグを減らすことができる。
　
バグは「期待通りに動作しないこと」を指す。「期待される動作」とは、業務用アプリケーションであれば、設計書や仕様書に記述された動作内容を指す。
そのため、ごくごく普通に動いていても、それが「期待される動作」と異なる場合には、それはバグである。たとえば、出力位置が要望と1ピクセルずれていても、それはバグである。
逆に言えば、それが期待される動作であれば、どのような動作でもそれはバグではない。いきなりプログラムが強制終了しハードディスク内のファイルを全て削除しようとも、「この操作を行った場合には結果は保証しない」と書かれていれば、それはバグではないのである。
そのため、バグはしばしば「仕様です」の一言で片付けられる。
　
バグを発見する作業を「テスト」という。
プログラムを実行し、様々な方法で操作を行うことで、プログラムを「テスト」し、バグを見つけ出す。
その際、プログラムを作った人間がテストをすると、無意識に「誤動作しやすい操作」を避ける傾向にあるため、全く関係ない人間がテストを行う必要がある。
　
バグを取り除く作業を「デバッグ」という。
デバッグでは、プログラムの実行を止め、変数の中身やスタックトレースを見ることができ、それによりバグの原因を特定する。
デバッグでは、プログラムでは見えない「変数の中身」を見ることができるため、プログラムを睨み付けるよりはデバッグしてしまう方が原因が特定しやすいこともある。
ただし、そのデバッグした箇所がそもそもの原因とは異なっている場合には、バグの修正が無駄に終わったり、他のバグを見逃す原因となる場合もあるため、注意が必要である。
　
バグは、必ず発生するものである。
プログラムは量が増えれば必ずバグも増える。バグは基本的には確率的に発生するものであり、どんなに優秀なプログラマーでも発生は避けられない。
単なるタイプミス、眠気や忙しさによるもの、意思疎通の少なさ、工数の短さ等、バグを誘発する原因は非常に多く、ほんの少しでも気を許せばバグは紛れ込む。
また、プログラムの量が増えればそれに比例してバグも増える。そのため、大規模なプログラムであれば必ずバグは発生する。
　
ところが、バグは「絶対悪」であり、存在してはならない、とされる場合もあり、その場合「バグは存在し得ない」もとなる。これは、プログラマーとしての無用なプライドや、根拠のない過信、もしくは性善説によってもたらされる。
さらに、バグがないプログラムがもし存在すれば、それは工数が短く、価格を低くできる。バグを発見するためのテストを行う工数を削減し、さらにその時に発見されたバグを取り除く工数も削減でき、全体的な工数が減らせるため、納期を短くでき、それにより人件費が下げられるため、値下げを行うことができる。これは主に営業によってもたらされ、現場に押し付けられる。
だが、バグは必ず存在し、テスト及びデバッグの工数は必要不可欠である。これらを抜きにしたプロジェクトは必ず失敗する。もし成功したらそれは奇跡であり、「マッチ棒でビルを造ってみたらできちゃった」レベルの恐怖を憶える必要がある。
　
バグが存在していいのはプログラムの作成途中のみである。
完成品のバグは極力減らさなければならない。「プログラムにはバグがつきもの」とはいえ、ユーザーにバグを押し付ける事があってはならない。完成品にバグが存在した場合、企業のイメージダウンに継ながったり、損害賠償請求をされる可能性がある。
　
バグを減らすコツは非常に多いが、ノウハウ化されてはいない。
これは、「バグは存在し得ない」という思想がまかり通ってしまっていることや、バグのノウハウ化そのものに多くのコストが必要となるためである。
バグはどこにでも存在し、それを認めた上で、全体として減らすようにしなければ、社会に存在するあまたのシステムはバグだらけになるだろう。しかしそれには、一人一人の意識改革が必要であり、また企業体質を変える必要もあるため、当分の間は困難を極めるであろう。
　
ちなみに、世界最初のバグは、その名の通り「虫」によるものである。
初期のコンピューターに虫が入り込んで誤作動したことが原因であり、ここから「バグ」という名前が付けられた。
また、「プログラムの中に入り込んで悪さをする」という点では、虫に近いものと言える。ただし、この場合「自分は悪くない」といった、第三者的な逃避に基づく考え方とも言える。

// Sample.java
public class Sample
{
    public static void main( String[] args )
    {
        // バグの例。
        int[] ints = new int[]{ 100, 200, 300 };
        //                    ↓これがバグの原因。「<=」ではなく「<」が正解。
        for( int iF1 = 0; iF1 <= ints.length; ++iF1 )
        {
            System.out.println( ints[iF1] );
        }

        // 100
        // 200
        // 300
        // java.lang.ArrayIndexOutOfBoundsException: 3
        //     at Sample.main(Sample.java:10)
        // Exception in thread "main" 

        // このようなバグは、「forループでは必ず<にする」
        // といったルールを決めることで回避できますが、それでも
        // ただ打ち間違えたり、ホームページにあるものを
        // コピー＆ペーストして修正し忘れたり、といったことが
        // 原因で起きてしまうこともあります。そういったミスは
        // 誰もがいつでも起こしかねないでしょう。

        // ちなみに、このプログラムは、普通に実行したら、例外で
        // 終了するだけですし、出力もちゃんとなされるので、
        // バグではない、とも言えます。プログラムとしては
        // 褒められないものですが、「仕様通り動けばいい」のも
        // 事実です。
    }
}