ソフトウェアテストの近未来を話そう（前編）～テストと開発の融合が必要 JaSST'12 Tokyo

これからのソフトウェアテストの課題とは何か、どのように進化していくのか？ そのために必要なこととは何でしょうか。

先週、1月25日と26日に都内で行われたソフトウェアテストに関するシンポジウム「ソフトウェアテストシンポジウム JaSST'12 Tokyo」。クロージングセッションでは、ソフトウェアテストの近未来はどうなるのか？ というテーマでディスカッションが行われ、ソフトウェアテストのこれからがパネリストの意見を通して浮かび上がってきました。

パネリストは、基調講演に登壇したマイクロソフトのBj Rollison氏、招待講演に登壇した東海大学の山浦恒央氏、そして電気通信大学の西康晴氏の3人。司会はガイオ・テクノロジーの大西建児氏。ディスカッションの内容をダイジェストで紹介しましょう。

テストと開発の融合が必要だ

司会　パネリストのみなさんにお伺いします。今、ソフトウェアテストのどこに関心がありますか？

Rollison氏　10年前にトピックだったことが、いまだに議論の対象になっていること。探索テスト、サーティフィケーション、モデルベーステスト、さまざまな分析方法、もう10年以上ソフトウェアテストの分野で話題になっていますが、いまだに最新の技術だと思われています。

現在では、例えばスマートフォンのような新しいテクノロジーが登場しています。技術が進化する中で、テストのプロフェッショナルはそれに見合う形で進化していないのではないでしょうか。

そういった中で、ここ2～3年の最大の関心事は、プロフェッショナルなテスターがこの変化の中で技術を高めていけるかどうかです。

山浦氏　今は1000万行を超える大規模ソフトウェアがごろごろしていて、その品質保証をしなければなりません。これをどうするか。1行1秒でチェックしても10万年かかる。しかもそれではロジック抜けなどは見つかりません。

完全なテストは、理論的には可能ですが、現実には不可能です。

「正しいこと」を証明するのは非常に大変ですが、それが私たちに課せられた使命です。ですから、バグを見つけるのではなく、予防の観点で、作らないようにする、作り込まないような開発プロセスを確立しないとだめでしょうね。

そのためには、テストだけではだめ、開発だけでもだめ、両者が融合しなければいけません。テストをいかにしないですませるか、大規模ソフトウェアではそうなる。この動きがじわっと出てくることを期待しています。

それから「リスク制御」としてメリハリのある品質制御ですね。開発コストのうち40％といわれている品質制御のコスト、これをどこに振り向けるか。どの部分の品質が大事かを、仕様書を書いている段階から頭に入れる、これは非常に大事です。

正当性、性能、信頼性などを定量化する手段が、あと10年ぐらいするとうまく機能するようになるのではないでしょうか。そしてテストと開発プロセスが融合したようなものが登場するのではないでしょうか。そう期待しています。

西氏　製品の多品種、大規模化、複雑化、こうした中で「ちゃんと作る」。

昨年、日本の大手自動車メーカーがアメリカ政府に叩かれたことがありました。こうしたとき、自分たちは本当に正当な開発をしているかどうか証明できなければなりません。実証する、それが求められるようになります。ちゃんと作る、テストもちゃんとやらなくてはなりません。現在のテスト技術の延長で、それがちゃんとできるでしょうか？

「早く作る」。これからは納期を半分や3分の1、4分の1にしなければならなくなってきます。人を増やしてもこれができないことは分かっています。じゃあどうするか。今の技術の延長で、納期を半分にできますか？

今までソフトウェア産業は、非少数精鋭化を進めてきました。簡単な仕事を切り出して下請けに出して大規模開発をしよう、という考え方です。でもこれでは立ち行かないのが分かってきた。

コミュニケーションロスをなくすために少数精鋭化してスピードアップしなければならない。テストも少数精鋭化することになる。それをどうするか。

「走りながら作る」。これまではウォーターフォール的な、あらかじめ順序が決まった開発におけるテストの技術をみなさん学んできたと思うが、今はアジャイル開発のようにイテラティブに開発がなってきている。

