Tweet

連載：.NET中心会議議事録 第5回 「あなたのチームに最適なテスト」を考える デジタルアドバンテージ　一色 政彦 2011/07/12
Page1 Page2

■パネル・ディスカッション『あなたのチームに最適な.NET開発のテスト手法』

　パネル・ディスカッションでは、「.NET開発でのテストにどのように取り組めばよいのか？ .NETアプリケーション開発で、どのようなテスト手法を採用すべきなのか？」について、テストに詳しい方々にご意見を伺った。登壇していただいたのは、下記の方々である（以下、敬称略）。

パネリスト		日本マイクロソフト 長沢 智治	（前述のため省略）
		日本アイ・ビー・エム 太田 健一郎	最初の6年間ぐらいは社内SEとしてアジャイル手法による開発を経験し、その後、4年間ほど金融系の大規模開発に携わり、主に自動テストを行っていた。7月からはDeNAに転職して、スマートフォン向けゲーム・エンジンおよびスマートフォン向けゲームの品質保証エンジニアをしている
		わんくま同盟 guicheng（ぐいちぇん）	XP（エクストリーム・プログラミング）の関係で自動テストを実践しており、CppUnit／NUnit／PhpUnitを扱ってきた
モデレータ		デジタルアドバンテージ 一色 政彦	＠IT Insider.NET編集長であり、.NET開発者中心の記事編集・執筆・企画などを行っている
登壇者のプロフィール

　以下に、その要点を個条書きにした（※筆者が特に重要だと感じた個所）。ここに書き出している以外にも注目すべき発言が多々あったので、興味がある方はぜひUstream動画を視聴してほしい。

●そもそも「テスト」とは？ 単体テストにおけるテスト指針

―― テストとは何か？ デバッグとの違いは？

guicheng「テストは品質を保証する作業であるということが大前提」

太田「その定義のほかに、テストは、仕様が満たされているかを検証したり、仕様漏れなどの欠陥を見つけたりする作業でもある。対してデバッグとは、テストで見付かった障害の原因となる欠陥を究明して、欠陥を除去する作業」

長沢「デバッグはテストではない。テストでは、『何をして、その結果、どうなったのか』というエビデンス（＝過程を含めた根拠となる情報）を蓄積することが大事。そうしておけば、後でそれを開発チームや品質保証チームで活用できる」

―― 「JaSST '11 Tokyo」というイベントでは、リー・コープランド氏が「真の“テスト”とは、テスターの頭の中で、あらゆる予測を立てながら行うものであり、決してツールの中で行うものではない」と発言した。この考えは「探索的テスト」と呼ぶらしいが、これは具体的にどういうことなのか？

太田「通常のテストでは、しっかりと対象のソフトウェアを分析し、テスト計画・テスト分析を行い、テスト設計を行う。一方の探索的テストでは、テスト担当者の知識を基にテストを行う。このように、探索的テストのメリットは、テスト・エンジニアが独自の創造性を発揮できることだ。ただし、適当にテストするわけではなく、『どのような観点で探索的テストを行い、その結果を収集して、次のテストに生かせるように分析する』など、きちんとエビデンスを取ることが重要。そうすることで、ほかのテスト・エンジニアにエビデンスを渡せるので、テストの再現性を確保できる」

―― 単体テストのコードについては、わたしの場合、すべてのメソッドやプロパティに対して単体テストを書いていない。すべて書くべきなのか？

guicheng「状況によるので一概には言えないが、ビジネス・ロジック層であれば、単純なGetter／Setterであっても100％書くべき。なぜなら、将来、内容が充実したり、変更する必要性が発生したりすることが十分起こり得るから。その場合に、あらかじめ単体テストのコードが存在するかどうかは、開発コスト面で大きな違いになる」

―― しかし、すべてに対して単体テストを書くと、パターンも膨大になることがあるので、大変に感じる。パネリストの皆さんは、実務で経験して、そういうことは感じないか？

guicheng「感じる。複数の下位モジュールを呼び出す1つの上位モジュールを作る場合、かけ算でテスト・パターンが増えるので、これに対してすべてのテストを書くのは無駄だと考えている。このようなケースでは、下位モジュールで網羅的な単体テストを実施して、上位モジュールでは下位モジュールの呼び出しのみを記述すれば十分であると考えている」

太田「クラス単体のテストと、結合テストでは、用いるテスト技法と網羅基準を変える場合がある。例えば『クラス単体では、ブラックボックスでの境界値テストとホワイトボックスのカバレッジ・テストを行い、クラス結合では、クラス間の呼び出し部分に焦点を当て、その部分を網羅したテストを行う』などのようにして、メトリクスを変えている」

