目次


developerにもテストを

第5回 ソフトウェアテストと開発のこれから

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: developerにもテストを

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:developerにもテストを

このシリーズの続きに乞うご期待。

はじめに

これまでの4回、ソフトウェアテストのスタンダード、ツールを使用したソフトウェアテスト、オープンソースツール、テスト技術者の資格試験について述べてきました。今回は、ソフトウェアテストおよび開発の今後について述べてみたいと思います。

初心に返って「ソフトウェアテスト」とは

ソフトウェアのテストについて、いろいろな人が定義を述べています。Myers が「ソフトウェアのテストの目的はバグを見つけることであり、バグの見つからないテストは失敗である」[1]と述べたことは、有名なことです。一方では、ソフトウェアテストというのは誤りの発見だけではないと言うことで、「ソフトウェアの確からしさの確信を増すことである」[2]とか「Myersの呪縛からの解放が必要である」[3]などと論じられています。現在の我々は何を目的としてソフトウェアのテストを実施しているのでしょうか。

従来、日本の製品の品質が良いことには定評がありました。しかしながら、最近の情報システムや組込システムについていろいろなトラブルが報告されていますし、そのトラブルが与える影響がますます大きくなってきています。特に、ソフトウェアが組み込まれると品質が低下するなどと酷評されてもいます。ソフトウェアの品質とハードウェアの品質では何が違うのでしょうか。ハードウェアは、設計・試作・評価を繰り返した後に、製造されます。作成された製品については、1つ1つあるいはサンプリングした製品が仕様を満たしているかどうかを検査します。また、車検に代表されるように一定期間毎に、製品の状況を確認し、すり減っているところ等を交換して、製品の品質を保っています。

一方、ソフトウェアにおいては、当初は開発時に開発者がテストを行なうというのが一般的でした。それだけでは、不十分と言うことで検査や品質評価・保証、第三者検証、などいろいろ呼び方がありますが、開発者とは異なる技術者がソフトウェアのテストを実施するようになってきています。さらに、日本製品の高品質性を保証してきたQC活動などがソフトウェア品質の確保のために検討されています。しかしながら、ハードウェアとソフトウェアの特性の違いや開発方法の違いを考慮にいれないと、全く的外れな対策になっている可能性があることを考慮に入れるべきだと思います。

また、ソフトウェアテストについて、学術的には、どのようなテストを行えば誤りを見逃すことなく発見できるかを明らかにするテスト品質の向上と、時間の掛かるテスト作業の効率化が課題として挙げられて来ました。最近ソフトウェアテストの考え方が少し変化してきて、これらの課題も見直されてきています。

ソフトウェア開発の中での位置づけ

ソフトウェア開発においてテストは、下流での工程として位置づけられてきました。しかしながら、XP (eXtrem Programing)[4] などのアジャイル開発において、テストファーストとして知られる、テストプログラムを書いてからプログラミングを行う方法が提案されました。最近では、テスト駆動開発 (TDD:Test Driven Development) として提唱されています。これは、最初にテスト設計によってテストケースを作成した後にソフトウェアを開発するというものです。また、仕様として記述したモデル段階でソフトウェアに誤りがないか確認するモデルチェッキング[5] も実際に使われ初めています。

同時に、ソフトウェアのテストによって確認したい内容がソフトウェアの仕様として求められている機能を「正しく」実現しているかということだけでなくなってきています。例えば、ソフトウェアの使い勝手が利用者を満足させるものになっているかを確認することが求められています。また、現在の仕様で想定されている以上の要求があった特に全面的にシステムが停止するのではなく一部の要求を拒否するなど「適切に」対応できるかを確認することが求められています。

このように、ソフトウェアの誤りを発見することによって仕様化・設計・プログラミングで作り込まれた誤りを発見することによってソフトウェアの信頼性を向上するというテストの役割が変化してきています。

誤りの発見から品質評価へ

ソフトウェア工学は、ソフトウェアの開発を体系化すると同時に工学的手法を取り入れようというものです。ソフトウェアテストについても、開発者や検査者の視点でこれまで多くの研究開発がなされてきました。例えば、テストで一度も実行されていないプログラムの実行文が間違っているとその誤りは発見できないということから、テスト十分性を評価する指標の1つとしてカバレッジ(被覆率)が提案されました。また、ソフトウェア開発過程での誤り発見状況を記録する(バグの成長極性)と一定の傾向があります。このバグの成長曲線を用いてバグの総数の予測やテストによって発見したバグ数の割合を求めるソフトウェア信頼性という研究が進展してきました。しかしながら、これらの指標は、あくまでソフトウェアの開発過程を評価しているものです。

