---

September 2012

Volume 27 Number 09

Visual Studio 2012 - Microsoft Test Manager 2012 の新機能

Micheal Learned | September 2012

今回は、Microsoft Test Manager 2012 (MTM) の新機能をいくつか紹介します。紹介するのは、Visual Studio ALM Rangers が社内テストに使用している機能です。

いつものように、ALM Rangers は、不足している機能に対処し、導入を妨げるものを取り除き、実社会の経験に基づいたベスト プラクティスとガイダンスを提供しながら、Visual Studio 製品グループ、Microsoft サービス、および Microsoft Most Valuable Professional (MVP) コミュニティの間での連携を高める専門家グループです。

それでは、MTM 2012 のさまざまな機能を紹介していきます。

探索的テスト: 「アドホック テスト」と呼ばれることもあります。このテストは、「スクリプトを定めずにソフトウェア テストを実行すること」と定義されます。つまり、テスト管理者の創造性に頼って表面的なバグを見つけるという考え方で、テストの実行やテスト シナリオごとにステップ バイ ステップのテスト ケースをスクリプトにして作成する方法と対極にある考え方です。2010 年にリリースされた MTM の最初のバージョンでは、Microsoft テスト ランナーを使って「調査用バグ」を記録することで、探索的テストを実現していました。このツールでは、ユーザーがスクリプトを作成していないワークフローで一連の操作を実行でき、バグが見つかったら、テスト担当者がそのバグを記録します。そのとき、記録するバグに、適切な数の手順に絞った操作を含めることができました。

これは、テスト担当者がバグを記録する前にかなりの時間を費やしてアプリケーションを調査し、特定のシナリオのコンテキストの知識を基に、そのバグを自由に再現できる手順を絞り込んでいく機能をテスト担当者に提供するという考え方です。この機能により、テスト担当者は、スクリプトを作成していないワークフローで自由にテストを実行しても、正確な再現手順でバグを発生させることができました。また、これらの手順からテスト ケースを作成し、スクリプトにしたテスト ケースを再実行することでバグが解決されたこと検証することも可能でした。

MTM 2012 のリリースでは、この探索的テストのエクスペリエンスが大幅に強化されています。以前のリリースでは、調査用バグを記録するには、まず Microsoft テスト ランナーからテスト ケースを実行する必要があり、ユーザーは "ダミー" のテスト ケース (例として "Exploring" という名前にします) を作成するか、いくつかの既存のテスト ケースを応用することになります。どちらの方法もやや面倒で、探索的テスト機能のすばらしさがいくぶんわかりにくくなっていたようです。MTM 2012 では、探索的テストを行うのにテスト ケースが必要なくなり、探索的テストのセッションを開始する方法がいくつか用意されています。探索的テストを開始するには、テスト計画内のテスト スイートを右クリックして、[探索] をクリックするだけです。また、探索的テストの作業を要件に関連付けることもできるため、見つかったバグとテスト ケースを、要件の作業項目にリンクできます。これを行うには、バックログ項目から MTM 2012 の探索セッションを開始します (図 1 参照)。

図 1 MTM を使用した探索的テストの手順

テスト担当者は、探索的テスト セッションの実行中に、スクリーンショット形式、コメント形式、および添付ファイル形式でバグに関する追加データを作成できます。図 2 に示している探索的テスト ウィンドウでは、優れたエクスペリエンスがテスト担当者に提供されます。アイコンが大きいのでバグやテスト ケースを作成しやすく、自由形式のフィールドでメモの入力や書式設定が可能です。入力したメモ (およびテスト担当者がキャプチャしたスクリーンショットなどのすべてのデータ) は、バグやテスト ケースの作成時にシームレスに追加できます。ユーザーは、記録操作中にキャプチャした手順を変えて、手順の追加や削除を行うこともできます。

図 2 MTM での探索的テスト セッション

探索的テスト セッションから新しいバグとテスト ケースを作成するのが一般的なワークフローですが、既存の手動テスト ケースとバグを開いて更新することも可能です。

