チームワークの実現

  • [アーティクル]

Visual Studio 2005 Team System による開発作業の一括管理

Chris Menegay

翻訳元: Get All Your Devs in a Row with Visual Studio 2005 Team System (英語)

この記事は Visual Studio 2005 December Community Technology Preview を基に執筆されており、 ここに記載されている情報は変更されることがあります。

この記事で使用する技術: Visual Studio 2005

この記事で取り上げる話題:

  • ソフトウェア開発プロセス
  • 開発チーム全体をサポートする Team System の機能
  • ワーク アイテム トラッキング、単体テストと負荷テスト、静的コード分析、およびソース管理

目次

  1. プロジェクト メソドロジ
  2. MSF Agile
  3. チーム プロジェクトの作成
  4. プロジェクト計画とワーク アイテム
  5. プロジェクト ドキュメント
  6. アプリケーションの設計
  7. Team Foundation Source Control
  8. より優れたコードの記述
  9. マネージ コードの分析
  10. 単体テスト
  11. 負荷テスト
  12. テスタ、マニュアル テスタ、およびバグ追跡
  13. Team Build
  14. チーム サイトとレポート機能
  15. まとめ

一般に、ソフトウェア開発は難しいプロセスだと考えられています。アプリケーション開発のプロセスを改善して成果物の質と一貫性を高める方法をめぐっては、いくつもの研究が行われ、何冊もの本が執筆されています。ソフトウェアの開発に役立つ新しい優れたアイデアを考え出すのは難しくありませんが、現実にそのアイデアを取り入れて有効に実現するのは困難です。マイクロソフトは、Visual Studio 2005 Team System を足がかりに、強固なソフトウェア システム構築を目指す開発チームの支援へ向けて重要な一歩を踏み出そうとしています。

Team System は、新しいソース管理システムによって Visual Studio 2005 の機能を拡張するものです。 開発者にとって有用な単体テスト ツールやコード分析ツールも組み込まれていますが、開発者だけをターゲットとしていた従来の方針が改められ、開発チーム全体をサポートするツールが新たに搭載されています。Team System には、プロジェクト マネージャ、アーキテクト、開発者、テスタ、さらには開発マネージャをもサポートするツールが取り入れられ、開発タスクとプロセスの実装を管理する新しいワーク アイテム トラッキング システムや、開発プロセスに一定レベルの透明性をもたらす Web ポータルが組み込まれています。

この記事では、Visual Studio 2005 December Community Technology Preview (CTP) を使用して Team System の概要を説明します。 そして、開発プロジェクトの設定方法を示し、開発プロセスの開始からテストに至るまでのすべての手順を紹介します。December CTP に組み込まれているバージョンの Team System をインストールするプロセスは、最終的に出荷される製品のインストール プロセスに比べてやや難易度が高くなっています。この CTP でサポートされるのは非常に限定的な環境であり、インストールには複数のマシンまたは複数の仮想マシンが必要になります。DVD やダウンロードに含まれているインストール ガイドの記述は正確ですが、正しく動作させるためには多少の補足情報が必要になる可能性があります。これについては今回の記事では扱いませんが、Team System の機能の多くは workspaces.gotdotnet.com/TeamSystemwalkthroughprojects (英語)でウォークスルーの対象になっています。 また、筆者を含む数名が weblogs.asp.net/cmenegay (英語)、blogs.msdn.com/robcaron (英語)、blogs.msdn.com/askburton (英語)の各ブログに記事を投稿していますので、併せてご覧ください。

ページのトップへ

1. プロジェクト メソドロジ

かつての Visual Studio は開発者向けのツールに過ぎなかったため、開発プロジェクトの他のフェーズ (要件の収集、設計、テストなど) にとっては価値に乏しいものでした。これに対し、Team System のサポート範囲は開発者だけにとどまりません。Team System は、開発ライフサイクル全体をサポートし、そのライフサイクルに関わるすべての担当者をサポートする設計になっています。

Team System の最も優れた点の 1 つは、プロセスというものの理解の上に成り立っているところにあります。なんらかの型にはまったプロセスを良しとする考え方を脱し、プロセスの内容をほとんど想定せずに開発されているため、非常に柔軟性が高くなっています。Team System では、マイクロソフトが "メソドロジ テンプレート" と呼ぶひな型を使ってプロセスを定義します。独自のメソドロジを開発することも、Team System に付属するメソドロジの 1 つを使うこともできます。さらに言えば、サードパーティのメソドロジ テンプレートを取り込むことも可能です。

かつては、フォーマル プロセスの採用と実施には時間もお金もかかり過ぎるという理由で、多くの開発グループがフォーマル プロセスの導入を見送ってきました。Team System では、開発チームが日常的に使用するツールにフォーマル プロセスが組み込まれるため、従来より広い範囲ではるかに容易に取り入れられるようになります。

