(株)ベリサーブは20日、(株)エクスカル、(株)エス・キュー・シー、オープンインターフェース(株)、(株)システムソリューションセンターとちぎと共同で、情報システムの開発や検証、評価に携わる人を対象にしたセミナー“第3回 システム検証セミナー”を都内で開催した。
(株)ベリサーブはハードウェア/ソフトウェアの検証や、テスト環境の貸し出しなどを行なう企業。システム検証作業の標準化のため、学識経験者を交えた“システム検証理論研究会”を設置し、システム検証の標準化や理論化を行なっているほか、『月刊アスキー』と共同でパソコンやデジタル機器の検証プロジェクト“日本デジタル検証プロジェクト”を行なっている。
“システム検証セミナー”は、2001年11月の“実践的製品検証セミナー”から年に1度行なわれている、ハードウェア/ソフトウェアを組み合わせたシステム製品の検証に関するセミナー。今回は“攻めの検証 ～ソフトウェアの終わりなき検証。どこまで、いかにして行なうべきか～”をテーマに、検証方法の紹介や事例紹介、システム検証企業によるパネルディスカッションなどが行なわれた。
“攻めの検証”は“特定の誤りを防ぐ”ための検証
基調講演では、中央大学理工学部経営システム工学科教授の中條武志氏が“攻めの検証”の方法について紹介した。
 |
|---|
| 中央大学理工学部 経営システム工学科教授の中條武志氏 |
中條氏はまず、現在のシステム検証について、「完全に検証できない複雑なシステム製品が多い一方、検証期間はできるだけ短縮し、早く市場に製品を送り出したいというニーズもある。どこまで検証を行なうのかが重要だ」と問題を提起した。
そのうえで、現在おもに行なわれている方法である“バグ収束曲線”(バグはランダムに存在すると仮定し、ランダムにバグをフィックスすると、当初は数多く発見されるバグが徐々に少なくなり、最終的にほとんどのバグをフィックスできることを示す曲線)に基づいたランダムなバグフィックスは、「検証に十分な工数をかけられた時代の方法で、現在のトレンドにはあわないもの」であると語った。
 |
|---|
| バグ収束曲線。縦軸を修正したバグの数、横軸を検証にかける時間すると、時間の経過とともに修正すべきバグの数は減少するというもの。中條氏は「検証に時間をかけられない場合には合理的でない理論」だという |
中條氏は“攻めの検証”について「“正しいことを確認する”という発想では必ず行き詰まる。“特定の誤りを防ぐ”という逆転の発想が必要で、それが“攻めの検証”だ」と説明し、“攻めの検証”を行なうためのポイントとして以下の3点を紹介した。
- これまでの検証結果を基に、検証すべき特定の誤りである“失敗モード”を抽出する
- 抽出した“失敗モード”の発生頻度や影響、検出方法に関する知識やノウハウを体系化する
- “失敗モード”やノウハウを検証に活用するためのフレームワークを用意する
特に“失敗モード”の抽出については、「モードは単なる分類とは違う。個別の問題を羅列するのではなく、さまざまな製品に共通して適用できるものだ」と説明し、モード抽出のためには開発プロセスに関しても知識が必要になることなどを説明した。
中條氏は最後に、排他制御や割り込み処理の誤りをテストする“高頻度テスト”や障害発生時に問題の影響範囲を小さくしたり対応を支援したりする仕組みをテストする“障害対応テスト”など、具体的なテストを紹介した。
 |
 | |
|---|---|---|
| “高頻度テスト”の設計方法。リソース、リソースを共有するプロセス、検証すべき誤りを表にしてテストを設計する | “障害対応テスト”の設計方法。それぞれの障害に対して、影響や対応する機能、検証するべき誤りを抽出してテストを設計する |
講演終了後、参加者からは「“アジャイルプログラミング”など、開発とテストが並行して行なわれるような場合、“失敗モード”抽出はどのようにすべきなのか」といった質問がなされた。中條氏は「そのような場合も、すべてのバグをなくそうとすると検証の終わりがなくなってしまう。これまでの経験や、開発部門との連携で、なくすべき問題を明らかにすることが重要だ」と答えた。