MTM 2012 における探索的テストのシナリオ: MTM 2012 の探索的テストのユーザー エクスペリエンスは高速かつ滑らかです。テスト担当者はテストの一時停止や再開が可能なため、ユーザー エクスペリエンス全体に非常に高い柔軟性があります。多くの組織でソフトウェア アプリをサポートするために使用される 1 つのシナリオは、顧客からの電話対応です。サポート エージェントは、このシナリオでエンド ユーザーのアプリケーションを段階的に検証し、バグの再現を試みることがよくあります。サポート担当者は、多くの場合、メモをとったりスクリーンショットを撮ったりして、そのバグを開発者に送ります。理論的には、MTM 2012 の探索的テスト機能によって、エンドユーザーの電話中にサポート担当者が探索的テスト セッションを利用してアプリを検証し、豊富な情報を添えた実用的なバグを開発チームに効率良く提供することが可能です。電話のサポート担当者は、電話を切るとテスト セッションを終了し、次の電話を受けると新しいセッションを開始します。

多くの場合、製品の責任者は、アプリケーションまたはアプリケーションの新機能をリリースする前に徹底的にテストして、バグを含むアプリケーションをリリースしないことを望んでいます。探索的テストを活用すれば、スクリプトにしたテスト ケースをシナリオごとに作成するオーバヘッドを取り除くことができます。テスト グループは、アプリケーションの調査に時間をかけ、見つかったバグとテスト ケースを記録できます。この自由形式のテストによって、定義済みのテスト作業に伴う多くのオーバーヘッドを減らすことが可能です。

単なる一時的なリソースの問題のため、定義済みのテストケースのオーバーヘッドを伴わないアプリケーション テストを望むのも、よくあるシナリオの 1 つです。

パフォーマンスの強化: これは新しいいリリースの大きな目標で、製品チームはこの分野に数多くの取り組みを行っています。テスト計画への接続、スイート内でのテストの表示、Microsoft テスト ランナーの起動、作業項目の保存、ラボ環境の構築など、あらゆる面が強化されています。加えて、添付ファイルについての Visual Studio Team Foundation Server プロキシ サポートが実現されているため、MTM 2012 と TFS プロキシを使用するチームは、ソース管理操作と同様のパフォーマンスのメリットが得られるようになります。具体的には、添付ファイルがプロキシ サーバーでキャッシュされるため、添付ファイルの各利用者は TFS から添付ファイルがダウンロードされるのを待機する必要がなくなります。ほかにも、細かな時間の節約になるものとして、完全な一覧を処理しなくてもユーザーを選択できる「直前に使用」リストの追加があります。また、それぞれ別の列から選択するのではなく、構成の一覧を 1 つ表示してその中から選択できるようになるため、構成の割り当ても容易になります。

テスト ケース エディターの強化: わかりにくいのですが、テスト ステップのグリッド (図 3 参照) が全面的に作り直されています。以前は修正プログラムや Feature Pack で使用可能だった機能が、製品に既定で組み込まれています。テスト ステップのグリッドでは、リッチ テキストや複数のテスト ステップがサポートされるのに加えて、Microsoft Excel や Microsoft Word からのコピーと貼り付け (複数のステップやリッチ テキストを含む) もサポートされます。また、画面上部に表示されるテスト ケース フィールドの周囲のフレームが取り除かれ、テスト ステップのグリッドと画面下部のパラメーター領域との間にスプリッターが用意され、画面領域が整理されています。

テスト ケース エディターの強化

新しいイテレーション用に他の計画にテスト スイートを複製: MTM ユーザーからよく寄せられた質問は、「トレーサビリティを損なうことなくテスト計画をコピーするにはどうすればよいか」というものです。MTM の 2010 バージョンでは、テスト計画をコピーできました。ただし、新しいテスト計画は作成されましたが、新しいテスト ケースは作成されず、新しいテスト計画から既存のテスト ケースを "参照" していました。そのため、1 つのテスト計画のテスト ケースを変更すると、他の計画のテスト ケースも変更されることになりました。絶対的なトレーサビリティを必要とするチームにとって、これは望ましい動作ではありません。こうしたチームが必要な動作を実現するには、サードパーティ製のユーティリティを使用するか、いくつかの低レベルな TFS API プログラミングに頼るしかありませんでした。

