ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo

先週、1月25日と26日に都内で行われたソフトウェアテストに関するシンポジウム「ソフトウェアテストシンポジウム JaSST'12 Tokyo」。2日目の招待講演では、ソフトウェアテストの過去を振り返り、将来を展望する非常に興味深い話を、東海大学大学院 山浦恒央准教授が行いました。

講演の内容をダイジェストとして紹介します。

（この記事は「ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo」の続きです）

ソフトウェア製品の品質のレベル分けが行われる

30年後のソフトウェア開発技術とテスト技術について。予想というか、こうなってほしいという期待を交えた話をしようと思う。次の4つがその予想だ。

まず、各ソフトウェア製品がどの程度の品質を備えているのか、品質のレベル分けがされるだろう、そうなってほしい。

例えば電気製品には「JIS」マーク、食べ物には「JAS」があり、なんらかの規格に基づいて表示されている。なんでソフトウェアにはないのか？ みなさんが一生懸命に品質制御しても、今はそれを示す表示がない。

投資の世界では、債券や国債にAAAなどの格付けがあり、投資家はリスクを選べる。安いけど品質は悪い、あるいは品質が高いものなど、格付けによって品質は無料ではないことが分かる。

これだけソフトウェアの利用範囲が広がると、その不具合によって刑事責任が問われたり、人命や環境に影響を及ぼす、といったことが起きる。そのとき、最低限ここまでテストしました、それ以上やろうとすると10万年かけても終わりませんといった、賠償責任や社会的責任に対応してちゃんとテストしたかどうかが大きな争点になる。これはきっと起きる。

そのとき格付けがあれば、ここまでやったからあとは責任はとれません、といった理由付けになるのではないか。

ソフトウェアを発注するときも、格付けCCCで基本機能が動けばいいので安く早くでいいから、とか、1億円払うからAAAで品質をきっちり上げてくれ、といったことが言われるようになり、これによって品質にはお金がかかることを発注側も認識してくれるのではないだろうかと期待している。

では具体的にはどうやってレベル分けするか。CMMIを参考にしている。

「レベル1」は、なにもテストしていない、正常ケースも動作しない可能性がある。
「レベル2」では、正常系はすべてやるが、異常系は代表的なケースのみテストする。
「レベル3」では、正常系、異常系どちらもすべてテストする。
「レベル4」では、正常系、異常系はすべて、組み合わせ系も代表的なケースをテスト。
「レベル5」になると、過負荷テストで最小メモリ構成のハードウェアや、最大接続数のテスト、長時間の負荷テストなど、これらはなかなか手間がかかるのですが、それをちゃんとやると。

こういうテストの証拠をちゃんと残して、うちのソフトウェアは「レベル4」ですとか、そういうのがでてくるのではないかと予想している。

分野別の品質情報データベースの確立

これだけコンピュータの応用分野が広がると、すべての分野で品質制御を一般化した普遍的な方法はもう無理だろう。

例えばデジカメとケータイでは常連のバグが違うはず。このバグは常連だから必ずテストする、といったデータベースが分野別にできていく。そのデータを自社製品向けにカスタマイズして応用し、品質制御のレベルを上げる、という方向に向かうのではないか。

リスク管理をベースにした品質制御プロセスの確立

例えばケータイ電話や複写機、この中のプログラムは1000万行を超えている。小説で例えれば1000冊の分量をデバッグしなければならない。全部をテストしようとしても無理で、とても時間が足りない。

とすると、機能に優先度をつけ、それにあわせてテスト資源をアサインしよう、となる。

日本だとだいたい開発予算の40％がテストにかかるコスト。じっくりテストをする時間的余裕はない。やみくもにテストの手を抜くのではなく、機能に優先度をつけ、システム破壊や環境破壊を引き起こすような重大な不良のテストを重点的にするなど、エンジニアリング的に手を抜くことが重要だ。

限られたテストの資源を、リスクベースで割り当てる制御プロセスが増えるだろう。

品質のカプセル化

オブジェクト指向でよく言われるのが、「カプセル化」と「情報隠蔽」。これをもう一歩進めて、品質もカプセル化しましょうと。

大規模なソフトウェアでは、機能の再利用が大事になっているが、それだけでなく品質も再利用することが大事になってくる。

今までは、どうやって大量のテストを効率よく実施するかが課題だったが、いかにテストしないで済ませるか、にパラダイムを変えないと、これからの超巨大プロジェクトはできないのではないか、と考えている。

いかに作らないか、いかにテストしないか

開発の基本思想として、これからは「いかに作らないで済ますか」に向かう。テストの基本思想も、いかにテストをしないで済ませるか、に進まなければならない。この鍵になるのが「再利用」と「オブジェクト指向」。

再利用がうまくいくには、3つのポイントがある。「応用分野が同じこと」これは絶対条件、デジカメと銀行のオンラインシステムのような、分野が違うソフトウェアの再利用はうまくいかないと思う。

「改造量が20％以下」、理想は5％以下だが、元のコードが半分しか使えないとなると、おそらく最初から作った方が早い。

最大の課題は、再利用時にソースコードを見て「ここを改良すればいいのか」ということが簡単に理解できること。ただし私の主張は、理解しなくても、そっくりそのまま使える方がいい。これが品質の再利用につながる。

構造化プログラミングは、ソフトウェア危機を解決すると期待された。しかし、ソフトウェアの再利用はまだ簡単ではなく、例えばグローバル変数などがまだ使われていた。

これを解決するために登場したのがオブジェクト指向だと私は思っている。オブジェクト指向によって機能やデータを隠してしまえる。これと一緒に品質も隠してしまう。そうするとテストしなくても済む。オブジェクト指向で再利用と品質を扱うようになるのではないか。

こういう方式をとらないと、大規模ソフトウェア開発はうまくいかないだろう。こうしたことを、期待を込めたこれからの予想としたい。

ソフトウェアテストシンポジウム 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