現在、マイクロソフトには Microsoft Solution Framework (MSF) という確立された開発プロセスがあり、現在のバージョンは 3.0 となっています。MSF は開発者の間に広まっているとは言い難く、マイクロソフト社内でさえあまり採用されていません。その原因は、使い方を習得しにくいという印象にあると考えられます。マイクロソフトは MSF をバージョン 4.0 に更新し、MSF Formal (Beta 1 Refresh での名称は MSF Complete) と MSF Agile という 2 種類のバージョンを Team System に同梱する方針で取り組んでいます。どちらのメソドロジもテンプレートとして実装され、Visual Studio に統合されています。December 2004 CTP に組み込まれているのは MSF Agile のサポートのみです。既にフォーマル プロセスを導入している組織は既存のプロセスを Team System に移行し、まだフォーマル メソドロジを導入していない組織は MSF Formal または MSF Agile のいずれかを任意に選択して使用することが予想されます。

しかしながら、開発プロセスのメンバー全員が Visual Studio を持っているとは限らず、必要性すら感じないメンバーもいると考えられます。開発者以外のニーズに応えるため、Team System の機能のうち比較的広範な需要が見込まれる機能を抜粋した Project Portal と Team Foundation Client もリリースされる予定になっています。Team Foundation Client は本質的に、Visual Studio 2005 の開発機能をすべて取り除いて Team System の機能をすべて残したバージョンという位置付けになります。したがって、この記事で扱うプロセスの大半は Team Foundation Client にも該当します。

ページのトップへ

2. MSF Agile

MSF Formal は CMMI レベル 3 に適合するよう設計されたプロセスであるのに対し、MSF Agile はより柔軟で反復性のある作りになっています。あらゆるプロジェクトに最適なプロセスというものは存在しないため、組織によっては個別の開発作業のニーズに基づいてプロセスを採用することも考えられます。MSF Agile の早期評価版は workspaces.gotdotnet.com/msfv4 (英語)からダウンロードできます。

MSF Agile では、アーキテクト、ビジネス アナリスト、開発者、プロジェクト マネージャ、およびテスタの 5 つのロールがサポートされます。プロセスおよびチーム開発に関する以降の段落は、ビジネス ユーザーとビジネス スポンサー、IT 管理部門だけでなく、この 5 種類のロールを念頭に置いて読んでください。Team System は、このようにタイプの異なる各者を惹きつける機能を備えています。

ページのトップへ

3. チーム プロジェクトの作成

ここまでの説明で Team System の全体的な目的はある程度ご理解いただけたと思いますので、ここからは、Beta 1 Refresh でポートフォリオ プロジェクトと呼ばれている概念についてひととおり説明したいと思います (後続のリリースではチーム プロジェクトという名称になる予定です)。Visual Studio 2005 December CTP のロードが完了したら、まず初めに、他のシステムまたは仮想マシン上で稼動している Team Foundation Server (TFS) に接続する必要があります。TFS は、Team System のチーム機能の多くを担うサーバー プラットフォームです。TFS で実現される機能には、新しいソース管理システム、ワーク アイテム トラッキング、チーム ポータル サイトなどがあります。

Visual Studio を TFS マシンに接続するには、[ツール] メニューの [Connect to Team Foundation Server] オプションを使用します。インストール メモを見ながら、TFS マシンへの接続に必要な手順を実行します。接続が完了すると、Team Explorer のウィンドウが表示されます。Team Explorer は TFS の内容を参照するためのビューで、SQL Server データベースの内容をわかりやすく表示するサーバー エクスプローラによく似ています。Team Explorer はすばらしいツールです。これから常時使うことになりますので、なるべく早く操作に慣れておく必要があります。

TFS への接続が完了すると、チーム プロジェクトを作成できるようになります。チーム プロジェクトは TFS の重要なメリットの 1 つで、プロジェクト関連のあらゆる成果物 (設計書、ワーク アイテム、プロジェクト計画など) に対するアクセスと作業を 1 か所に集約する機能を持ちます。チーム プロジェクトは、作業対象となる開発プロジェクトごとに 1 つ作成します。Team Explorer でチーム プロジェクトを作成するには、[New Team Project] ツール バー ボタンを使用します。このほかに、Team Explorer で TFS サーバーを右クリックして、そこからチーム プロジェクトを作成する方法もあります。既存のチーム プロジェクトを Team Explorer のウィンドウに取り込むオプションも用意されています。チーム プロジェクトの設定時には、図 1 に示すように、どのメソドロジ テンプレートを使用するかを選択する必要があります。さらに、新しいソース管理フォルダを設定したり、既存のコード ベースを分岐させるオプションもあります。ここでは MSF Agile を使用します。

図 1 新しいチーム プロジェクトの作成

図 1 新しいチーム プロジェクトの作成