テスト計画の複製は、現在、TCM.exe (テスト ケース管理のコマンド ライン ツール) の機能の 1 つになっています。テスト計画を複製すると、テスト ケース、共有ステップ、テスト スイート、割り当てたテスト担当者、構成、操作の記録、リンク、添付ファイル、およびテスト構成も複製されます。テストの設定、テストの結果、およびテストの実行は複製されず、要件を基盤とするスイートも複製されません。元の要件を複製して新しいテスト ケースに関連付けたり、新しいテスト ケースを以前の要件に関連付けたりする操作は手動で行います。

複製操作は、Visual Studio コマンド プロンプト内で TCM.exe によって実行します。コレクション、複製元のスイートと複製先のスイート、および複製先の新しいテスト計画用の値を指定する必要があります。必要に応じて、overridefieldname パラメーターと overridefieldvalue パラメーターを使用して新しい区分パスやイテレーション パスを指定したり、テスト ケースの作業項目テンプレートに追加されたカスタム テスト ケースのフィールドを使用したりすることができます。

Tcm.exe suites のコマンド形式は次のとおりです。

Tcm.exe suites /clone /collection:CollectionURL /teamproject:project /suiteid: id /destinationsuiteid: id /overridefieldname: fieldname /overridefieldvalue: fieldvalue

次のコマンド ラインを使用すると、ID 100 のスイートが ID 115 のスイートにコピーされます。

tcm.exe suites /clone /collection:http://myTFS:8080/tfs/sampleTPC /teamproject:sampleTeamProject /suiteid:100 /destinationsuiteid:115 /overridefieldname:"Iteration Path" /overridefieldvalue:"areapath\sprint 2"

チーム プロジェクト コレクションは "sampleTPC"、チーム プロジェクトは "sampleTeamProject" と名付けられます。新しいイテレーション パスは "areapath\sprint 2" になります。

注: 計画のコンテンツとして表示されているテスト スイートを強調表示し、テスト ケースの一覧の上に表示されているヘッダーで、右側のスイート名の隣にある ID を確認すると、テスト スイートの ID を確認できます。

テスト ケースの読み取り専用バージョンへのリンク: このリンクは、Microsoft テスト ランナーで提供されるようになります。また、Microsoft テスト ランナーのテストの説明を記載するフィールドでは、リッチ テキストがサポートされます (図 4 参照)。

図 4 Microsoft テスト ランナーの機能強化

ビデオ録画の強化: ビデオ レコーダーを個別にインストールする必要がなくなります。ユーザーは、必要に応じてオーディオ録音を有効にすることもできるようになります。オーディオ録音は、ビデオ レコーダーの診断データ アダプターで有効または無効にできます (図 5 参照)。

図 5 オーディオ録音を有効にする

MTM でのナビゲーション: MTM でのナビゲーションは複数の面で強化されています。図 6 に示すように、製品全体のさまざまな箇所に [リンクのコピー] ボタンが用意されています。

図 6 [リンクのコピー] ボタン

このリンクをクリックすると、URL がクリップボードにコピーされるため、表示中の項目へのハイパーリンクを他のユーザーに電子メールで送信できます。

このアドレスを含むハイパーリンクをクリックすると、MTM 2012 が起動し、(ハイパーリンクに含まれる) ID および実行 ID で識別されるテスト結果が直接表示されます。

テスト計画の選択方法も強化されています。以前のバージョンでは、一覧に多数の計画が表示されている場合、起動画面から計画を選択するのが困難な場合もありました。MTM 2012 では、長い一覧をスクロールするのではなく、計画の最初の数文字を入力すれば、計画一覧の適切な位置にすばやく移動できるようになっています。

