ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo

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

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

ソフトウェアテストの30年前と30年後

東海大学大学院 組込み技術研究科准教授 山浦恒央氏。

私は1977年入社。約30年前となる当時と今では、ソフトウェアテストはものすごく大きく変わった。この30年を振り返り、これから30年後にどう変わるか、という予想を紹介したい。

これがソフトウェア開発技術の歴史をざっくりと示した技術マップ。

一番左は1964年。仮想記憶を使った初めてのメインフレーム用OS「OS/360」の開発。これは人類史上最初で最後の超巨大プロジェクト。当時で5000人年、だいたい1200人が4年間働いた。

これはコンピュータが大発展する礎になるのだが、プロジェクトとしては大失敗だった。このときのプロジェクトマネージャがフレデリック・P・ブルックス Jr.氏。

1968年には「ソフトウェア工学」という言葉が誕生した。まだ言葉だけだが。このころ主流はアセンブラ言語。FortranとCOBOLが登場し、サブルーチンという概念が出てきて、これを使うとソフトウェアが格好よくできると思われていた時代。そして構造化技法が浸透してきた。

その後、さっきのブルックス氏がOS/360の開発で経験したことを書いた「ソフトウェア開発の神話」（現「人月の神話」）が出版。遅れているプロジェクトに助っ人を入れるとさらに遅れる、という有名な「ブルックスの法則」などが書かれていて、強烈なインパクトを残した。

1986年には、ブルックス氏の「No silver bullets」（銀の弾丸などない）という論文が公開された。これは、たった1つのツールや開発方法論でソフトウェアの品質や生産性が急に良くなる、そんな銀の弾丸は存在しないんだよということを書いた論文。この当時、まだ「この一発で生産性が5倍になる」といった論文がたくさんあった。

当時の日本では、JRの「みどりの窓口」の予約システムなど、オンラインシステムが最先端で一世を風靡した。COBOLが最先端の言語だった。メインフレーム全盛期。メインフレームをやっているとかっこいいなあというイメージ。メインフレームの仕事をしたい、という人が多かった。

品質が最優先の時代

30年前のプログラミングの生産性は、だいたいひとり1カ月1000ステップ。アセンブラでも高級言語も同じ。これは今もほとんど変わらないので、この先30年たっても変わらないのではないかと思う。

バグ密度は1000ステップあたり10件くらい。これは私の感触の数字で、仕様のバグは入れず、ビルド以降に見つかるのバグの個数。

品質が最優先されていた時代で、品質保証部にプログラムを送ってテストしてもらい、バグがゼロになるまで開発を繰り返した。まだ古き良き時代。今はケータイとかデジカメとか、これを年末商戦まで出荷しなくては売り上げに響く、といったことになっているが。

まだメモリが非常に高価で、メモリの占有量が少ないほどいい、職人芸で１ステップでも１マイクロ秒でも短く作るのが偉いと言われていた。理解しやすい、分かりやすいプログラミングよりも優先されていた。

理解容易性と効率は永遠のテーマだと思っていて、今の組み込みプログラミングは効率の方に寄っているが、理解容易性に寄るか効率性に寄るかは時代ごとに振り子のように振れる訳ですね。

テスト技術はまだ、それぞれの部や課であみだされた方法を先輩から伝承されるという時代。プロセスという考え方は確立されていなくて、開発技法などのレベル。

テスト技法の根幹は変わっていない

これが34年前に書かれたテスト技術の本。学生にはこの本を読めと、大事なのは最初の20ページに書いてあるので立ち読みでいいから読め、と言っている。

テスト技法の根幹の部分は、ここに書かれていることからほとんど変わってないと思っている。

何が書いてあるかというと2つしかなくて、「同値分割」と「境界値分析」。

開発とテストを比べると、テストの方がずっと時間がかかる。30分もあれば書ける10000×10000の二重ループのプログラムがあったとして、このすべてをテストしようとすると1億通りのテストが必要になって非常に時間がかかる。

これをなんとかしようとするのが同値分割の考え方。

例えば「入場料は6歳以下は無料、7歳から12歳は500円、13歳から18歳は800円、19歳以上は1000円」という条件のプログラムがあったとする。

それぞれの条件から1つの値をテストしたら、あとはやらなくていい、やっちゃだめだと。そうでないとテストケースがいくらあっても足りなくなってしまう。なるほどなと、これを知ったときにはちょっとびっくりした。

そして境界値分析は、例えば以下か未満か、これを間違えるのは永遠に課題で、そういう境界をきっちりテストで叩きましょうということ。

テスト技術として、今後これの応用などはあるとしても、これより画期的な方法はないだろう、と考えている。

なぜソフトウェア開発がこれほど難しいのか

なぜこれほどソフトウェア開発が難しいのだろうか。

ブルックス氏も主張していたことだが、まず規模が大きい。今なら携帯電話のソフトウェアで1000万行。そしてソフトウェアは目に見えないので、全体像を把握しにくい。

目で見えない、手で触れないのは大きいハンディ。しかも簡単に変更できてしまう。

そしてこれが一番大きい理由だと思うが、自然界の法則が少なく、自由に作れてしまうこと。飛行機や自動車には自然界の制約があって、どう作っても同じようなものになる。しかしソフトウェアではいろんなやり方ができて、自由すぎるのはいいようでよくない。

「普通に作ればこうでしょう」という制約は、高級言語や構造化プログラミング、オブジェクト指向などによって行われ、誰が作っても同じようなものになるという縛りをつけている。

そしてソフトウェア開発には順序性がある。仕様書がないとプログラムが作れない、プログラムがなければテストができない。そのために分業がしにくい。1万人を同時に連れてきても分業ができないからだめ。

ソフトウェアは、電子製品の設計や製造よりも小説を書くのに似ていると思っている。源氏物語は今から1000年前に書かれた。当時はワープロもなかった。では、今の小説家は半分で同じような小説が書けるか？ 品質がいいものができるか？ ほとんど変わらないだろう。

ソフトウェア開発も、プログラミング言語はJavaなど高級言語になったが、生産性は1カ月約1000ステップとあまり変わっていない。プロジェクト管理技術もあまり進歩していなくて、いまだに「神話」がそのままあてはまる。

バグ密度は7〜8年前と比べると、1000ステップで4から5程度と減った感じがする。これは高級言語導入の効果ではないかと考えている。

30年後のソフトウェア開発も、生産性やバグ密度は今とあまり変わらないのではないか。ただし、同じことをやっていれば経験値は上がるので、開発プロセスやテストプロセスはじわじわと良くなっていくと思うが、どこかで頭打ちになるのではないだろうか。

後編の「ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想」へ続く。

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