チーム プロジェクトを設定すると、いくつかの処理が実行されます。重要な処理の 1 つに、Windows SharePoint Services (WSS) チーム サイトの作成があります。TFS のドキュメント管理機能の多くは、WSS との統合によってもたらされます。WSS は、TFS で利用できるコラボレーション機能も複数備えています。ブラウザを開いて http://tfsserver/sites/project にアクセスすると、TFS によって作成されたチーム サイトのホーム ページが表示されます。このサイトは WSS サイトの 1 つであり、適切な権限があれば誰でもアクセスできます。ビジネス ユーザーと管理部門がプロジェクトの進捗状況を参照して把握するうえで非常に有効です。

チーム プロジェクトを用意したら、何よりもまずプロジェクトを設定する必要があります。プロジェクトを設定するには、Team Explorer でプロジェクトを右クリックして [Team Project Settings] の [Classifications] をクリックします。この設定メニュー オプションは、セキュリティ権限やソース管理ポリシーを設定したり、プロジェクト構造を設定する場合に使用します。MSF Agile の場合、作成したプロジェクトには 3 つの反復プロセスが既定で追加されています。名前変更、削除、追加は任意に実行できます。たとえば、6 つのフェーズから成る段階的なロールアウトを、反復プロセスとして設定することができます。後でワーク アイテムを作成する際に、プロジェクト全体の中でワーク アイテムを特定の反復プロセスに関連付けることができます。メソドロジ テンプレートの扱いはユーザー側に委ねられていますので、プロセスに縛られることのないようにしてください。

ページのトップへ

4. プロジェクト計画とワーク アイテム

プロジェクト管理の観点から見た Team System の重要なメリットの 1 つに、ワーク アイテム トラッキングという機能があります。開発者の興味を引くのは単体テスト、高度なソース管理、コード分析などの機能ですが、プロジェクト マネージャ、ビジネス関係者や IT 管理者が特に関心を抱くのはワーク アイテム トラッキングの機能です。ワーク アイテム トラッキングは、その名が表すとおりの処理を実行する機能です。ソフトウェア開発プロセスに必要な個々のタスクをワーク アイテムとして扱うことができます。これには、ドキュメント化の作業、設計作業、開発作業、バグ、要件が含まれます。ここまで読んだところで、ワーク アイテムをタスクとして管理するだけなら自分は既に Microsoft Project や Excel で実行していると思われた方もいるかもしれませんが、実際には各ツールでタスクを作成するのみで、追跡や管理は行っていないケースが大多数を占めます。

現在の追跡プロセスを思い浮かべながら、以下の質問の答えを考えてみてください。設計書は完成していますか? 特定の開発者に割り当てられているタスクの数がわかりますか? どのタスクが完了していますか? 最も進捗が遅れているのはどのタスクですか? タスクが予定どおりに終わらなかった場合、スケジュールにはどのような影響がありますか? これらの質問に答える能力のある組織は多数あるとしても、答えを出すためには、プロジェクト マネージャとチームの残りのメンバー (開発者、ビジネス アナリスト、テスタなど) との間で多大なコミュニケーションが必要になります。プロジェクトの進捗状況を正確に見極めるため、プロジェクト マネージャはそれぞれの担当者と話す必要があります。通常、タスクの進捗状況は、プロジェクト進捗会議や個別の会話、または電子メールを通じて管理します。このようなデータ収集、追跡、レポートのプロセスを合理化することが、Team System の目標の 1 つになっています。

使用するメソドロジ テンプレートを選択すると (前述のとおり、ここでは MSF Agile を選択しました)、いくつかのタスク (ワーク アイテム) が自動的に作成されます。この処理が実行されるのは、MSF Agile プロセスで実行する必要のあるプロセスがいくつか存在するためです。MSF Agile でチーム プロジェクトを設定した際に作成されたワーク アイテムの例を図 2 に示します。

図 2 MSF Agile のワーク アイテム

図 2 MSF Agile のワーク アイテム

ワーク アイテムは、担当者への割り当てが可能という点で Microsoft Project のタスクに非常によく似ています。ワーク アイテムには、ステータスと期間があります。担当者は、自分に割り当てられたワーク アイテムの処理を終えた時点で該当するワーク アイテムのステータスを変更し、そのステータスを WSS チーム サイトに反映させることができます。WSS サイトには、SQL Server Reporting Services を利用して、TFS によって SQL Server に保存されたデータを基に各種レポートを表示する機能があります。ユーザー独自のレポートを作成する機能もあり、それをカスタム Web パーツによって SharePoint に統合することもできます。ただし、これらのレポートは December 2004 CTP には組み込まれていませんのでご注意ください。

ページのトップへ

5. プロジェクト ドキュメント