MTM の右上隅には、ユーザーが計画一覧にジャンプできるハイパーリンクが常に表示されていました。この機能はまだ残っていますが、チーム プロジェクトへのハイパーリンクも表示されるようになります。チーム プロジェクトの選択画面へも、1 回のクリックでジャンプできます。

TFS 2010 への接続: MTM の大半の機能 (テストの計画や実行、データ収集、ラボ環境の使用など) は、MTM と TFS のバージョンが一致していなくても正常に動作します。MTM 2012 を使用する場合は、TFS 2010 SP1 と最新のソフトウェア更新プログラムをインストールする必要があります。ただし、探索的テストなどの新機能は、TFS 2010 から TFS 2012 にアップグレードしない限り機能しません。

レポート: MTM には、追跡してテストの効率性を測定するための多種多様なレポートが用意されています。このレポートは、合格するテスト ケース、失敗するテスト ケース、またはブロックされるテスト ケースを把握するのに役立ちます。MTM 2012 では、[Plan] (計画) タブで結果を確認できます。結果の表示には 1 つのオプションがあり、このオプションを利用するとテスト計画の結果をわかりやすく表示できます。結果は、結果を確認するテスト構成やテスト スイートを基に表示することが可能です。また、テスト担当者を基に結果を表示することもできます。[Plan] (計画) タブに結果を表示するには、[Results] (結果) リンクをクリックします (図 7 参照)。これで、前回のテスト実行の結果が表示されます。

図 7 テスト計画の結果

TFS のストレージにかかる負荷を減らすテスト データの削減: MTM 2010 では、自動テスト実行の結果を TFS 2010 に発行する際、既定で全テスト実行の配置項目とバイナリがアップロードされます。この配置項目とバイナリは、テストを再実行してエラーを分析するのに後で使用されます。この方法では、TFS データベース ストレージに関する大きなオーバーヘッドと、テスト結果を開いているクライアント側でのパフォーマンスの問題が生じます。MTM 2012 の既定では、TFS データベースにアップロードされるのは、テスト結果のファイルとデータ コレクターの添付ファイルだけです。コード カバレッジまたはテストの影響分析が有効になっている場合にのみ、バイナリが TFS 2012 にアップロードされます。これらのバイナリは、コード分析に必要になります。

Microsoft テスト ランナーを起動しない MTM でのテスト ケース結果のマーキング: MTM 2010 では、複数のテスト ケースを合格または失敗としてマークする方法は用意されていません。テスト担当者が設定できるのは 1 つのテスト ケースの状態だけで、これは Microsoft テスト ランナーのウィンドウで行う必要があり、面倒な作業です。MTM 2012 では、テスト担当者は、[テスト] タブの [テストの実行] ウィンドウから直接テスト ケースを合格、失敗、またはブロックとしてマークすることができます。また、1 つのテスト ケースまたは複数のテスト ケースに合格したテスト、失敗したテスト、またはブロックされたテストをマークしたり、テストをアクティブ状態にリセットしたりするオプションも用意されています (図 8 参照)。

図 8 MTM でのテスト ケース結果のマーキング

Windows ストア アプリケーションの手動テスト: MTM 2012 では、Window ストア アプリの手動テストの効率を向上できます。MTM 2012 を使用すると、リモートの Windows 8 デバイス (タブレットや Windows 8 PC など) で実行している Windows ストア アプリケーションをテストできます。テスト ステップをリモートの Windows 8 デバイスで実行しながら、ローカル コンピューターの MTM 2012 でそのテスト ステップを合格または失敗としてマークできます。MTM 2012 では、動作に関するビデオや、テキストと画像による説明を添えた充実した操作ログを生成できます。この操作ログは、リモート デバイスで実行した操作をステップ バイ ステップ方式で示すものです。

