この連載記事の目次へ

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら

 次に,テスト・レビューの基本を解説しよう。実は,テストとレビューで考えるべきことは,かなり共通している。テストでは,テストを実施する前に,テスト項目をきちんと設計しなくてはならない。レビューでも,レビューを実施する前に,指摘項目をきちんと設計すべきである。行き当たりばったりのテストやレビューをしている限り,少ない手間で危険なバグを早くたくさん検出できるようにはならないし,テストやレビューの改善にもつながらない。

 テストのやり方にはいくつかの工夫がある(図4)。まず,なるべく網羅性を落とさずに手間を減らし,たくさんバグを検出する方法がある。直交配列表を用いる方法や,All-pair法などが知られている。一言でいうと,複雑な組み合わせの網羅性を割り切ることで,魔法陣のような原理を用い組み合わせテストを効率化するものである。富士ゼロックスが開発した「HAYST法」が,日本では最も有名である。

テストの目標は少ない手間で早くたくさん危険なバグを検出すること

図4 テストの目標は少ない手間で早くたくさん危険なバグを検出すること
テストにおいては,「少ない手間で」「早く」「たくさん」「危険な」の4つのキーワードのどれが抜けても,品質が低下してしまう。良いテスト設計をするためには,バランス感覚が重要なのである。

 網羅性はさておき,少ない手間で早くたくさんバグを検出する方法もある。バグが多そうなパターンを狙って,集中的にテストを実施する手法が代表的だろう。こうしたパターンを,不具合モードと呼ぶ。例えば,ソフトウエア・モジュール間のインタフェースとなる部分や変更・修正が多い部分,要求や設計が複雑な部分,エンジニアが認知ミスを起こしやすい部分などが不具合モードとなり得る。コーディング規約は,実装工程における不具合モードの集成ともいえるだろう。

不具合情報を活用しフロント・ローディングへ

 不具合モードは,レビューのチェック・リストや設計ガイドラインの改善にも活用できる。バグが作り込まれた部分というのは,開発者が間違えやすい特徴を持っている。すなわち,不具合モードは,開発組織の弱点を具体的に意味しているのだ。従って,テスト部隊が不具合モードを分析し,上流工程のエンジニアにフィードバックすると,工程間の連携が深まり,ハードウエアのモノづくりのようにフロント・ローディングが可能になるのである。

 また,危険なバグを早く検出する方法もある。リスク・ベースド・テストが代表例だろう。機能ごとに,製品としての重要性や不具合が起きた場合の影響の大きさをリスクとして整理しておき,優先順位をつける方法である。リスクの高そうなテスト項目を優先的にテストすることで,テスト項目をすべて消化できずに出荷する事態に備えることができる。

 テストの目標は,少ない手間で早くたくさん危険なバグを検出することである。「少ない手間で」「早く」「たくさん」「危険な」の4つのキーワードのどれが抜けても,品質が低下してしまう。良いテスト設計をするためには,バランス感覚が重要なのである。

回帰テスト実施で設計を改善

 テストの中でも難しいのは,回帰テスト(リグレッション・テスト)である。回帰テストとは,変更を加えたりデバッグをしたりした後に,もう一度テストを実施することで,デグレード・バグの発生を防ぐものである。ソフトウエアは変更の影響が想像も付かないところに発生することがあるので,原理的には回帰テストですべてのテスト項目を再実施する必要がある。

 しかし変更やデバッグの度にすべて実施すると工数が膨大になるため,上手に間引きをする必要が出てくる。依存関係が多く設計の見通しが悪いソフトウエアは,変更やデバッグの影響が思わぬところに出現してしまうため,回帰テストの間引きが非常に困難になる。どこの組織も苦労していることだろう。間引きが下手な企業は,何度もデグレード・バグを引き起こし,納期遅れや品質事故を多発する。

 一方,回帰テストの間引きを上手に行っている組織は,設計も上手であることが多い。回帰テストの項目を抽出しやすくなるように,ソフトウエアの設計を見通しよく改善するからだ。また,テスト工程と設計工程で密に連携を取り,上流工程からテストのことを十分考えておくことにもつながる。

「Wモデル」は世界的なトレンド

 上流工程からテストのことを考える1つの方策は,「テスト・ファースト」のような考え方で,テスト設計を上流工程で行う方法である。具体的にテスト項目を抽出することによって,テスト実施をしなくても,要求や設計の抜け,曖昧な点,矛盾点などを見つけることができる。つまり,具体的なテスト項目を用いて,レビューを行っていることになる。このように上流工程でテストを設計すると,テスト実施やテスト設計が難しかったり,テスト項目が増えすぎてしまう仕様・構造であったりといったことも分かるので,分析や設計の質が向上する。

 こうした考え方は,通常の開発工程の「Vモデル」を2個ずらして重ねた「Wモデル」として提案されている(図5)。一般のVモデルでは,実装を経た後,初めてテストに取りかかるが,Wモデルでは,後半のテスト工程のうちテスト設計をすべて前半に移す。テストの設計を,分析や設計工程,実装工程で同時に実施してしまい,後半はすべてテストの実施だけにするわけだ。

Wモデルでテスト設計工程を上流にシフト

図5 Wモデルでテスト設計工程を上流にシフト
Wモデルでは,後半のテスト工程のうちテスト設計をすべて前半に移す。テストの設計を,分析や設計工程,実装工程で同時に実施してしまい,後半はすべてテストの実施だけにする。

 そのため,分析,設計,実装の各上流工程と,システム・テスト設計,機能テスト設計,結合テスト設計,単体テスト設計の各工程が並列に進むことになる。Wモデルは,テスト設計によってレビューの質を向上し,かつ上流工程でテストについて検討しテストしやすいソフトウエア開発を促進する開発プロセスである。

 Wモデルは,世界的なトレンドである。日米欧の最先端の開発組織では,分析・設計工程とテスト工程の融合に取り組んでいる。組み込みソフトウエアを競争力の源泉として欧米やインド,中国と戦っていくには,こうした取り組みを率先して進めていくべきであろう。

(第5回につづく)