プログラムのコード化が終わると、嬉しくてすぐにもコンピュータ上で動かしたくなります。どうしてもやりたければやってみてはどうでしょう。（以下では数キロステップのプログラムを想定しています）

コンパイラ方式の言語を使っている場合、コンパイル時にエラー検出しますが、思いのほかエラーが多いことにガッカリします。

試しに動かしてみると、大抵の場合、数十ステップくらい走ったところで不具合に遭遇します。ここでまたガッカリします。

人間はミスを犯しやすいもので、注意して書き上げた積りでもこの位のミスが入り込みます。

こんな状況でバグ（bug、誤りのこと）を取り続けたら、沈んだ気持ちで延々と作業を続けることになります。

そこで、私たちはプログラムに対するレビュー（review、見直すこと）の必要性を理解します。

レビューは、機能設計、構造設計、コード化の各段階が終了する度に成果物（機能設計書、構造設計書、プログラムコード）に対して行う必要があります。レビューを効果的に行うために、レビューポイントを決めてそれに集中するように努めます。

レビューがしっかり行われた後で、再び動かしてみると、以前に比べて格段にスムースにプログラムが走ることが実感できるはずです。（レビュー・ファースト参照）。

テストではすべての機能が正しく動作することを確認しますが、最初から利用者が使うレベルでテストするのはなく、プログラム・コードのどこをテストするのかというレベルで行ないます。これは単体テストと呼ばれています。次に、複数のモジュールの間で上手く動作しているかを確認します。これを結合テストと呼んでいます。そして、最後にプログラム全体が連携して動作しているかをテストします。これを統合テストと呼んでいます。

単体テスト、結合テスト、統合テストのそれぞれで用いるテストデータを作成します。テストデータは一覧にして、それぞれが何をテストするのかを明らかにしておきます。これらの計画をテスト計画書と呼びます。テストが進捗する度に、計画書には実績を記入し、今どの程度テストが進んでいるかが分かるようにします。

テストでエラーが発見されたら、当然エラーを修正しますが、この作業のことをデバッグ（debug）と呼んでいます。

レビュー｜テスト｜デバッグ作業がすべて完了して、ようやく利用者による評価を受ける段階になります。