コンピュータが普及し、社会基盤としてコンピュータネットワークが使用される時代になっています。また、携帯電話や自動車の制御、情報家電などコンピュータを組み込んだ機器が利用されるようになり、ソフトウェアの占める割合が大きくなって来ています。ソフトウェアの品質についても作る立場での品質だけでなく使う際の品質についても考慮されるようになってきています(ISO9126-1およびJIS X 0129-1)。[6]

ソフトウェアのテストも、ソフトウェアの誤りを発見するという観点だけでなくソフトウェアの品質について確認・評価し、品質を保証するという観点についても考慮すべきであると思います。

学術・教育との関係について

ソフトウェアテストに関する学術的な議論は、ソフトウェア工学やソフトウェア信頼性工学という分野の中で行われてきています。ソフトウェア工学が提唱されたのが1968年のNATOの国際会議です。1973年にはICRS (International Conference on Reliable Software)という国際会議が開催されています。1975 年のICRSで「ソフトウェアテストの新しい手法 (New Approch for Software Testing)」という論文で議論されていることを現在の言葉で言えば「全文被覆(全ての文をテストで少なくとも1回は実行する)だけではテストは不十分であり、全分岐被覆(全ての分岐をテストで少なくとも1回は辿る」を考えるべきである」という提案です。この論文を発端として、被覆率の計測ツールの開発や有用性の議論が行われてきました。現在では、コンパイラが自動的にこれらの被覆率を計測するコードを生成できるオプションを持つようになっています。

このように、学術の世界ではその時点の最先端で研究者が興味を持った問題について議論が行われています。それらの議論が現実のソフトウェア開発の現場で直ちに役に立つという保証はありません。また、提案されている手法を直ちに現場に適用できるという保証もありません。しかしながら、現場の問題を解決するヒントであったり、共同して問題の解決に当たることが可能あることも多いのです。さらに、開発現場における課題を研究者が解決すべき課題として提供することも現場からの提案として必要だと思います。

大学等においてソフトウェアテストに関する教育は、ソフトウェア工学あるいはソフトウェア開発の講義や演習の中で扱われています。しかしながら、教育の現場では実用的なソフトウェアを扱うことが困難であり、ソフトウェアテストの重要性をなかなか理解してもらえないというのが現状です。そのような中で前回の記事で紹介されているようにソフトウェアテスト技術者として資格認定試験(JSTQB)が始まり、技術者としてのキャリアパスが確立されようとしています。一方、ソフトウェアテストデザイン科というテスト専門の学科が創設されようとしています。

テスト技術者に求められているのは、現時点では、実際にプログラムを実行してテストを実施する能力であり、どのようなテストを行うかを決めるテストの設計能力であり、テストの計画から終了までの管理する能力です。しかしながら、上に述べたように、テストの考え方が誤りを発見するという目的から、ソフトウェアの品質を評価し保証するという目的に変わりつつあります。その中では、ソフトウェアの仕様化や設計の段階からソフトウェア品質を考慮すると同時に、確認手段としてソフトウェアテストだけでなく形式化手法やレビュー、ウォークスルーなどを適切に組み合わせる必要が生じてきます。その意味で、ソフトウェアテストの技術者としては、従来のソフトウェアテスト技術だけでなく、ソフトウェア品質とその保証技術について学んで行くことが必要になると思います。

おわりに

最近ソフトウェアテストについていろいろな試みが行われています。ソフトウェアテストに関するシンポジウム(JaSST)やソフトウェアテスト技術者資格試験(JSTQB)、ソフトウェアテストに関するいろいろな本や雑誌の出版、ソフトウェアテストについてのいろいろな雑誌での議論、などソフトウェアテストが注目を集めています。ソフトウェア開発に関与される皆さんには、是非、毎日の仕事の中で時間を見つけてこれらの活動に是非参加していただければと思っております。


ダウンロード可能なリソース


関連トピック

  • [1] G.J. Myers, et al. 長尾真他訳: ソフトウェア・テストの技法(第2版), 近代科学社. 2006/07
  • [2] 玉井哲雄, 松田茂広, 三嶋良武: ソフトウェアのテスト技法, 共立出版. 1988/01
  • [3] 西 康晴: 不具合の分析とフィードバックによるテストの設計, JaSST03予稿集. 2003/01
  • [4] Kent Beck, 長瀬嘉秀訳: XPエクストリ-ム・プログラミング入門ソフトウェア開発の究極の手法, ピアソンエデュケ-ション, 2000/12
  • [5] 産業技術総合研究所システム検証研究センター: 4日で学ぶモデル検査, 産業技術総合研究所エヌ・ティ-・エス, 2006/06
  • [6] 日本工業標準調査会

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=
ArticleID=277907
ArticleTitle=developerにもテストを: 第5回 ソフトウェアテストと開発のこれから
publish-date=12212007