モデル駆動型ソフトウェアテストの可能性：ソフトウェアテスト・エンジニアの本音（1）

[大西建児，株式会社豆蔵]

テスト現場の生の声をお伝えするために

　ソフトウェアテストに片足だけはまっている人、頭からつま先までずっぽりはまっている人……、テストとのかかわり具合はエンジニアによってそれぞれでしょうが、テストと全然かかわりを持たないという技術者はおそらくいないでしょう。テストへの取り組み方は十人十色なだけに「テスト」と聞いて、自慢するのか愚痴をつぶやくのか、あるいはきびすを返して逃げ出そうとするのかいろいろな反応があると思います。

　立場こそ違いますが、テストが大事だという認識はほとんどのエンジニアが持っていると思います。しかし、プログラミング手法や開発手法などのように、スキルアップのための材料が簡単には得られないという印象を（テストに対して）持っているエンジニアが多いようです。テストに関する日本語の情報は豊富とはいい難いのが現状ですし……。

　「テストに興味を持って活動しているエンジニアは、テストのことをどのようにとらえ、どのように自分のテストスキルを磨いているのだろう？」

　本連載では、こういった疑問にお答えするべく、テストに「ずっぽり」とはまってしまっているエンジニアたちが集まって主催する「JaSST：ソフトウェアテストシンポジウム」実行委員会のメンバー（以下、JaSSTメンバー）がテストに対してどのようなことを感じ、どういった工夫をしているかをざっくばらんにお届けしていく予定です。

　本連載は、JaSSTメンバーがJaSST’05（2005年1月24日と25日に品川の東京コンファレンスセンタで実施予定）に向けた準備会議の後に非公式に開かれる懇親会で、あれやこれやとテストに関して盛り上がったことを素材に記事化をしていきます。JaSSTメンバーのざっくばらんな議論から生じる「テスト現場の生の声」をお伝えできればと思います。

　懇親会の場の議論にしては、少し上品過ぎるのでは？ と思われる読者の方もいらっしゃるものと推測しますが、本当の生の議論に興味がある方は、ぜひJaSST’05に参加していただければと思います。また、ソフトウェアテスト技術者交流会（TEF）のメーリングリストでも普段からテストにかかわる議論を行っていますので、こちらへの参加もお勧めします。

　なお、本文は第一線のエンジニアによる、テストを軸にした濃い会話が基となるため、聞き慣れない用語や表現があるかもしれません。専門用語にはできるだけ解説を加えながら議論の跡をスムーズにたどれるよう工夫をしていきたいと思います。参加者については参加者一覧表をご覧下さい。

議論パート

モデル駆動型ソフトウェアテストの可能性を問う

　9月某日、都内某所にてJaSST実行委員会が実施された後、空腹を満たすべく委員たちはこぞって別の食事処に移動しました。食欲を満たすことひとしきり、座が盛り上がってきたところで榊原氏（日本IBM）がいつものようにモデルに関する話を切り出したのでした。

榊原　ソフトウェアテストを地道にVモデル（注1）で実施して、品質を確保するっていうスタンダードなアプローチ自体は否定しないけど、もうそろそろ、システムを作りながら同時に検証もしていくっていう（ソフトウェア開発の）世界になっていくべきだって最近考えているんだけど、みんな、どう思う？ もちろん、技術的には発展途上だし、難しい面がたくさんあるから、夢物語っていわれるかもしれないけどね。

---

---

　 MDD（Model Driven Development：モデル駆動型開発のこと）の活用を推奨している榊原氏ならではの発想です。ご本人の言によると、「テストの実施が面倒なので、先端技術でテストを省けるものならなるべくそうしたいと常日ごろ考えている」とのことです。こういった考え方がベースにあって、モデルによる静的な検証を充実させることで、動的テストの実施段階まで持ち越さなくてもよくなるのだというアイデアを持たれたのでしょう。この発言に対して電気通信大学の西氏から肯定的な反応が出ました。

西　私見だけど、統合環境として充実したアンチ・デザインパターンがそろっていて、なおかつモデル図を描く端から過不足をどんどん指摘してくれるみたいな感じの、つまり、コードを書く端から文法チェックをするエディタみたいに、モデルをチェックするツールができれば、そういう理想的なことも可能になると思いますけどね。

　これに対しては、まだまだ静的テストに対して、動的テストの比重は減らないだろうと考えている「テスト実践派」の大野氏（日立ソフトサービス）からこのような質問が上がりました。

大野　モデルベースで仕事するっていうことは、つまり仕様をモデルで全部表すということ？ 実際の開発作業では、コードの8割くらいは正常パターンよりイレギュラーケースの記述にエネルギーを費やしているわけだから、そのアイデアの実現性に対しては正直いって疑問だな。ドメイン的には業務アプリケーションや組み込みソフトウェア開発でいうところの「メカ、エレのインターフェイス」では実現は無理だと思うけど。

　この疑問に対して、榊原氏が補足説明を加えました。

榊原　うーん、少し誤解が交じっていると思う。モデルだけで仕事が完結するなんてもちろん思っていませんよ。実際、いま指摘されたように、イレギュラーな部分ってまだまだモデル化し切れないところがあることは十分認識しているつもり。ただ、現在のモデル記述の発展状況からすると、将来的にはいまよりもモデルでカバーできる範囲は広がっていくだろうと思っているんです。

　ここで、黙って議論を聞いていた鈴木（三）氏（TIS）から、声が上がりました。

