デバッグ
バグの存在は予知できることも結果的に判明することもある。
経験を積んだプログラマはどこでエラーが起きやすいかをよく知っている。それはプログラムの部分ごとの複雑性やデータ破壊の危険性などから判断できる。例えば、ユーザが入力したデータは疑って扱うべきである。注意深く、データの形式および内容が正しいものであると検証すべきである。通信によって得たデータならば、メッセージ(データ)の全体を受信したか確かめねばならない。複雑なデータをパースまたは加工する際には、値の予期しない組み合わせを含んでいて正しく扱えないことがある。エラーの兆候らしき箇所にチェックを挿むことで、データがいつ破壊された、または正しく処理されなかったかを検出することができる。
もしエラーがプログラムを異常終了させるほど深刻なものだったなら、バグの存在は明らかである。プログラムがそこまで深刻ではない問題を検出した場合、エラーとなるかログメッセージが表示されるかすると、バグの存在を認識できる。しかしエラーが軽微で間違った結果を出すだけであったら、バグの存在を検出するのははるかに難しくなる。これはプログラムの結果を検証するのが困難であるか不可能である場合に特に成り立つ。
このステップの目的はバグのしるしを特定することである。問題のしるし、どのような条件の下で問題が起き、(可能なら)どのような回避策があったか、を観測することは後のステップで問題点をデバッグする大きな助けとなる。
「デバッグ」という語を初めて使った人物については論争がある(バグを参照)。1976年に Glenford J. Myers の Software Reliability: Principles and Practices で"debugging"が「既知のエラーの原因を突き止め、そのエラーを修正すること」と定義されて使われたのが初めてだとする者がいる一方、1940年代にグレース・ホッパーによるとする者もいる。
その逸話は以下のようなものである。ホッパーがある初期のコンピュータに携わっていたとき、蛾がリレーの中に入って動作不良を起こすのを見た。ここから、プログラムからエラーを取り除く作業を指してデバッグという語が使われ始めたと信じている者もいる。ホッパーによればバグという語はそれ以前にも使われており、実際にその場面に遭遇したのがおもしろかったという。