============================================================================== 分科会1 セッションB1: SWEST4 議事録 「テストを楽しもう 〜組込みソフトウェアのテストについて語ろう〜」 ============================================================================== ------------------------------------------------------------------------------ 【会場/参加者】 日時: 7/23 20:30-22:30 会場: C会場(席数 50脚程度用意) 参加者: 30-40人 テーブルを輪にして、皆が向き合う形で議論を始めた。 ------------------------------------------------------------------------------ 【司会者から】 テスト作業について - 必須なのは皆が納得するはず リスクなければテストなし - 必要悪なのか? 難解、時間、コストがかかる プログラミングとテスト - プログラミング: 生産的 - テスト: 非生産的、日陰的 完全にテストしたからといって、製品から問題はがなくならない - 製品の品質保証の最後の砦 許容できる品質を提供することがテスト ソフトの致命的なバグは誰の責任か? - テスターの責任? そのバグを発見できなかったから? - プログラマの責任? プログラムを正しく書かなかったから? プログラマとかテスターではなくシステムに関わった人すべての責任では? ------------------------------------------------------------------------------ 【ポジショントーク 1/2】 主題: 世の中のテストはどうなのか? 数年前まではテストの話なんて取り上げられていなかった。 フィンランドにて - 7ECSQ(第7回欧州ソフトウェア品質学会) - 3WCSQ(第3回世界ソフトウェア品質学会) 3年後に重要なソフト = 組込みソフトウェア アメリカの動向 - ソフトウェアにもPL法? テロ後、セキュリティや信頼性を重要視 - Sustainable Computing Consortiumの設立 3000万ドルを出してテストの手法を模索 - NIST report 6-sigma ソフトウェアのバグで6兆円の損失(アメリカでのみ、GDB の0.6 %) ↓ ソフトウェアテストは世界的に注目されている! ヨーロッパの話題 - 品質は大事という議論が活発に ↓ 日本は品質立国で安心すると置いてかれる! ------------------------------------------------------------------------------ 【ポジショントーク 2/2】 主題:単体テストの取組 客の要望: 品質を上げる方法は? - オブジェクト指向屋は分析設計重視で、テストはおろそか。 設計をうまくしてもミスは入り込む - ミスは必ず起こる。 最後はテストで抑える必要がある テストとは? - 設計したものが意図どおりに動くか? -> 検証 - 負荷などをかけて動くかどうか? -> テスト ここでのテストは前者の検証にあたる。 設計したものが正しく動作するかを検証すること。 よくあるテストの状況と問題 - 結合テスト(実機テスト)で品質を抑えることがほとんどでは? 部品の品質は担当者任せ - しかし、それでは品質確保は難しい 実機でのテストは時間がかかる バグが多く品質が低い ↓ テストそのものの品質を高くする必要がある 対策 - システム構成部品の単体テストを実施 部品開発(設計、実装)担当者が実施 - 実装と同時にテストプログラムを作成 - 部品の仕様を踏まえて、より細かなテストが可能 部品単位でテストでき細かく抑えることができる テストコードもソースコードと同様に保守する - 部品修正時にはテストコードも修正 XPが最近流行  - XPだけでも統制のとれた開発はできるが、取り込む必要があるのはテスト。 システムテストと単体テストの比較 - システムテスト テスト対象は動作するシステム - システム構成部品の単体テスト テスト対象はコード - テストプログラムによるテストがしやすい。 ↓ 組込みシステムは周辺デバイスとのやりとりがある。 それをデスクトップ上にもってくることは、難しいけど単体テストはできる。 単体テストの見込み - 他の部品ができてない場合でもスタブを作ることでテストできるはず - 良い部品化(部品間の依存性小)ができればスタブも最小限に - 簡単なことだけでも品質向上に 本対策のアプローチ(単体テストでのアプローチ) - 単体テスト、結合テスト -> プログラマ担当 - システムテスト -> テスター担当 単体テストの戦略 - XUnit の採用 - サブシステム単位でテスト - シナリオ単位でテスト - 重要な点から先にテスト 完全なテストは不可能 テストの網の目を小さく - ブラックボックステストを基本にする 補助的にホワイトボックステストを行う 単体テスト方法 - 出力テスト サブシステムに入力を与えて、その出力をテストする - 状態遷移テスト 一連の入力に対して、正しい状態遷移が行われるかをテストする 今後の課題 - 単体テストの標準化、パターン化 - 結合テストでも回帰テストを行いたい(単体テストならばできる) - 実装前にモデルのテストを行う - テスト技術を活用できないか? ------------------------------------------------------------------------------ 【ポジショントークに対しての質問】 Q 「クラス単位でのテストが大変なので、サブシステム単位でやるとうまくい く」という話だが、経験的には、クラス単位で行なってて、それでうまく動い ている。 何かこつがあるのか? A 単体テストは必要だが、組込みは単体で動かないものが多い。複数のものが 絡み合うコントローラ的なクラスに対しての単体テストは難しい。妥協として、 工数との兼ね合いも考えて部品単位で行なった。サブシステム単位でやった方 が簡単。確かに、データ的なクラスなどはクラス単位の方がよい。 Q 現実には8割くらいが論理的なインターフェースで、残りの2割はデバイスの ような実際の物と絡んで動く。8割の部分は設計者の腕によってうまい設計で でき、提案方法で可能かもしれない。だけど、2割は絡んでいる物を良く知っ てる人でないとテストできない。この2割はどうするのか? A その2割をどうするか、という話はもちろんあると思う。特に、デバイスド ライバ部門などは、物を見ながら検証する方法しかできてない。 Q デバイスっていうのは人間の考えた通りに動作しなかったり、考えてもなかっ たなような不良品が混ざっていたりすることがある。入力と出力を突き合わせ てテストを行なうのが単体テストだが、実際の物でないと検証できない物もあ る。 A 理想としては、ハードウェアの仕様があって、それをテストツールみたいな 物に入れて机上でデバッグする。 ただしその手間は莫大だし、そういうツー ルも無いし、ハードウェアのばらつきもあるので、その部分はやってない。今 まではそういう論理的な部分も個人任せでやってたり、あるいは、テストして なかったりする。だから、まずそこからやりましょうというアプローチ。 Q テストを考えた時に、まずファーストレベルのテストとしてはソフトウェア のバグによって問題を起こさないよう、単体テスト、あるいは、部品テストな どがまず基本にあるとは思うが、その次にやっぱり、本当の物の安全性だとか を見るには、実際のものでどれだけ予想しなかったものを拾い出すか、という ことが大きいと思うのだが。 A 経験的には、組込みソフトウェアで本当に品質性がキーになっている所が 実機周りということはほとんど無く、部品レベルである。それが全部ちゃんと できたところで実機の問題がもしあるならば、指摘の通り。一方で、実機周り での問題には、実機でしか絶対に見つからないという問題があり、技術的な解 決策として、完全にハードウェアをシミュレートしようという話がある。もう 一つの問題として、自分が完全であっても相手がばらつきや不具合を持った場 合にどうしようもないという事がある。個人的に、4〜10年物のソフトウェ アの問題点は、 1. 相手がおかしいときに自分はどう付き合っていくか 2. 現場では網羅してテストする時間が無い 3. サブシステムを単位にすればテストの数は減るけれども、実際にはクラスが 組合わさることによって単体のテストの組合わせが効いてくるので網羅する数 は爆発的に増える。 Q 複雑系は単体ではシンプルなものでも、それらの多数が組合わさった途端に、 予想できないケースがでてくる。ただ単純に単体を抑えれば全体が収まるとは 思えない。 A 結合テストをやるにしても、組合せで効いてくる。少なくとも、単体を抑え なければ、全体は抑えられないのは自明。組合せを減らしていく必要がある。 Q ユビキタスコンピューティングが広がる中で、これから先、予想できないケー スが増えて来るはず。例えば、USB などは、コネクタに接続するだけで新しく て予期しないデバイスを利用できるようになる。単体を抑えると同時に全体の 中でどうやって抑えていくのかという点で、テスターの責任が大きくなってく ると思うが。 A テスター側としては、予期しないものをどれだけ予期できるかという話が一 つ。もう一つは、開発側でできるだけテストしやすいように設計してもらうと いう話がある。 ------------------------------------------------------------------------------ 【テストを楽しむには?】 個人的に、テストの楽しみには、次の3つがあると考える。 1. 実績を上げる喜び 2. バグを見つけてくれてありがとうと言われるなどの感謝への喜び 3. こうやればうまくテストができますよなどとこういう場で発表して皆に自 慢する喜び それはオープンソースの考えと近い。みんなが興味を持つ物なら自然に問題が 挙がってバグがなくなる。多くの目にさらしている。そういう点では組込み系 というのは突っ込む人が少ない。その中でどれだけ多くの目にさらすかという ことがもしできれば、非常に面白い。Linux と同じ開発体制を作れればいいん だが、オープンにできないんだから現実には無理。 ちょうど今セキュリティーの世界では、セキュリティーバグを見つけたらどう やって企業に告知して、企業が言うことを聞かない場合は何日の猶予を与えて 発表すべきかという議論が延々されていて、そういう意味では皆でよってたかっ てバグを出すという事はちょっとありえない。 バグを発表する場を当たり前の常識としてしまうとか。 例えば、年に一度のSWESTで”組み込みバグ大賞”を決定するとか。アメリカ のバグネットという会社ではバグネット大賞というものがあって、その年一番 迅速にソフトウェアのバグを直したっていうので大賞を出している。 実際、皆さんの会社ではバグを見つけた時の扱いはどうしてるのか? 例えば バグを見つけたら誇らしげに賞賛される企業がある。一方でバグを見つけられ ると徹底的にいじめられる組織もある、皆さんのところはどうなのか? それはなかなか言えないと思う。でも会社によって、というより製品による差 は大きいと思う。医療品や人の命にかかわることでは、あまり表沙汰にされな いでさっと直していくという事が多いと思う。 結局その製品の行く末。次のバージョンアップまで放っておいてもいい物だっ たら、サービスセンターにクレームがいくけどごめんなさいという感じ。要は、 その製品によって変わってくる。例えば、炊飯器でバグを見つけたら賞金を出 すとした時に果たして皆が飛びつくか? ------------------------------------------------------------------------------ 【うまくいったテスト方法】 うちのソフトウェア開発組織のテスト周りでこんなことをやってうまくいった という話があったら教えて欲しい。 以前の組織での話。「ソースコードにはバグが含まれているもので、それを見 つけるのもプログラマの仕事だ」と意識を改革しようとした。本当にいいプロ グラムを書いたならばバグは出ないが、中途半端に見つかるのはきっとデバッ グをちゃんとしていない。だから、ある割合以上のバグを出した人には賞金を 与える。本当に出なかった人にはそれはそれで評価する。中途半端な者には賞 金を与えない、としたら、バグがどんどん出た。バグはそもそもあるもので仕 方がない、隠すな。とはっきり公言することはある程度大切だと思う。 賞金システムは非常に面白いと思うが、その賞金というのが大金である場合と、 もしかしたら 50円かもしれないがそれによって会社の文化が変わってバグが でるという場合と、意味合いが変わってくると思う。 意識を変えるという意味合い。 それがずっと続く場合にはペナルティーは無かったのか? そういう設定はしてない。必ずバグは含まれるという前提なので。 そうすると最初にバグをたくさん含ませておくことができるのでは? 恵まれていたのか、そういう社員はいなかった。 プログラムを書いた人とテストする人が別の場合は話が変わってくる。別のテ スターが見つけたら賞金とか。 金銭でもプレゼントでも社長賞のようなものでも結構ですが、何かそういう取 り組みをされている組織や企業は他にありますか。やってみたいってところと かありますか。もしうまくやれれば、swest-discuss メーリングリストがあり ますので、そこに是非結果を。 ------------------------------------------------------------------------------ 【テストの戦略性】 テストの話を聞いていつも不満に思う事は、最後は結局、「勘ですね」「経験 ですね」「今までの蓄積ですね」という話になり、戦略的な話が全然聞けない。 もうちょっと高いレベルの話が聞ければ嬉しい。もちろん、勘や経験を否定す る気はないが、どうも組込み全般そういう話が多すぎる。職人さんだけで作れ るならばいいが、そういう時代ではないし、職人もそうたくさん作れるわけで はなく、そこで皆苦労している。ですから、職人さんではない、経験のない人、 勉強してない人でも問題なくできる方法が欲しい。 それが産が学に求めているもの。実際の現場でプログラミングしてる人は論理 的な思考ができない人ばかり。 でも、論理的に「こういうテストをしてどうこうしていれば」ということを言 える人は会社の中に一人か二人いて、その人達は一生懸命何かをしている場合 が多い。だから学術の方に、誰がやってもというようなことは無理だと思う。 なぜなら組込みシステムはそれぞれが細かい特性を持っていて、それを理解す るには使ってみないと分からないことが多いから。全てをテストするのはもの すごいコストで、だからリーズナブルな範囲内でできるテストが、経験とか勘 と言われていると思う。本当に論理的にきっちりできるようなシステムが作れ るのならば、それはすばらしいと思うが。 現場にいて思う事は、テストに戦略性が無い。単体テスト、結合テスト、シス テムテストっていう話があったが、製品の特性によって、その工程で何を落と すべきかを、本当は決めるべきで、それは設計者だからこそ決められる物だと 思う。テストに求める物を明確にしなくてはならないし、設計の立場から言え ば、テストしなくてはならないことっていうのは設計時に挙げれるはず。それ をしないのは物を作る設計者の怠慢だと思う。テストはやっぱり網羅性の問題 だと思う。全部を網羅する事は難しいが、論理的に押さえないといけない部分 があって、これは70%くらい。予測して、できるかぎり悪い製品は出さない。 それが競争力になる。 日本の製品の品質がいいというのは、企画や設計の品質がいいのではない。設 計に関しては、他の国と一緒かちょっといいくらい。日本は、製造の生産技術 がずば抜けている。それは製品ごとの組立てノウハウがすごい工場に貯まって いるからだと思う。ソフトというのはどうも話が設計の方ばかりにいってしまっ てて、テストではただ確認すればいいんだという意識があり、ノウハウの塊の はずなのにノウハウとして扱っていないので全然貯まらないということがある と思う。ソフトウェア技術者はテストは確認だけすればいいというレベルで思っ ているのでは? テストには戦略性が必要。 経験や勘が重要というのは絶対ある。全部をテストで品質を保証しようとする とやっぱり無理がある。無限の時間と無限の組合わせの中から、この部分だけ をやれば充分だというような効率的な部分を見つけなくてはいけない。その部 分で今のところどうしても経験や勘が効いてくる。そのピックアップを普通の 人ができるような手法について、学でやってもらいたいという話があったが、 現実には、特に組み込みのような複雑かつ実機でどうこうという話になってく ると、まだそれは経験や勘に頼って皆やっていると思う。 経験が全てというわけでは無くて、経験が無くてもあるレベルくらいまでの検 証ができるような工夫をしている。社員には限りがあるし、皆が経験を持って いるわけではないし、検証に関してはなるべく経験が少ない人間でもできるよ うなルールみたいな物は作ってやっている。それでも最終的にバグを絶対に出 さないような歯止めになるのは経験のある人間の最終的な指摘になる。ただ、 そういう過程を繰り返していって、経験を貯めてもらう必要がある。 経験は個人の資産であり、会社としては、それを伝える必要がある。 ------------------------------------------------------------------------------ 【テストの重要性】 日本の人は勉強不足だと思う。ホワイトボックスとブラックボックスしか知ら ない。例えば、「以下の4つの戦略にしたがってテストをすればよい。 User-oriented、Spec-oriented、Fault-oriented 、Design-oriented ...」と 言うと、素晴らしい考えだと言われるが、実はこれは既存の物。ちょっと調べ れば知ることができるのに、勉強していない。テストは外部仕様とソースコー ドを対象にするだけではない。例えば、アーキテクチャ上の弱点を狙った構造 中心型テストのように、アーキテクチャに注目してテストするものもある。 テストはアーキテクチャを考える時点で視野に入れる必要がある。どういう状 態で作ったのかを他の人に伝える枠組みがない。 確かに。testability (テスト容易性)が重要。テストだけではだめで、設計か ら考慮したものが必要。テストだけで考えるなら、組合せが爆発する。組合せ を抑えるには、設計をきちんとするのが正しい方法である。 テストの重要性をどう説明し、どう教育すべきか? 新人、中堅、重役。どの 立場に伝えるのも難しい。新人はまだいい。研修の際にいい課題をやらせれば、 すぐにその必要性を理解してもらえる。若い人より現場でもまれた人達をどう 説得するかは大変だと思う。何のためなのかが明確ではないので、テストの目 的を明確にする人を作らなければならないのでは? テストの重要性を伝えるには、教育、文化、キャリアパスの3つが関係すると 考えている。 教育 - 教育はどうにでもなる 文化 - 怒られる文化であればよい キャリアパス - テストをやる人は勉強する時間がなく、一生テスターどまり テスターには憧れる人はいないが、プログラマに憧れる人はいる。背景として、 プログラマには、誰でも知っている有名な成功者がいるが、テスターにはいな い。憧れる人がいないので教育カリキュラムを作ることはできない。テスター になったら名誉や金を手に入れるということができればよい。 ------------------------------------------------------------------------------ 【最後に】 私の経験から、ホワイトボックスとブラックボックスだけでテストを組むこと ができ、品質の確保もできた。経験というのは本当に必要? ただポイントを 見つける時間が短くなるだけ? それは才能があったからだと思う。テスト件数や時間を減らすのには、経験は 必要。 バグが妙にとれる人ととれない人がいるが、これはプログラムの能力には比例 していない。ある意味バグを見つける才能は存在する。 センスや感受性の問題なのかも。 皆さんの土俵が異なっているためか、議論がいろいろと発散しましたが、全体 的に底上げが必要だということが言えると思います。また、皆のテストに対す る意識を高めることも重要です。次回またこのテーマで議論ができたらと思い ます。 ==============================================================================