MSF Agile のアプローチに基づいてプロセスの第 1 段階で実行する作業の 1 つに、ドキュメントの作成開始があります。プロセスの段階に応じて、ビジネス ケース、シナリオ、さらにはプロジェクト計画など、各種のドキュメントを作成します。作成するドキュメントは、メソドロジによって異なります。これらのドキュメントを Team System のコンテキストで作成するには、Team Explorer を使用します (チーム ポータル サイトを通じて作成することもできます)。[Documents] ノードにドリル ダウンして右クリックすると、[Add a Document] というメニューが表示されます。Team System では、プロジェクトに使用するメソドロジをユーザーが指定した時点で、そのプロジェクトの各種ドキュメント用のテンプレートが設定されるようになっています。[Add a Document] をクリックすると、追加するドキュメントの種類をそれらのテンプレートの中から選択するよう求めるメッセージが表示されます。テンプレートには、デザイン、ライフサイクル、計画、プロジェクト管理、要件シナリオ、および機能に関するオプションがあります。テンプレートを選択したら、適切なツール (Microsoft Word や Excel など) でドキュメントを編集します。

作成したドキュメントは、プロジェクトのホストとなっている WSS サイトに保存されます。これにより、同じ組織内の人々は、該当するサイトに移動するだけでそのドキュメントにアクセスできるようになります。ポータル サイトに直接追加されたドキュメントは Team Explorer に表示されます。新しく追加されたドキュメントを Team Explorer に表示するには、[Document] ノードを右クリックして [Refresh] をクリックします。

プロジェクト マネージャは、どこかの時点で実際のプロジェクト計画を作成する必要があります。Team System を使用すると、プロジェクトの作成は実におもしろい作業になります。もちろんそれはプロジェクト計画の作成やタスクの追跡をおもしろいと感じられればの話ですが、 少なくともプロジェクトの管理ははるかに容易になります。それだけでも私にとっては画期的です。

Team System では、プロジェクト計画を非常に簡単なプロセスで作成できます。Team Explorer からプロジェクト計画を作成するには、[Documents] の [Project Management] に移動して右クリックします。コンテキスト メニューに、Microsoft Project のプロジェクト計画の作成に関するオプションが表示されます。Team System では、Excel スプレッドシートでのプロジェクト タスクの管理もサポートされており、これと同様の方法でプロジェクト タスク用のスプレッドシートを作成できます。

Team System の真価は、Microsoft Project や Excel との関係にあります。Microsoft Project または Excel がインストールされているコンピュータに Visual Studio 2005 December CTP をインストールすると、各アプリケーションにいくつか新しい機能が追加されます。具体的には、[Work Items] メニューと、Team Foundation Server にアクセスするための新しいツール バーが表示されるようになります。重要なのは、プロジェクト計画のタスクを Team System のワーク アイテムと同期する機能です。

プロセスは、プロジェクト計画を作成し、チーム プロジェクト作成の一環として作成されたオリジナルのワーク アイテムをインポートするところから始まります。続いて、新たなタスクの追加と割り当てを行い、プロジェクト計画のタスクと Team System のワーク アイテム データベースを同期させます。開発者がタスクを処理してコードをソース管理にチェックインする際、ワーク アイテムのステータスは Visual Studio 内から更新できます。ワーク アイテムのステータス データは、チーム ポータル サイトでワーク アイテム レポートを通じて参照できます。プロジェクト マネージャは、プロジェクト計画をワーク アイテム データベースと同期させることによって情報を最新の状態に保ち、最新のステータスを取得することができます。

図 3 は、Microsoft Project に Team System のワーク アイテムをインポートし、プロジェクト タスクとして使用している状態を表しています。ご覧のように、Team Foundation Server にアクセスするための新しいツール バーが表示されています。この統合は、Project だけでなく Excel でも利用できます。これは、プロジェクト タスクを Project ではなく Excel で管理したいというユーザーからのフィードバックに基づいて追加された機能です。

図 3 Microsoft Project へのワーク アイテムのインポート

図 3 Microsoft Project へのワーク アイテムのインポート

プロジェクト計画の準備が整ったら、Team System と同期して、プロジェクト チームのメンバーが自分に割り当てられたタスクを確認できるようにする必要があります。開発者にとってすばらしいのは、Visual Studio を離れることなくワーク アイテムのリストを受け取れる点です。Team Explorer で [Work Items] に移動し、[My Work Item] または [My Active Work Items] を開くだけで操作は完了です。この合理的なアプローチのおかげで開発者にはほとんど負担がかからず、プロジェクト マネージャと開発者のミーティングの回数も従来より少なく抑えることができます。

ページのトップへ

6. アプリケーションの設計

