仕様通りに作られているかを検証する

どんな製品やシステムも、性能が正しく満たされているか、期待通り動くかテストが不可欠です。

ソフトウエアも例外ではありません。

すべての仕様が期待通り実装されているのか、検証が欠かせないのです。

設計段階から仕様通りになるように設計し、時にレビューし書いたプログラムをテストし問題なく動くように実装していくのですが、実際には「すべての仕様」が満足通り動くことを確認することはかなり難しいことです。

難しいのは、すべての仕様を洗い出すことです。

技術者にとって仕様とは「仕様書に書かれるもの」を意味しますが、必ずしも仕様にはすべてのことが網羅されていないことがあります。

できる限りのことを書くのですが、書き切れない仕様も実際には発生してしまいます。

そうすると、実際には予期していなかった動作をしたり障害が起こりえます。

最悪の場合、世の中に出してから気づくことも少なくないのです。

仕様に基づいてテストすることは当たり前ですし、それだけではなく仕様と仕様の組み合わせの評価をしっかりと行うことが大事です。

仕様を積み重ねていった結果、あの仕様とこの仕様を組み合わせると、想定していなかった組み合わせが発生するということで抜けが発生することもあります。

たとえ仕様書に書かれていても組み合わせとして気づかなかったり、仕様書には書かれていなくてもバグが潜む可能性を察知して問題点を洗い出すことがとても大事になります。

評価は評価者の仕事、という風に考えず、自らしっかりとテストする意識がが欠かせないのです。

バグは早めに潰すことが大切

誰しも人から「君、間違っているよ」といった指摘は受けたくないものです。

特にプログラムの場合、評価者から指摘されると、その指摘件数が記録に残りますし、そのバグを直すためにどのような対応をしたのかも説明する必要があります。

特に開発の終盤であれば、小さな修正であっても他の機能への萍郷がないのかを綿密に調べる必要があるのです。

バグの内容と修正にかかる手間を考えたとき、そのバグを適切な時期まで直さないという対応だって採られることがあるくらいなのです。

後になって発見されればされるほど、ことは深刻になっていきます。

ですから、バグは極力早めに潰すことが大事になりますし、そのためにも自分でできる限りの評価をするという姿勢が大事になるのです。

評価には設計が必要

バグを早く取り除くようにするといっても、手当たり次第に評価を実施していたのでは、ばらつきが出ますし抜けも発生します。

テストすべき項目が抜けた場合には、本来見つかるべきバグが見つけられないということになりかねません。

そうした抜けを防ぐためには、評価にも設計をして抜けを発生させない対策が必要になります。

テストを設計するためには、仕様書や設計書に基づいたテストをしていく必要があります。

プログラマはプログラムに基づいてテストをすることが多いと思いますが、仕様書などのよりどころに基づいて評価をすることによって、抜けを防ぐことができます。

もし、自分が書いたコードに基づいてテストしたら、本来あるべき仕様が入っていない（実装漏れ）ことに気づかないかもしれないのです。

ですから、評価をする場合には仕様書や設計書といった、よりどころとなる文書に基づいて行うのです。

ホワイトボックステストを実施する

テストは、大きく2つの観点があります。

コードの中身を知った上で行う「ホワイトボックステスト」と、中身の動作を知らず入力と出力の結果だけを頼りにテストをする「ブラックボックステスト」の2つです。

この2つは大きく目的が異なります。

ホワイトボックステストは、初期の頃に行われるテストでよく行われ、プログラマが開発しながら行うテストではコードに沿ったテストをします。

このとき、コードのどれだけの部分を評価したかという指標であるカバレッジも大事になります。

後の行程のテストになればなるほど、コードの細かい部分のテストはできなくなっていきますので、初期段階でコードごとのテストを行い、後半のテストでは全体として問題かを確認するのです。

特にエラーが発生したときの例外処理など、実際のテストでは起こせないものもありますので、ホワイトボックステストで隅々までテストしておくことが求められるのです。

コード修正したら必ず周辺もテストする

忘れがちなのが、何かバグがあって修正したときの関連部分のテストです。

コード修正するとき、自分が思っている影響範囲のテストはするのですが、それよりも広くテストすることが大事です。

影響があると思われることは結構調べるのに、それ以外のことを意外と見落としていることも少なくないのです。

それを防ぐには、一連の機能の確認をすればいいです。

ざっと機能を確認すれば、コード修正による影響を見つけやすいからです。

面倒だけれども、直したコードに問題がないか、より広い視野で確認することが必要です。

後になって見つかったバグを調べていったら、ずっと前に直したコードの影響だった、ということはプログラマなら経験のあることでしょう。

こういうのは原因見つけるのに時間がかかったりもします。

コード修正時になるべくバグを混入させない、そういう意識で取り組むことが大事です。

プログラムの品質はテストで上げる

結局のところ、完璧なプログラムというのは存在しません。

だから評価で確認するという気持ちが不可欠なのです。

頭の中で「問題ないはず」と思っていることを、面倒でも「動かして検証する」という姿勢が必要なのです。

面倒でもこういうことをやるプログラマのコードにバグは少なく、面倒くさがる人のコードにはバグが残るのです。

仮に瞬殺できるバグだとしても、そういうバグを残さないことが大事です。

そういう緻密さがプログラマとしての信頼を高めてくれるのです。