ソフトウエアの品質を守る最後の砦はテスト

ソフトウエアをリリースして良いかを判断する重要な指標の一つにテストの結果があります。

テストは開発者と別の人が、仕様書と付きあわせて検査項目を作り、一つ一つ検査していきます。

開発者は自分でプログラミングしているので問題ないはずと思っていますし、またある程度の規模以上では複数人で開発することがほとんどなので、個々の部分には問題がなくても全体で動かすとお問題が起きることもあります。

ですので、第三者がソフトウエアの全体をくまなく検査することが求められます。

テストはソフトウエアの品質を決める最後の砦なのですが、問題はきちんと検査項目をしっかり出し、機能のほとんどをカバーできているか、ということがとても重要になります。

テストは期間の定めもあり、人員の制約もありますので、テストの網羅率を高めた上で効率的に進めていくことが求められる、非常に重要な仕事です。

検査項目は正常系と異常系をカバーする

検査項目を作るとき、仕様書の記述に沿って検査項目を作っていきます。

開発者はプログラムのコードのすべてをカバーできるようにプログラムベースのテストしますが、テストで行う工程ではプログラムがどう作られているかではなく、機能が仕様書通りに動くのかで検査します。

機能的には大きく正常系と異常系に分かれ、正常系とは通常の操作で問題なく動作する場合のことを言います。エラー処理も決まっている場合は、これも正常系に含みます。

例えば、入力画面で入力できない文字を入力したときにはじくようにするのは正常系に分類されます。

異常系とは、正常な動作をしたにもかかわらず起きる場合で、入力がサーバーに通知されたのに保存されていないとか、保存できていないことがわかり別の部分がアラートを出したとか、そういったときの処理になります。

正常系、異常系、どちらもシステムの機能として不可欠です。

両方をカバーしてはじめて検査項目としてできたということが言えます。

異常系のテストが難しい

異常系もテストに必要なのはわかっていても、異常系とはそもそも通常の仕組みの中で起きにくいことなので、なかなか現象を起こせないというジレンマがあります。

そのテストのためには、いかにして異常に近い状態を発生させるか、ということがカギになります。

そのためには開発者の協力が不可欠になる場合もあります。

やりたい異常系の状態にもよりますが、例えば内部的に異常な状態を作り出すわけですね。

なかなかこういうテストは難しく、機能の100%をカバーしていくことは至難の業です。

それでもテストが最後の砦である以上、できる限りカバーしていくことが求められます。

どうしてもテストできないものは、開発者がテストしていることでよしとする場合もあります。

網羅性の高い検査項目を作る

検査項目を出すとき、組み合わせとして多くのことをカバーするのが大切です。

やみくもにたくさんやっても、同じことを検証しているだけということになりかねませんし、いかにテストの網羅性を上げるかということに注力しましょう。

網羅性を上げるためには、組み合わせとして違うパターン作ったり、値として意味の違うものを与えることによって、プログラムの違う経路を確認したりします。

そのためにも、機能仕様を理解して、通常はこういう動作をするが、これこれのときは別の処理をしているなということを理解して、通常と別の処理をしているパターンを分けてテストをするということになります。

その辺の検査項目の組み方は少々熟練する必要があるとは思いますが、既存のテスト項目をみながら学んでいくことが大事でしょう。

テストの効率化を目指す

テストは最後の砦ですが、何でもかんでもテストでカバーすることはできません。

時間は限られますし、テストの人員も必要な分だけ提供されるわけでもありません。

そこで効率的なテストの実施が求められます。

検査項目の順序の組み方次第で、1つの手順で2つ以上の検査を実施できる場合もありますし、組み合わせとして減らせる場合もあります。

テストの順番によって同じことを繰り返す手間を減らせることもあります。

テストの進捗やテストの目的にもよりますが、テスト項目に書かれた通りに順にやるのではなく、効率的な実施方法も考えながらやることも大事です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

評価には設計が必要

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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