ソフトウエアの品質を確保するために、テスト現場が変わり始めた。要件定義段階からテスト設計に着手することで、「無計画・場当たり・人海戦術」と評されてきたテスト環境を改める。“テストありき”に変えることで、仕様が明確になるうえ、達成したいソフトウエア品質のマネジメントが可能になる。テスト支援ツール・ベンダーも、テスト工程のマネジメント機能の強化に力を入れている。

(井上 英明)


【無料】サンプル版を差し上げます本記事は日経コンピュータ6月12日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集2」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバーをご利用ください。

 ソフトウエアに起因するシステム障害が起きた際、こんな言い訳を聞いた、あるいはしてしまったことがないだろうか。
「上流工程の遅れがテスト工程を圧迫し、テストのための時間が十分に取れなかった」。
「テスト中に要件と仕様の食い違いに気がついても、要件にまでさかのぼって修正するだけのリソースも時間もなかった」。

 これらの言い訳は、昔から変わっていない。テスト工程は軽視されているとも言える。

 だが、いつまでもこのままですむわけがない。情報システムの利用範囲が広がり、システム停止は社会活動をも停止しかねないし、自動車などに組み込まれたソフトウエアの不具合は人命にもかかわる。ソフトウエアの品質は、これまで以上に問われている。テストとプロジェクト・マネジメントのコンサルティングを手掛けるサイクスの宗雅彦社長は、「開発を取り巻く環境が厳しさを増すばかりの今、ソフトの品質を確保するには、テストのやり方を根本的に変えるしかない」と断言する。

テストで不具合発生を“予防”

 宋社長が指摘する、テストの根本的な見直しとは、これまでテストの直前に実施していたテスト設計を、要件定義や設計と並行して実施することだ(図1)。上流工程でテスト内容を設計する“テストありき”に変える。

図1●上流工程から“テストありき”に変えることで、品質確保に向けた計画的なテストが可能になる

 具体的には要件定義時にシステム・テストを設計。基本設計段階では結合テスト設計を、詳細設計段階では単体テスト設計をそれぞれ実施する。テスト設計で作成するのは、テスト設計書とテスト・データである。成果物自体は、現状はテスト直前に実施しているテスト設計と同じで、変わらない。テスト設計書には、要件や設計内容に基づき、機能やモジュールのインプットとアウトプット、テストの実行手順と実施環境、他のテストとの依存関係などを明文化する。

 テスト設計を上流工程で実施する方法は、「予防テスト」と呼ばれ、メインフレームでの開発が主流だった時代には、当たり前だった。そのメリットは大きく三つある。第1は、テストを設計できない要件や、複数の要件間の矛盾を上流工程で指摘できること。下流工程でテストを設計し、要件の矛盾に気付いてもプログラム開発が終了している段階で要件を変更することはほとんど不可能に近い。

 2点目は、上流工程で要件の精度が上がることで、無駄な実装とテストがなくなること。開発量が減れば、不具合の数も減る。そして三つ目が、テストのボリュームがプロジェクトの初期段階で明らかになるため、計画の見通しが良くなることである。テスト・ケースの数が明確になるため、実装後のテスト作業を平準化でき、結果としてテスト品質が高まる。

 にもかかわらず、予防テストは姿を消した。その理由を宗社長は、「テストや品質に対する取り組み姿勢が現場の技術者に引き継がれなかったため。クライアント/サーバー、Webとシステム環境が変わる過程で、情報システムの規模は10年前の10倍に拡大したにもかかわらず納期は半分。テスト工程がしわ寄せを受けた」と指摘する。

ユーザー企業にも原点回帰の動き

 それがここにきて、予防テストに“原点回帰”する例が現れてきた。ソフトウエア品質が事業損益や会社の信頼に直結するパッケージ・ベンダーなどが先行。それにユーザー系企業が追従する。

 テストのコンサルティングを手掛ける豆蔵の大西建児ES事業部シニアコンサルタントは、「テストの根本を見直す機運がユーザー企業や、受託開発型ITベンダーに広がり始めた。情報システムの利用範囲や開発スタイルが大きく変化している中で、テスト現場に自動化ツールなどを導入するだけでは品質が高まらないことに気付いてきたからだ」と話す。

 ユーザー企業で“テストありき”の改革にいち早く取り組んだ一社が、石川島播磨重工業(IHI)のシステム子会社であるIHIエスキューブ。2006年4月に本稼働させたWebベースの調達システムを開発するに当たり、テスト設計を上流工程で実施した。同システムはIHIグループ全体で2200人が利用する大規模システムだ。

 IHIエスキューブは、品質管理の国際標準規格ISO9001を取得するなど、品質を軽視してきたつもりはない。しかし、テスト工程は決して万全ではなかった。実装後にテスト設計を実施してきたため、「要件とテストの関係があいまいになり、テスト内容に漏れがあった」(プロジェクト・リーダーを務めた河本拓二ソリューション事業部第三プロジェクトグループ長)という。

 “テストありき”に変えた効果について、河本グループ長は、「テストの見方が180度変わった。これまでのようなテスト漏れや、人海戦術と徹夜に頼ることはなくなった。現場からは、バグの多発と迫る納期に頭を抱え込むといった悲壮感が消え、むしろ『次のバグを発見し品質を高めよう』といった積極性が生まれてきた」と話す。


続きは日経コンピュータ2006年6月12日号をお読み下さい。この号のご購入はバックナンバーをご利用ください。