開発者の観点から見ると、開発タスクのワーク アイテムが割り当てられた時点で、アプリケーションの設計とコードの記述を開始できる状態になります。プロジェクト計画においては、アプリケーションの設計フェーズのタスクが実際に 1 つ以上存在するのが理想です。"コードの記述" の前に "設計" を挙げているのはそのような理由からです。Team System には優れた設計ツールが複数付属していますので、それを使わない手はありません。デザイナについてはここでは説明しませんが、MSDN Magazine の 2004年 7 月号に掲載された Brian A. Randell 氏と Rockford Lhotka 氏の記事、「Bridge the Gap Between Development and Operations with Whitehorse」(英語)に詳しい情報がありますので、そちらを参照してください。

ページのトップへ

7. Team Foundation Source Control

設計またはコードの作成を始める前に、Team Foundation Source Control を使用してソース管理を設定します。かつては "Hatteras" というコード ネームで呼ばれていた Team Foundation Source Control は、Microsoft Visual SourceSafe をはるかにしのぐ強固なプラットフォームです。この新しいソース管理システムに保存した内容はすべて自動的に SQL Server 2005 データベースにバックアップされ、簡単に管理できます。この新しいソース管理システムの設計にあたっては高度なスケーラビリティとパフォーマンスの実現が目標となっていますが、この 2 つは Visual SourceSafe には欠けていたものです。新しいソース管理システムには、より強力な分岐とマージの機能が組み込まれます。このため、複数ユーザーによる同一ファイルのチェックアウトが既定でオンになります。

"シェルビング" と呼ばれる新しい機能も用意されています。この機能を使用すると、チェックアウトして作業しているコードを、プライマリ ブランチにチェックインせずにソース管理にチェックインできるため、開発者は不完全な変更をチームの他の開発者に強いることなく適切に作業をバックアップすることができます。

Visual SourceSafe も引き続きサポートされ、Visual Studio 2005 との連動のため更新される予定です。小規模のプロジェクトでチームの人数が少ないケースでは、Team Foundation Server のパワーは必要とされず、インストールに余計な手間と時間をかけるのが望ましくない場合も考えられます。Visual SourceSafe はそのような場合に役立ちます。使用するソース管理エンジンを選択するには、Visual Studio を起動して [ツール] メニューの [オプション] をクリックし、[ソース管理] のオプションを選択します。

Team Foundation Source Control を使用するよう設定すると、Visual Studio で新しいプロジェクトを作成する際に、そのプロジェクトをソース管理に追加するかどうかを選択するオプションが表示されるようになります。その時点で、使用する Team Foundation Server を選択します。開発者は、タスクの処理中にワーク アイテムをマークすることで、ソース管理へチェックインするコードにワーク アイテムを関連付けることができます。この関連付けはデータベースに保存され、レポートの作成時に使用できます。また、新しいソース管理システムはチェックイン ポリシーの作成にも対応しています。チェックイン ポリシーは、ソース管理リポジトリにチェックインできるコードを制限する手段として使用できます。

ページのトップへ

8. より優れたコードの記述

Visual Studio 2005 Team System では、より優れたコードの記述を支援するツールが IDE に組み込まれます。これには、作成中のアプリケーションに潜在するパフォーマンス上の問題を分析するプロファイラや、マネージ コードとアンマネージ コード用のコード分析ツール、コード カバレッジ分析機能を備えた単体テスト ツールなどがあります。コード分析ツールのベースになっているのはマイクロソフトで以前から使用されていたテクノロジですが、Visual Studio とこれほどうまく統合されたのは今回が初めてです。ネイティブ コードの分析には PREfast が使用され、マネージ コードの分析には FxCop が使用されます。単体テスト ツールは、NUnit などのツールに用意されているものと非常によく似ていますが、使いやすさの点で上回っており、より短時間でテストを作成できます。このため、単体テストがはるかに実行しやすくなります。単体テストは、コード カバレッジとの統合性にも優れています。コード カバレッジは、本質的には、単体テストで実際に実行されたコードの割合を示すレポート メカニズムです。

ページのトップへ

9. マネージ コードの分析

FxCop を使い慣れた方であれば、Team System のコード分析機能は難なく使用できます。この機能は、IDE との統合性に優れています。コード分析を有効にするには、プロジェクトのプロパティを表示して [Code Analysis] タブに移動します。このタブでは、コード分析を有効にするだけでなく、実行するルールも選択できます。コード分析に付属しているルールは非常に厳格であるため、大多数の組織はそのいくつかを無効にすると想定されます。既存のアプリケーションに対して FxCop を実行してみると、自分がいかにルールに則していないかということを思い知らされます。

