品質とセキュリティに注意を払わずにコードを書き、後からアプリケーションのすべての欠陥を特定して除去するというやり方は、リソースの浪費になるだけでなく、極めて非効率的でもある。

　アプリケーションの随所に潜んでいるすべての欠陥を洗い出すには、アプリケーション全体にわたってすべてのパス（経路）を特定し、各パスをくまなく厳格にテストする必要がある。

　平均的には、5つのコード行（LOC：Lines Of Code）に付き1つの分岐が存在する。例えば、100万LOCのプログラムであれば、約20万の分岐が存在することになる──これらすべてのパスを1回実行するには、コード全体にわたって2の20万乗のパスを網羅する必要がある。

　また、すべての欠陥を検出するには、さまざまなパラメータおよびデータを用いてコード全体にわたって複数のパスをテストする必要があることも多い。

　それに、この段階で見つかった問題は修正するのが困難だ。各バグを修正するのに必要な労力やコスト、時間などは、開発プロセスが進むのに伴って指数関数的に増大するからだ。

　最大の問題は、バグ検出というアプローチでは、問題の根本原因に対処できないことだ。ほかの業界ではずっと以前に明らかになっているように、品質のカギとなるのは、品質を製品に作り込む品質プロセスを導入して適用することであり、「組立ライン」から出てきた製品の欠陥を発見、修正するための手段を探すことではない。

　品質とセキュリティをアプリケーションに作り込むには、欠陥とセキュリティ脆弱性のリスクを減少するためのポリシーに従って、アプリケーションを開発し配備した上で、ポリシーが適切に実装され、正しく機能していることを確認する必要がある。

　例えば、ユーザーが入力した値を受け取った直後に「入力値の妥当性確認を適用するポリシー」を確立すれば、入力値がコードの無限パスに入って混乱を引き起こす前に、すべての入力が妥当な値に修正されていることを保証できる。また、入力直後の妥当性確認を適用するポリシーを実装することで、コードのあらゆるパスにわたってSQLインジェクションの脆弱性を探す必要がなくなる。さらに、この種の脆弱性がテストをすり抜けて、企業を訴訟や罰金のリスクにさらす心配もなくなる。

　もう1つ例を挙げよう。開発者が「ループ内部のループのインデックスを修正するのを禁じるポリシー」を確立して適用すれば、インデックスの修正に関連したループデッドロックを探す必要がなくなる。そういったことが起きる可能性がなくなるからだ。

QAの最適化

　伝統的に、QAプロセスは開発プロセスの後に実行され、比較的長い時間がかかる。これは、企業が新規／修正ソフトウェアを効率的に提供する能力を大きく損なうものだ。さらに厄介なことに、欠陥が見つかるたびに、開発チームは多くのリソースを必要とするQAプロセスに戻らなければならないのだ。

　継続的品質プロセスの一環として、以下に示すソフトウェア検証手法を導入することにより、QA時間を最適化できる。

1.　統計分析

　単純な欠陥を探し出そうとするのは、QA時間の大きな浪費だ。単純な欠陥というのは、開発者がコードのセキュリティや信頼性、パフォーマンス、保守性などを実現するための開発ポリシーに従ってコードを書けば、容易に防げるような欠陥だ。「開発中に統計分析を実施する」というポリシーに従うことで、さまざまなカテゴリーの欠陥の発生を防止でき、その結果、後のプロセスでこれらの欠陥を発見して診断を行い、それを解決するために必要となったしれないリソースを解放できる。

　統計分析を通じてコーディングポリシーを適用するというのは「製造ラインの各段階で仕様に従って部品が生産されるようにする」ことに似ている。こうすれば、あらゆる部品を検査しなくても所定の品質の部品を確実に生産できる。

　一方、生産の一貫性が保持されていなければ、QAチームは製造ラインから出てくるすべての製品について、欠陥の発見やその修正に膨大な時間を費やさなければならない。その中には、見過ごされやすい欠陥もあるだろう。

　統計分析は、一貫性のある適切なグループポリシーを導入するための最短距離だ。適切な導入とトレーニングを実施すれば、開発チームのメンバーはポリシーを受け入れて、日々のワークフローの自然な一部としてポリシーに従うようになるだろう。

2.　開発時のコードレビュー

　アプリケーションが意図した動作をしないといった機能的欠陥を発見するのにも、多くのQA時間が費やされる。こういった欠陥を発見する唯一の手段が「人間の頭脳」だ。

　しかし、開発後に人間の頭脳でこれらの欠陥を見つけるのは容易なことではない。非常に多岐にわたる情報を同時に処理しなければならないからだ。それよりも、開発中にピアレビューを実施すれば、機能的欠陥を最も迅速で簡単にかつ安価に発見・解決ができる。統計分析の場合と同様、QA段階で対処すべき欠陥の数を減らすことにより、QAサイクルの時間とコストを削減できるのだ。

3.　自動リグレッションテスト

　QAと開発をオーバーラップさせるには、自動リグレッションテストスイートを作成し、それを完全に自動実行できることが不可欠だ。この種のテストスイートでは、統計分析やユニットテスト、プロトコルテストといった技術を活用すべきだ。

　また、テストスイートが毎晩（ビルド終了後）に自動的に実行され、加えられた修正が既存の機能に予期せぬ影響や悪影響を与える場合には、直ちに警告を発する機能を備えた自動化インフラによって、テストスイートが駆動されるようにしなければならない。

　このような自動リグレッションテストを導入すれば、QAチームはこのテストスイートの運用管理に専念できる。テストが自動的に実行されない場合に必要な対策を講じたり、アプリケーション機能が追加あるいは修正された場合にテストスイートとアプリケーションの対応が維持されていることを確認するのだ。

　要するに、QA担当者の役割が「製品検査官」から「品質スーパーバイザー」へと変化するということだ。

本稿筆者のウェイン・アリオラ氏はParasoftの戦略担当副社長を務め、同社の業務開発チームおよびSOA／Webソリューションチームを統括する。ハイテクおよびソフトウェア開発業界で15年間にわたってコンサルティングに携わった経験がある。Parasoftに入社する前は、Fasturnで業務開発担当シニアディレクターを務めたほか、PricewaterhouseCoopersでは主席コンサルタントとして戦略転換業務で指導的役割を果たした。カリフォルニア大学サンタバーバラ校を卒業し、インディアナ大学でMBAを取得した。