ソフトウェア・テストの現状
ソフトウェア開発を行う際には、必ずテストを行います。特に、現代のソフトウェア開発では、全開発工数におけるテストの比率が高くなる傾向にあります。なぜならば、（前回も触れたように）現代のソフトウェア開発では、「ゼロからすべてを作るケースはほとんどなく、既存システムの拡張、または出来合いのサービスの利用によって開発を進める場合が大半」だからです。つまり、テスト工数に比した開発工数は相対的に減少しているというわけです。
ここで、「既存のシステムや出来合いのサービスをベースにするのであれば、テストの工数も少なくて済むのでは」と思われる方もおられるでしょう。
確かに、出来合いのソフトウェアを用いた場合、ソースコード・レベルのテスト工数は確実に削減されます。ただし、開発したソフトウェアについて、ビジネス上の価値要件を満たしているかどうかのテストを行うとすれば、どうでしょうか。そうしたテストは、ソフトウェアが要求仕様どおりに機能するかどうかを点検するテストとは異質なものであり、その工数の多寡は、開発工数の多寡とは無関係です。そのため、開発の工数が削減されたからと言って、テストの分量も少なくなるとは一概には言えないということになります。
このように、ソフトウェアのテストには開発の方式次第で減るものと、そうでないものが存在します。ですから、テストを実施する際には、テストに関する整理整頓を事前に行い、全体のバランスを見ながらテスト量を調整していくことが重要となります。仮に、そうした作業を行うことなく、従来の古典的なテストの進め方を踏襲していると、テスト工数がいたずらに増大し、テスト工数の比率がますます大きくなっていくのです。
従来のテストを踏襲するリスク
テスト量の増大は、ソフトウェアの開発コストはもとより、品質にも悪影響を及ぼします。というのも、テストの分量があまりに大きくなると、開発にかかわるメンバーがテストの実行に忙殺されることになるからです。しかも残念なことに、この問題を解決するために誤った手段がとられることが珍しくありません。
例えば、人員を大量に追加投入して、計画したすべてのテストを「とにかく終わらせようとする」のは典型的な誤りの1つと言えるでしょう。
このようなかたちで、「テストを完了させること」に集中しすぎると、テストを前に進めること以外に意識が向かなくなります。そうなると、ソフトウェア開発の本来目的を再確認しないままテストを実行するケースが増え、結果的に「大量のテストを行っているにもかかわらず、最も大切な部分の確認が行えたかどうかが分からなくなる」といった事態に陥るのです。
もう1つ、誤った手法として挙げられるのが、コストや日程に合わせてテストを無理やり省略してしまうことです。この方法の背後には、「おそらく大丈夫だろう」という根拠のない思い込みが存在します。そのため、こちらの方法を採用した場合でも、大切なことを見落としてしまうおそれが強まるのです。
テストは単なる実行作業ではない
ソフトウェア開発を巡るこうした課題を解決する方法はいくつか存在します。
ただし、ソフトウェアの利用者側が最も留意すべき点は、現代のソフトウェア開発の特性に合わせたかたちで、テストすべき事項の整理整頓と分量の調整を行うことです。これはすなわち、単なるテストの実行ではなく、テストを計画したり設計したりする活動こそが最も重要であることを意味しています。
ですからまずは、テストの全体像を整理し、成すべきことを把握できるようします。ここでは、例えば、テストすべき項目を以下の3つに分けて洗い出し、その全体像を一覧形式で整理するといった方法が考えられます。
① 開発者自身が行うソースコードをベースにしたテスト
② 開発者間で調整して実施されるアーキテクチャなどの設計をベースにしたテスト
③ 利用者が最終的に考慮すべきビジネス要求をベースにしたテスト
次に、ソフトウェアのビジネス価値を判断するうえでは、どのような情報を収集／集約すればよいのかを検討し、テスト量を調整していきます。
例えば、ビジネス上の要件が「膨大な数のユーザーの使用に耐えうる信頼性の確保」であれば、そのチェックに軸足を置いたかたちでテストを設計し、実行します。つまり、「設計ベースのテストについては、データベースの構造やアプリケーション・サーバのメモリ・キャッシュの点検を行い、ビジネス要求に関するテストでは想定ユーザー数とそれを超えた場合のテストを行うといった具合です。
加えて、コードや設計、要求に基づいて、「現在、何％のテストが完了しているか」といった達成度を常に計測しながら、その状況がリアルタイムに閲覧できる仕組みを作ることも重要です。いわば、ソフトウェア開発情報のシステム化（IT化）を図るというわけです。
これによって初めて、ソフトウェアのビジネス価値が判断できるようになります。なかでもテストの達成度を測り、リアルタイムに閲覧するための仕組み作りに関しては、全体を俯瞰できる立場の人たち、つまり利用者側が率先して行うべきです。
テストの整理と調整における2つの成功要因
テストの整理と調整は、一見すると当たり前のことのように思えます。ただし、この連載で何度も言及している「開発のサイロ化」によって、ビジネス要求や設計、開発の成果物、およびテストの成果物の内容が隔絶してしまうと、それぞれが相互にどう紐づいているのかを確認すること自体が困難になり、それを明確にしようとするだけでも実に多くの工数がかかってしまいます。
そんな中で求められるのは、要求や設計、コードとテストとの間のトレーサビリティを確保すること（つまり、紐づけをすること）と、トレーサビリティを維持し常に監視することの２つです。
トレーサビリティを確保するうえで大切なポイントは、その作業を後回しにせず、テストを作成するのと同じタイミングで実施することです。
また、そのための下地作りとして、ソフトウェアに対する要求をビジネス要求とシステム要求といった適切なタイプに分類し、階層化しておくことも重要です。つまり、このようなかたちで要求を整理することで、どのテストがどの要求に紐づくかが分かるようになるのです。
一方、トレーサビリティの維持と監視には、その仕組みのIT化も求められます。というのも、紐づけの対象は数千、もしくはそれ以上になるため、IT化を行うことなくトレーサビリティを維持しようとすると、それ自体が開発のボトルネックになってしまうからです。
また、監視を行ううえでの最良の方法は、トレースした情報を日々のプロジェクト業務の中で活用することにほかなりません。
このようにして、IT化された仕組みを通じてテストの達成度を見ていくことは、ソフトウェアの品質がどういった状況にあるのか、また、品質がきちんと維持されているかどうかを監視することにもつながるのです。
以上、今回は利用者がソフトウェアのビジネス価値を判断するうえで有効となるテストの方法について論じました。上で触れたトレーサビリティの確保は、とても地道な活動です。そのため、トレーサビリティの維持と監視をそれほど重視してこなかった方にとっては、この作業は実に面倒で余計なコストがかかるプロセスに映るでしょう。
ただし、この地道な活動を着実に遂行することで、開発全体のコストも大幅に削減することが可能になるのです。次回も引き続き、利用者の価値判断に役立つようなテストの方法にについて解説します。
※ これは2011年にCIOオンラインにて「【HP特別連載コラム】探求！ビジネス成長とIT革新
シリーズ3：ビジネス成果をもたらすソフトウェアを開発するために（4）」として連載したものを転載したものです。