コード分析を IDE に統合することで得られる大きな利点は、コード分析をオンにしておけば、アプリケーションのコンパイル時にコード分析が自動的に実行され、ビルド プロセスの中で警告やエラーが表示される点です。リリース ビルドの際はコード分析をオンにし、デバッグ ビルドの際はオフにするという便利な機能もあります。規模の大きいプロジェクトほどコード分析の所要時間は長くなることは認識しておいてください。もう 1 つの便利な機能として、ソース管理のチェックイン ポリシーとしてコード分析を実行するオプションがあります。このオプションを使用すると、開発者が FxCop の検証ルールに適合していないコードをソース管理リポジトリにチェックインするのを防ぐことができます。チェックイン ポリシーには、コードをチェックインできるようにするオーバーライド メカニズムが付いていますが、オーバーライドした場合はログに記録されるように設定することができます。

ページのトップへ

10. 単体テスト

単体テストの背後にある一般概念は、アプリケーションのコードを切り分けて部分的に実行し、思いどおりの結果が得られるかどうかを確認するというものです。これは通常、さまざまな入力制御を伴うメソッドを呼び出して、返されるデータをテストすることを意味します。一切ツールを使用しなくても簡単に実行できる処理ですが、生産性を上げるにはなんらかのサポートが必要です。従来、単体テストに関しては、テストの作成、テストの編成、テストが成功したかどうかのレポートを簡単な操作で作成するメカニズムの導入などが課題になっていました。Team System はこれらの問題にすべて対処しています。

Team System は、メソッドの単体テストを自動的に作成する機能を備えています。単体テスト コードと通常のコードは属性で区別されます。テストをテスト リストに編成するツールと、それらのテスト リストに基づいてテストを実行するツールが、いずれも IDE 内に用意されています。テストの実行時、結果は Visual Studio の [Test Results] ウィンドウに表示されます。

単体テストをプロジェクトに実装するには、図 4 に示すように、コード内で右クリックして [Create Tests] をクリックします。どのオブジェクトのどのメソッドについてテストを作成するかを選択するよう求めるメッセージが表示されます。複数の異なるクラスからメソッドを選択して、一度に複数のテストを作成することもできます。自動的に生成されるテストには、テスト対象のメソッドを含むオブジェクトをインスタンス化し、メソッド パラメータの変数を宣言し、最後にテスト対象のメソッドを呼び出すコードが入っています。既定の設定では、返される結果は Inconclusive になります。この設定は、テストの作成時に [Configuration] タブで変更できます。Inconclusive は、テストが成功したかどうかが不明であることを意味します。このようになっているのは、テストになんらかのロジックを実際に組み込む必要がある点に注意を促すためです。以下のメソッドをテストする場合を例に考えてみましょう。

図 4 単体テストの作成

図 4 単体テストの作成

Public Class Math
  Public Function Add(ByVal Value1 As Integer, _
    ByVal Value2 As Integer) As Integer
    Return Value1 + Value2
  End Function
End Class

この例の Add メソッドでは、単純に 2 つの整数を足した結果が返されます。 最初に単体テストを作成した時点では、生成されたテスト コードは図 5 のようになっています。

図 5 生成されたテスト コード