ただ単にイテレーションに追従するだけならテストはあまり変わらないと思いますが、イテレーションの特徴を生かしたテストができるかもしれない。さらにクラウド、単にネットワークにサービスが乗るだけではなく、βサービスのままどんどんユーザーの実システムとして使ってもらい、テストもしていく。それにどう対応するのか。

さらに、ソーシャルネットワークのテストって、どうすればいいでしょう。メッセージや日記の応答時間のテストをすればいいですか？ それ以上にソーシャルネットワークの特徴である、親密なコミュニケーションが実現できているか、友達とつながっているか、といったことが実現できているかどうかを確認するためのテストって、何でしょう？

あるいは、スマートフォンの「さくさく感」って何ですか？ これから介護ロボットが登場してきたら、人を運ぶといったことだけでなく、相手をいやしてくれるような機能が備わるとき、このロボットは本当にいやしてくれるかどうかというテストって、どうやって作ればいいのでしょう？

こういうことを次の10年でやっていかなければならないと考えています。

テストプロセスは、どう洗練されていくか？

西氏　すでにテストについてはいくつかの国際規格がありますが、今テストプロセスの国際規格が決まろうとしています。ヨーロッパ主導で作っていて、難解でヘビーウェイトな規格になりそうです。海外の官庁や政府機関に製品を納入するにはこれに準拠しなければならない、などと言い出されかねない可能性があります。ですから、主にソフトウェアを開発する側の米国や日本はなんとか軽くしようとしているところです。

でも来年くらいにはたぶん発効になって、日本の業界によっては黒船扱いされるかもしれません。黒船だからやらなきゃと。

しかしその前に、自分の会社でまずテストプロセスを進化させ、きちっとやって、足りないところはこういう規格を参照して、10年かけて会社のプロセスを成熟させる。そういう動きも出てくると思います。

山浦氏　政府や標準化団体が作る規格は、遅いし抽象的で使いにくい、カスタマイズしにくいところがあります。そういうのを待つのではなく、いろんな組織が自分で作っていくのがいいでしょう。

テストのプロセスを考えると、いろんな引き出しを持っていて動的に使い分けられるのが洗練されたプロセスだと思います。

いわゆるデスマーチの状態、これだけの規模をこの人数と期間でやれと、できないのは分かっているけど、というとき、じゃあどうすればいいですかというと、スケジュールを長くするとか、要件を減らすとか、いわゆるWin/Winアプローチをとれるのがある程度洗練されたプロセスかなと思います。

あるいは、分野に特化したり多様化に対応したプロセス。インドや中国は人件費が安い。ならばテストを分けて独立した2つのチームに発注してしまおうとか、そういった引き出しを組織が持っていて、状況に応じて最適なものを使えるのが洗練したプロセスだと。

お上が規格を出してくるのでは遅いので、先に走り出しましょう。

Rollison氏　テストや品質に関する国際規格はたくさん出てきています。分野によっては、そうした堅牢なプロセスにあてはめるのが大切なところはあるでしょう。医療やNASAの宇宙開発といった分野などはそうでしょう。

一方でFacebookは世界ナンバーワンのソーシャルネットワークですが、これはいわゆるカウボーイプロセスで作られました。

本音では、テストプロセスとデベロップメントプロセスについて話すのは疲れてしまいました。これらは別個でななく、今後アジャイル開発ではデベロッパーとテスターが緊密に連係しなければならず、両者の境界はなくなっていくのではないでしょうか。

開発プロセス、テストプロセスと分けるのではなく、ソフトウェアエンジニアリングプロセスと考えるのはどうでしょうか。

（後編「ソフトウェアテストの近未来を話そう（後編）～テストプロセスには魂が必要だ JaSST'12 Tokyo」に続きます）

ソフトウェアテストシンポジウム JaSST'12 Tokyo

• マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」 JaSST'12 Tokyo
• マイクロソフトでは「開発プロセスのすべてにテスターが関与している」 JaSST'12 Tokyo
• みんなはどんなテスト技法を使っているの？ JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo
• ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（前編）～テストと開発の融合が必要 JaSST'12 Tokyo
• ソフトウェアテストの近未来を話そう（後編）～テストプロセスには魂が必要だ JaSST'12 Tokyo