連載：VB研公開ゼミ議事録 第3回　実践！ .NETで変わるVB業務アプリ開発 デジタルアドバンテージ　遠藤 孝信 2007/08/03
Page1 Page2 Page3

テスト・ツールを使っている場合のバグ管理

【会場】テスト自体の話ではないのですが、テスト・ツールを使っている場合のバグ管理はどうしていますか？ Excelなどでバグ管理をされているところが多いようですが、もし便利なツールなどがあれば教えてください。

【小井土】：Subversionには「trac」というオープンソースのバグトラッキング・システムとリンクが取れるようになっています。残念ながらわたしは使っていませんが。

　簡単な方法としては、バグとテスト・コードがひも付けできればよいので、Excelなどでバグ番号を管理しながら、テスト・コードにもバグ番号を付けておくということでもよいと思います。特に再現テスト用のテスト・コードを書く場合には、この方法は単純でよいと思います。

【小川】お話を伺っていると、小井土さん自身はあまり本格的なバグトラッキングに重要性を感じておられないような……。

【小井土】もちろん重要性は感じていますよ（笑）。

【小川】いや、バグがたくさん出ること自体の方が問題なのかなと。

【小井土】確かにプロジェクトによっては、テスト駆動開発などをフルにやっているとバグ自体が非常に少ない場合がありますね。ですので、テストをすごくたくさん書いている場合などでは、バグトラッキングの手法も変えなくてはいけないということはあります。そのへんはプロジェクトの規模などでも変わってきますが。実際、非常にバグの数が少ないプロジェクトの事例をXPユーザーグループ内での事例発表などで聞いたことがありますし、わたし自身にもそういう経験はあります。

【小川】ちなみにアバナードさんではどうされていますか？

Visual Studio Team Systemで開発プロジェクトはこう変わる

【西崎】われわれの場合、マイクロソフトとの関連からVSTSの最上位バージョンと、そのサーバとなるTeam Foundation Serverを使って、Visual Studioの中ですべての問題管理や変更管理を行うのが基本です。

　ただ、わたしたちがシステム・インテグレータとしてお客さまのところに入って開発を行う場合、製品のライセンス購入などが難しいときには、Excelでの運用もあります。また場合によっては、Excelすら入っていなくて、障害報告やその結果を紙に手で書いて運用しているといったところもあります。

　しかし全体の運用は例えば紙であったとしても、最終的な出力にだけ紙を使い、自分のチーム内では先ほどのtracなどを導入して、変更やバグ管理はきちん同期させて行えるという運用は可能と思いますし、実際に現在そのようにしている案件もあります。

テスト・コード自体のメンテナンス

【会場】テスト駆動開発を行っていると、要件の変更が発生したときにはテストも変更しなくてはなりませんが、それにかかるコストのために、テストを置き去りにして開発を進めてしまったという経験があります。テストを始める時点で気を付けなくてはいけないこと、そしてテストの粒度に関して、何か方針となるようなアドバイスはありますか？

【小井土】なかなか難しい質問ですが、実際にテストをどんどん作っていくようになると、非常にたくさんのテストを作ってしまうし、また作りたくなります。NUnitなどではテストのグルーピングができるので、テストを作るときにある程度粒度で分けておくことが必要です。そして、テストを捨てるタイミングを作ることが実は大切です。テストがどんどん増えてしまうと、変更要求が出たときにたくさんのテストに手を入れなくてはならなくなるので、本当はある程度プロジェクトが進んだ段階で、いらないテストやほかのテストで満足できるテストは整理していくことができると非常によいですね。

　アジャイル開発で著名なマーティン・ファウラー氏などは、1回のテストの実行は15分以内で完了することというルール付けをしています。テストにはそういった制限を設けて、その中に収まらないテストに関してはデイリーに落としたり、デイリーだったのをウイークリーに落としたりというふうに実施の頻度を落としていき、最終的にはウイークリーやマンスリーになったら、いらないということで削ってしまうなど、テストのライフサイクルを再度計画し直します。