''' <summary>
''' AddTest is a test case for Public Function Add(As 
''' Integer, As Integer)
''' </summary>
<TestMethod()> Public Sub AddTest()
  Dim target As NewOrderEntry.Math = New NewOrderEntry.Math

  ' TODO: Initialize to an appropriate value
  Dim Value1 As Integer
  ' TODO: Initialize to an appropriate value
  Dim Value2 As Integer

  Dim expected As Integer
  Dim actual As Integer

  actual = target.Add(Value1, Value2)
  Assert.AreEqual(expected, actual)

  Assert.Inconclusive("Verify the correctness of this test method.")
End Sub

テストを実行するには、プロジェクトをコンパイルしてから Test Manager のウィンドウを開く必要があります。Test Manager は [Test] メニューの [Windows] の下にあります。Test Manager では、さまざまなテストを参照して、どのテストを使用するかを選択することができます。また、さまざまなテスト リストを作成し、そこにテストを追加することもできます。たとえば、ビジネス ロジックまたはデータ アクセス コードを実行するためのテストをそれぞれ 1 つのグループにまとめたり、アプリケーション内の機能領域別にグループ分けすることができます。

テストの実行にあたっては、いくつかのオプションを選択できます。注目すべきオプションの 1 つに、コード カバレッジをオンにするオプションがあります。コード カバレッジをオンにしておくと、単体テストでどのコードが実行されたかを表すデータを取得して分析することができます。コード カバレッジ オプションは、テスト実行設定の一種です。Test Manager のツール バーにある [Edit Test Run Configuration] ボタンをクリックすると、テストの実行に関して設定可能な一連のオプションを選択および編集できます。テストの実行後は、テスト結果 (図 6 を参照) とコード カバレッジ結果 (図 7 を参照) の 2 つを確認する必要があります。

図 6 テスト結果

図 6 テスト結果

図 7 コード カバレッジ結果

図 7 コード カバレッジ結果

[Test Results] ウィンドウを見ると、1 つのテストが Inconclusive であったことがわかります。これは、生成されたテストに対し、有用な処理を実行するための変更を一切加えなかったためです。テストは、図 8 に示すような内容に変更する必要があります。

図 8 のコードでは、2 つのパラメータ値に 2 つの整数を割り当て、Add メソッドの戻り値が想定どおりになっているかを確認しています。Add メソッドの戻り値が想定どおりの 42 であればテストは成功、42 以外であれば失敗です。また、データ駆動型の単体テストを作成することも可能です。データ駆動型の単体テストでは、ハードコーディングされた値ではなく、データベースの実際のデータを使用できます。

図 8 修正したテスト コード

''' <summary>
''' AddTest is a test case for Public Function Add(As Integer, 
''' As Integer)
''' </summary>
<TestMethod()> Public Sub AddTest()
  Dim target As NewOrderEntry.Math = New NewOrderEntry.Math

  Dim Value1 As Integer = 32
  Dim Value2 As Integer = 10

  Dim expected As Integer = 42
  Dim actual As Integer

  actual = target.Add(Value1, Value2)
  Assert.AreEqual(expected, actual)
End Sub

単体テストは、対象となるコードを正確に実行するように記述されて初めて有効に機能します。1000 行のコードのうち 10 行しか実行しない単体テストは、コードの優良性を正確に表すものとは言えません。Team System のコード カバレッジ機能は、単体テストが既存のコードの大部分をカバーしているかどうかを確認するうえで重要なリソースです。逆に、使用することのない削除可能なコードがあるかどうかを確認することもできます。

[Code Coverage Results] ビューでは、付加的にソース コードのカラー コーディングをオンにすることもできます。図 9 は 2 つのコード片を表しています。赤で示されているコードは単体テストで実行されなかったコード、緑は実行されたコードです。

図 9 コード カバレッジ ソース強調表示

図 9 コード カバレッジ ソース強調表示

テスト結果とコード カバレッジ結果は、Team Foundation Server に発行できます。発行されたデータは、Team Foundation Server によってデータベースに保存されます。これにより、ポータル サイトに表示されるレポートでこのデータを使用し、テストとコード品質の観点から見たプロジェクトの現況を確認できるようになります。

ページのトップへ

11. 負荷テスト

単体テストに加え、Team System は Web 負荷テストの作成、管理、実行の機能も備えています。この機能は従来の Application Center Test の機能によく似ていますが、堅牢性とスケーラビリティの高さ、そして Visual Studio に完全に統合されているという点で、Application Center Test をはるかに上回っています。独自のテストをゼロから作成することも、Web ブラウザのセッション情報を記録しておいて 1 台または複数のマシン上で再生することも可能です。負荷テスト ツールには、便利な機能が複数組み込まれています。ASP.NET の ViewState を適切に処理する機能だけでなく、ASP.NET のフォーム認証を処理する機能を備えている点は、特に注目に値します。

負荷テスト機能を使用する最も簡単な方法は、新しい Test Project を作成することです。これは、今回新たにソリューションに追加できるようになったプロジェクトの種類です。作成した Test Project には、ソリューション エクスプローラでプロジェクトを右クリックして [新しい項目の追加] をクリックすることにより、新しいテストを複数追加できます。Web 負荷テストの記録方法は簡単で、プロジェクトに適切な種類のテストを追加して [Record] をクリックするだけで記録プロセスが開始されます。新しく追加したテストは Test Manager のウィンドウに単体テストと共に表示されるため、プロジェクトのさまざまなテストを一括して参照することができます。Web テストは Visual Studio 2005 の負荷テストとは別物です。Web テストは Web アプリケーションの特定部分を実行するスクリプトであり、負荷テストは負荷をシミュレートするためのデータ (シミュレートするユーザー数など) を含んだ別個のテストです。したがって、まず Web テストを作成し、それを負荷テストで Web アプリケーションにストレスを加えるために使用することになります。

ページのトップへ

12. テスタ、マニュアル テスタ、およびバグ追跡

Team System には、Web アプリケーションの単体テストと負荷テストの機能はありますが、Web 以外のユーザー インターフェイスをテストする自動化されたメカニズムはありません (ただし、Compuware 社は同社の TestPartner 製品との統合によってリッチ クライアントのユーザー インターフェイスのテスト機能を提供すると発表しています)。QA チームをサポートする機能としては、組み込みのテスト管理ツールとバグ追跡システムが用意されています。バグは単なるワーク アイテムの一種として Team System に入力され、処理すべきタスクとして該当者に割り当てられます。バグのステータスとバグの数は、プロジェクトのポータル サイトから参照できるようになっています。

もう 1 つの優れた機能は、特定のプロジェクトに対応するさまざまなマニュアル テストを保存して管理する機能です。システムをマニュアルでテストする場合は、実行に必要な手順を詳細化するために、さまざまな Word ドキュメントやマニュアル スクリプトを作成するのが一般的です。Team System では、これらのスクリプトをマニュアル テストとして TFS に保存し、Web テストや単体テストと共に管理することができます。保存するスクリプトは、実際の Word ドキュメントの場合もあれば、プレーン テキストの場合もあります。これらのテストを Visual Studio の内部から実行する機能もあります。

マニュアル テストを実行するよう選択すると、テスタがマニュアル プロセスをひととおり実行してテストを成功または失敗とマークするまで、そのテストのステータスは Pending になります。言うまでもなく、テストが失敗した場合はバグが入力されることになります。マニュアル テストをテスト リストでグループ化し、優れた編成機能を利用することもできます。テストが TFS上にあることから、バグを再現するために同じ手順を繰り返す必要のある開発者も、該当するテストに容易にアクセスできます。これらの新しいツールを使用すると、テスタと開発者が同じ環境で作業できるようになり、両者の連携が深まります。

ページのトップへ

13. Team Build

Visual Studio 2005 付属のツールキットには、もう 1 つ、Team Build というツールがあります。Team Build には MSBuild が使用されています。MSBuild は、.NET Framework 2.0 に組み込まれる新しい拡張ビルド エンジンです。Team Build では、ビルド サーバーの概念がサポートされます。このビルド サーバーに対するネットワーク要求により、Team Foundation Source Control に保存されているビルド スクリプトを使用してアプリケーションをビルドするよう指示することができます。ビルド スクリプトは、Visual Studio からウィザードで各種のビルド オプションを選択することによって生成できます。ビルド プロセスの一環として FxCop または単体テストを実行するよう指定するオプションもあります。また、ワーク アイテムを更新し、通知を送信することもできます。たとえば、夜間のビルド プロセスでアプリケーションを自動的にコンパイルし、単体テストと静的分析を実行したうえで新しいビルドをテスト サーバーに保存して、新しいビルドが利用可能になったことをテスタに通知することも可能です。

ページのトップへ

14. チーム サイトとレポート機能

Team System には、開発者向けの機能とは別に、開発プロセスには直接関係しない担当者向けの重要な参照機能があり、注目に値します。この機能は、マネージャ、プロジェクト マネージャ、テスタ、ビジネス ユーザー、アナリストをはじめとして、開発プロジェクトの進捗状況に関心のあるすべての関係者に資するものです。テスタとプロジェクト マネージャは Team Foundation Client を使って Team Foundation Server にアクセスすることも考えられますが、ビジネス ユーザーや IT 管理部門が Team Foundation Client を利用するという想定は現実的ではありません。

プロジェクトの SharePoint ホーム ページは、このような担当者に最適なツールです。 このサイトからプロジェクトの現在の進捗状況にアクセスし、バグの数や重大度を確認し、プロジェクトのドキュメントにアクセスすることができます。さらに、未処理のワーク アイテムのレポート、未処理のバグのレポート、テスト結果など、多種多様なレポートも利用できます。このような参照機能の強化により、従来に比べて開発プロセスの状況をはるかに的確に把握できるようになるはずです。

話を締めくくる前に、拡張性についても一言触れておく必要があるでしょう。既存の開発プロセスが定着している組織向けに、Team System はカスタマイズに対応できる設計になっています。また、サードパーティ各社による統合と拡張も念頭に置いて設計されています。Borland 社は既に、同社の要求管理ツールである CaliberRM の新バージョンとして、Team System との統合に対応したバージョンをリリースすると発表しています。これにより、マイクロソフトの製品スイートが補完されることになります。Team System では満たされないニーズがある場合でも、Team System と統合して拡張するツールの中に適切なツールがないかどうか探してみてください。

ページのトップへ

15. まとめ

Visual Studio 2005 Team System の購入方法は、現在の Visual Studio の購入方法とは異なります。ベータ ビルドは正式リリースで利用できるようになる各種製品と正確に対応しているわけではないため、この区別を明確にしておきたいと思います。最も注目すべき点は、Team Foundation が別売のサーバー製品になることです。機能のウォークスルーは既にいくつか用意されており、ベータ サイクルの間にさらにリリースされる予定です。開発作業の "プロセス化" を進める方法をお探しなら、Team System がニーズに合っているかどうか検討してみることをお勧めします。詳細については、Team System の製品サイト (Visual Studio 2005 Team System) を参照してください。

Chris Menegay 氏は Notion Solutions の創設者であり、首席コンサルタントでもあります。Notion Solutions は、テキサス州ダラスを本拠とし、マイクロソフトのテクノロジを専門にトレーニング事業とコンサルティング事業を展開している会社です。Chris Menegay 氏の連絡先については、weblogs.asp.net/cmenegay (英語)を参照してください。

この記事は、MSDN マガジン - 2005 年 4 月号からの翻訳です。 .

ページのトップへ