●どこまでテストすれば十分なのか？ テスト完了の見極め

―― 現場では、テストの完了はどうやって見極めているのか？

guicheng「基本的にはプログラマー個人に任せているが、テスティング・フレームワークのNUnitを使った場合、関数名や関数コメントで『どういったテストを行う関数なのか』が分かるようにしている。書いたコメントを抜き出す自作スクリプトを組んでいて、それぞれの単体テストが仕様書のどれに対応するのかをマネージャーが確認している。これによりテストの漏れはチェックできる。ただし、そのテストが検証すべき項目を完全に網羅しているかは、正直、プログラマー個人の考え方に寄るところが大きい」

太田「わたしの考えも入っているが基本的にIBMでは、モジュールやライブラリ、サブシステムなどのテスト対象に対して、『どういうテスト技法を使って、どこまでテストするか』といったテストの設計方針と網羅基準を設定している。例えばメソッドやクラスのユニット・テストであれば、コード・カバレッジのステートメント・カバレッジが1つの基準になるし、引数の組み合わせのバリエーションであれば、境界値分析をして、そこから想定される全対応の基準をきちんと定義する。こういった基準の策定を行ったうえで、『スケジュールやコストの観点で完全網羅が不可能だ』と判断されたときには、組み合わせの数を全網羅にしないなど、その網羅基準を下げる。

　やはり開発者の勘に頼ると、人によりテスト・ケースが増えたり減ったりするので良くない。だから、『こういうテスト基準とテスト技法を適用すれば、この開発プロジェクトにおいて網羅性の高いテスト・ケースを実現できる』という、利害関係者全員の合意を取って、テストを実施している」

長沢「テストは必ず実施する作業にも関わらず、なぜか網羅基準のない現場があるのが不思議だ。つまり、『形式的・社交辞令的にテスト・フェイズを設けているが、テスト内容はよく分からない』という状況であるが、こういった状況を是正するためにも、テスト・エンジニアリングの手法を学ぶことが重要。欧米ではテスト技法の習得は必須だし、Visual Studioが持つテスト・ツールなどは使うのが当たり前だ。テスト・ツールでテストを効率化することで、よりクリエイティブな作業に時間を割けるようになる。ただし、テスト基準があいまいな状態でテスト・ツールを導入しても、そのテスト・ツールの使い道が分からないということになるので、あくまでテスト技法の習得が先決だ」

●ひと言

―― テストにどのように取り組むべきか？ どのようなテスト手法を採用すべきか？ また、若いテスト・エンジニアに向けてテストの意義や面白さを教えてほしい。

太田「秋山浩一氏が執筆された『ソフトウェアテスト技法ドリル―テスト設計の考え方と実際』という本の勉強会を不定期に実施しており、和気あいあいとした雰囲気でテスト初心者でも参加しやすい。この本の良いところは、テスト技術を学べるだけでなく、テスト・ツールの紹介もあること。開発者でも、テスト技法を習得して、Visual Studioなどのテスト自動化ツールを活用することで、テストの面白さを知ることができる」

guicheng「まずテスト・ツールに触ってみてほしい。NUnitなどのオープンソース・ツールを利用すれば無償でテスト環境を整備することもできる。テスト・ツールを扱えるようになったら、既存のコードに対して単体テストを書いてみる。そうすれば、これまでの手動による単体テストが不十分だったことに気付くだろう。その後は楽しいテスト・ライフが待っていると思う」

長沢「本来あるべき開発の姿・テストの姿を、ぜひ妄想してほしい。後は本やコミュニティやツールを活用しながら、自分の手を動かして学んでいってほしい。テストを学習する際には、ぜひ仲間を作ってほしい。仲間と話をしたり、教え合ったりすれば、自分1人では分からなかったことなど、さまざまなフィードバックが得られる。『本来やらなければならないことを、目をつぶってやらないまま済ませてしまったり』ということがない開発現場であるべきだ。そういった意識で、小さなことから取り組んでほしい」

■

　今後の.NET中心会議としては、UX（ユーザー・エクスペリエンス）、Windows 8、Windows Phone 7、アジャイル開発などのテーマを検討中である。実現すれば、秋ごろに開催となるので、ご期待いただきたい。

INDEX
	[連載] .NET中心会議議事録
	第5回 「あなたのチームに最適なテスト」を考える
	1．基調講演『あなたのチームに最適な.NET開発のテスト手法』
	2．パネル・ディスカッション『あなたのチームに最適な.NET開発のテスト手法』

「.NET中心会議議事録」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）