.NET Tools：テスト駆動開発ツール最前線（後編）− Mockオブジェクトを使ったNUnit 2.2によるテスト −

　また、テストを15分以内に完了できるようにするためには、Mockオブジェクトなどを導入してテストのスピードを上げなくてはいけなくなってきます。ただ、Mockオブジェクトを入れてテストをすると依存関係の場所がどんどん狭くなるので、広範囲にわたるテストではなくて、部分的でかつ的確なテストが必要とされます。

　以上が一般論ですが、作ったテストをばっさり削ることにはなかなか勇気がいります。わたしの知り合いのところでは、個々のテストに関する重要度をメンバーで評価するようにしているところがあります。テストの評価をWikiなどで簡単に行えるようにしておいて、いつもやらなくてはならないテストと、やらなくてよさそうなテストを日々評価できるようにします。正直いって、これを急にやろうとするとハードルは高いと思いますが、そういうやり方もあるということです。

使っているツールの数

【遠藤】最後にお聞きしますが、.NETで開発するときにツールはいくつほど使われているのですか？

【小井土】最近はオープンソースのツールの使用は禁止というプロジェクトもけっこうあるのですが、過去にインストールしたことのあるツールは30〜40ぐらいでしょうか。

【遠藤】1つのプロジェクトで30のツールを？ それはデモしていただいたNUnitやNAntなどですよね？

特集：Windows PowerShellレビュー 特集：MSBuild完全攻略

【小井土】いや、プロジェクト全体で使っているというわけではなく、その数は個人的なものです。プロジェクトとしては、10個くらいは使っていると思います。ほかにも例えばPowerShellを使ったりMSBuildを使ったりです。けっこうマイクロソフトから出ているフリーのツールもたくさんあり、マイクロソフトのツールであればOKということがよくありますので。先ほど紹介のあったマイクロソフトのSandcastleなども比較的よく使っています。

　すべてのツールを常時使うというわけではないですが、何か問題が起きたときの解決には使います。そういう意味では20〜30は使うかもしれません。また、自分でもアドイン・ツールなどを作ることもあります。常にプロジェクトに必要なツールを柔軟に取り入れるというスタンスで仕事に取り組んでいます。

【遠藤】アバナードさんもそれくらいの数を使っておられるのですか？

【西崎】われわれの場合は先ほどもお話ししたように、Visual Studioをはじめとしてマイクロソフトから出ている製品はほぼ全員がライセンスを持っているというかなり恵まれた環境におり、VSTSには単体テストの機能も入っていたりするので、外部ツールの利用はあまり多くはないのですが、Subversionなどは活用しています。

【小川】分かりました。皆さん、本日はどうもありがとうございました。

■

　VB6と.NETの開発環境では、ツールの整備具合に雲泥の差があるようだ。そして今回のディスカッションで登場したようなツールは、開発者が開発のために作ったツールであるため使い勝手も良く、また多くの開発者に利用されているため品質も高い。導入に際しては技術面以外でのハードルも少なくないようだが、これらのツールは基本的にフリーであり（もちろんVSTSは別だが）、取りあえず個人で試してみても損はないだろう。

　なお本稿ではページの都合で割愛させていただいたが、パネル・ディスカッションではツールやアジャイル開発に関する議論もさることながら、VB6→.NETの移行に関しての議論や質問も多く出た。やはり既存のVB6のソースをどう扱えばよいのか悩んでいる開発者はまだまだ多いようだ。本稿が移行を進めるうえでの手助けの1つにでもなれば幸いである。

INDEX
	VB研公開ゼミ議事録
	第3回　実践！ .NETで変わるVB業務アプリ開発
	1．VB6でもツールの利用は可能か／移行時のツール活用／UIの単体テストについて
	2．非機能要件のテスト／アジャイルを社内展開／ツールで保守性アップ
	3．ツールを使う際のバグ管理／テストのメンテナンス／使っているツールの数

　

「VB研公開ゼミ議事録」

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