テストとレビュー

ねらい

作ったものを確かめる方法を学びます。このレッスンを終えると、テストを小さい単位から順に行う理由と、どの設計に対してどのテストが対応するのかを説明できるようになります。

誤りは、早く見つけるほど安く直せます

同じ誤りでも、見つかる時期が遅いほど直す費用は大きくなります。要件定義の段階で気づけば文書を直すだけですが、動き始めてから気づけば、設計もプログラムもテストもやり直しになり、業務も止まります。

だから確かめる機会を、工程の途中に何度も置きます。

レビュー — 動かす前に、読んで確かめる

レビューは、成果物を人が読んで誤りを探す活動です。設計書の段階で行えるので、プログラムを書く前に誤りを見つけられます。

• ウォークスルー… 作った本人が説明し、参加者が指摘します。作成者が進行します。
• インスペクション… 進行役を決めて、決められた手順で厳密に確かめます。

テストの順序 — 小さい単位から

テストは小さい単位から大きい単位へ進みます。

この順序には理由があります。部品が正しいことを確かめずに全体を動かすと、不具合が出たときにどの部品が原因かを絞り込めません。小さい単位で確かめておけば、組み合わせたときの不具合は「つなぎ方」に絞れます。

運用テストは、利用部門が主役です。開発者から見て仕様どおりでも、実際の業務では使えないことがあります。それを見つけられるのは、日々その業務をしている人だけです。

テストのやり方の2つの見方

• ブラックボックステスト… 中身を見ず、入力に対して正しい出力が返るかで確かめます。仕様どおりかを見る立場です。
• ホワイトボックステスト… 中の処理の通り道に着目し、すべての分岐を通るかを確かめます。作った人の立場です。

両方が必要です。ブラックボックスだけでは通っていない処理が残り、ホワイトボックスだけでは「仕様の解釈が違っていた」誤りを見つけられません。

直した後、別の場所が壊れていないかを確かめるテストを回帰テスト（リグレッションテスト）といいます。直した箇所だけを確かめて終わりにすると、直したつもりが他を壊していることに気づけません。

まとめ

誤りは早く見つけるほど安く直せるので、レビューで動かす前に確かめ、テストで小さい単位から順に確かめます。各テストは対応する設計で決めたことを確かめるため、順序に意味があります。運用テストの主役は利用部門で、直した後は回帰テストで他への影響を確かめます。

理解の確認

プログラムの不具合を1か所修正した後、修正した箇所だけを確認してリリースしようとしています。この進め方の問題点と、行うべきテストの名前を述べてください。

答え: 問題点は、修正が他の箇所に与えた影響を確かめていないことです。プログラムの部品は互いに呼び出し合っており、共通で使われる処理を直せば、それを使う別の機能の動きも変わります。修正箇所だけを確認して合格としても、直したつもりが別の機能を壊している可能性が残ります。行うべきなのは回帰テスト（リグレッションテスト）で、これまで正しく動いていた機能が引き続き正しく動くことを確かめます。