鈴木（三）　先ほどから話されているモデルベースでの検証というのは、究極的にはVモデルに対するアンチテーゼでしょ？ Vに対して「バックスラッシュ・モデル」って名付けるのはどうですかね（注2）。

---

---

　Vモデルが以下のように対応する上流フェイズの検証を実施するのに対して、

　以下のようにモデル化による静的検証だけで、Vモデルで行っていた動的検証をカバーできるようになるというアイデアとなっています。

　このように、V字に対して「＼（バックスラッシュ）」の形となるため「バックスラッシュ・モデル」とこの議論の中では呼んでいます。

　さて、ここで「テスト実践派」の高橋氏（ソニー）が言葉を継ぎました。

高橋　動的検証を省けるというのはやっぱり極端でしょ。

榊原　いやいや、だからモデル・オンリーで検証が終わるわけじゃないってことは十分認識してますってば。だけど適用範囲さえきちんと絞り込めればこの「バックスラッシュ・モデル」は十分成立すると思いますよ。ともあれ、「バックスラッシュ」はいいね。気に入った。

高橋　だとしても、本質のところが分かっていないと、下手すると「作りっ放し」でいいっていう誤った認識を助長しちゃうんじゃない？ そうならないといいんだけどね。

榊原　そうか。意見が合わない理由の1つとして、テストの専門家の皆さんってさ、どうしても「テストでバグが出ないと」おかしいっていう認識が常にあるからでしょ。

　テスト実践派もそれには異論がないようでした。

榊原　でも、常に一定ラインまでバグを出すことを前提にテストを実施するというのも、いまのご時世の論理としては無理があるように思っちゃうなぁ。「バックスラッシュ」的なアイデアも挑戦する価値があると思うけど。

鈴木（三）　いまの議論の是非はともかく、動的テストを実施しているときは「バグが出ないと意地になる」という一面は確かにありますよ。動的テストを実施するときには「バグは絶対あるはず」という前提で行うから、静的テストだけで動的テストの不具合が取り切れるっていうアイデアはやっぱり違和感があるんですよね。

　この辺りから話は堂々巡りになりそうだったため、いったん議論は落ち着きました。そこで、以上の議論を技術的な観点から分析し、どういったことが考えられるかを次のパートで解説します。なお、以下の解説は鈴木（三）氏と大西が共にまとめました。

解説パート

「バックスラッシュ・モデル」、その特徴と背景

　解説では、「バックスラッシュ・モデル」というアイデアがJaSSTメンバーから生まれた背景や、モデルのメリット／デメリット、今後の展望などを説明します。

　開発プロセスは時代とともにいろいろな形態が提案されています。アジャイル的な方法論はその代表格といえるでしょう。ただ、テストに関しては、提唱され始めてからかなりの時間が経過している「V字モデル」がいまでも使われています。方法論が進化しているように、テストの分野でも新しいモデルが提唱されてもよいのではないか。こういった考えがベースとなり、今回の議論へと発展しました。

　「バックスラッシュ・モデル」の特徴を簡単に整理すると以下の2点となります。

• 動的テストを行わず実装が終わった段階でリリースする
• 動的テストを実施する独立したテストエンジニアを介す必要がない

　このアイデアに対して「テスト実践派」が違和感を覚えたのは、ソフトウェア開発の現場において「動的テストを一切行わない」という組織は皆無だからでした。確かにこのモデルは、動的テストにかかる工期や工数を削減できるため、短納期開発をさらに進めることができるというメリットがあります。

　一方、このモデルにもデメリットがあります。イレギュラーな処理に対して適用すると検証が不十分になる恐れがあるのです。また、エンジニアに高度な技術的バックボーンを求めます。現在の統合開発環境でも、コーディングスタンダードにのっとった静的解析により、誤ったコーディングを指摘してくれるツールが存在しますが、このモデルで要するツールは、これを要件の領域まで広げるイメージのものとなります。

　ですから、MDDを究極的に推し進めると「バックスラッシュ・モデル」になります。要件定義の段階から一貫してモデルベースでの開発が必要になるのです。こういったアプローチは最近のソフトウェア工学分野で研究が活発化しています。興味のある方は、最近のIEEE Software誌2004年9〜10月号に寄稿された「Test-Driven Modeling for Model-Driven Development」という記事をご覧ください。

　ところで、「バックスラッシュ・モデル」には以下のような問題もあります。

• 現時点では、仕様のすべてをモデルで表現することは不可能
• 現在のプロジェクトでも、十分にテストを行わないところが多いにもかかわらず、間違った認識を広める恐れがある
• 仕様の勘違いなどをモデルだけで検証できない部分がある

　こういった点を考慮しつつ、実用化を目指すべきものでしょう。今後の展望としては、まずはMDDの環境が整備され始めた組織から小規模プロジェクトや開発の一部で適用されるようになると考えられるでしょう。「テスト実践派」からすれば、「このモデルどおりに開発が進んだら、テストエンジニアは全員用済みになってしまう」とか「動かさないで納品なんて邪道だ」「バグを見つける楽しみを取らないでほしい」といった声も聞こえてきそうです。

　しかし、上記で示したようにすべてをモデル化できるわけではありませんから、人間でなければできない高度な検証というのはこれからも残るわけです。ツールでできることを、人間がやることはないでしょう。また、今後もプロフェッショナルなテストにかかわるエンジニアが高度な技術や経験をベースに、人間にしかできないテストを追求していくことにも変わりはないと思います。