Windows ストア アプリケーションの手動テストは 3 つの手順で実行します。まず、Microsoft Test Tools Adapter サービスで構成されるリモート デバッガーをインストールします。次に MTM 2012 を使用してリモート デバイスに接続し、最後に MTM 2012 のテスト ケースを実行します。

Windows ストア アプリケーションをテストする前に、Microsoft Test Tools Adapter サービスが有効になっていることを確認します。サービスを有効にしたら、MTM 2012 で、テスト スイートが格納されているテスト計画に接続します。テスト センターで、[テストの実行に使用する方法] の隣にある [変更] リンクをクリックして、手動テストを実行するリモート デバイスを指定します (図 9 参照)。[リモート デバイス] オプションを選択し、テストするデバイスの名前または IP アドレスを入力します。[テスト] をクリックして接続をテストし、変更を保存します。

図 9 Windows ストア アプリケーションの手動テスト

接続が確立されたら、手動テスト ケースを実行できます。Microsoft テスト ランナーに、[Start Test] (テストの開始) と [Install Application] (アプリケーションのインストール) のどちらかのオプションが表示された [手動テストの実行に使用する方法] ダイアログ ボックスが表示されます。[Install Application] (アプリケーションのインストール) オプションをクリックすると、ファイルのコピー、証明書のインストール、およびアプリのインストールという 3 手順のプロセスで、Windows ストア アプリが Windows 8 デバイスにリモート インストールされます。[Start Test] (テストの開始) オプションをクリックすると、合格または失敗をマークするために使用する MTM のウィンドウにテスト ステップが表示されます。リモート コンピューターでテスト ステップを実行する間、ユーザーは、バグのスクリーンショットを撮ったりバグを記録したりすることができます。

Windows ストア アプリの操作ログの強化: MTM 2012 では、Windows ストア アプリケーションや Internet Explorer 10 で実行した操作に関してテキストや画像による説明を添えた、充実した操作ログを生成できます。操作ログのファイルには、テスト実行中に実行した各操作手順のスクリーンショットが含まれます。ファイルは .html ファイルとして保存されるため、ブラウザーで表示できます。画像の操作ログのサムネイルをポイントすると、実行した操作の画像が全画面表示されます (図 10 参照)。強化された操作ログにより、バグを簡単に再現できるようになります。ユーザーは、テスト担当者が実行した手順を正確に確認することができます。Microsoft テスト ランナーまたは探索的テストのウィンドウからバグが送信されると、このようなログが表示されます。

図 10 Windows ストア アプリの操作ログの強化 (出典: Visual Studio ALM + Team Foundation Server Blog (Visual Studio ALM + Team Foundation Server のブログ、bit.ly/NV0Eru、英語)

特に、ソリューションやソリューションのテストに関する品質水準の向上を担当している方は、MTM 2012 のこうした機能やその他多くの機能をぜひ調べてみてください。

Sudheer Adimulam は、Microsoft Services Global Delivery のテスト コンサルタントで、Visual Studio ALM Ranger として活躍しています。彼はコンピューター アプリケーションの修士号を取得しており、ISTQB、CSQA、MCSD、および MCTS の資格を持っています。

Micheal Learned は、マイクロソフトのプレミア フィールド エンジニアリング部門の開発者で、Visual Studio ALM Ranger として活躍しています。彼は、.NET Framework 開発やアプリケーション ライフサイクル管理によるマイクロソフトの顧客のサポートを担当しています。彼のブログは tfsmentor.com (英語) です。Twitter のアカウントは twitter.com/mlhoop (英語) です。

Tim Star は、Intertech Inc の主任コンサルタントで、トレーニング、コンサルティング、Visual Studio ALM を担当しています。彼は電気工学で学士号を取得していて、MCPD、MCTS、MCT、および Visual Studio ALM External Ranger の資格を持ち、MVP を三度受賞しています。

この記事のレビューに協力してくれた技術スタッフの Mathew Aniyan、Nivedita Bawa、Willy-Peter Schaub、および Charles Sterling に心より感謝いたします。