Visual Studio 2015
TFS による Web ベースのテスト ケース管理
Team Foundation Server (TFS) によるアプリケーション ライフサイクル管理では、ソフトウェア プロジェクトの計画、開発からテスト、配置までを統合ツールセットを利用して管理します。Team Foundation Server の中核となるテスト ハブを使用すると、任意のプラットフォームのすべての主要ブラウザーからアクセスできる使いやすい Web ベースのインターフェイスを利用して、手動テストを作成および実行できます。今回は、テストの計画と作成、関係者とのテスト レビュー、テストの実行、テスト チームの進捗状況の追跡という、手動テストの各フェーズについて詳しく取り上げます。さらに、ワークフローをカスタマイズする際の柔軟性、エンドツーエンドの追跡可能性、条件ベースのテスト選択、変更の追跡と監査、テスト ステップとテスト データの共有、関係者によるレビュー、そして最も重要なこととして、手動テストに Excel ベースのフレームワークを使用しているテスト担当者にとっての使いやすさなど、さまざまな価値を示します。テスト ハブにアクセスするには、オンプレミスの [テスト] タブに移動します。同様に、バックログを管理するには [作業] タブにアクセスし、ビルドを監視するには [ビルド] タブにアクセスします。また、無料の Visual Studio Online (VSO) アカウント (visualstudio.com) に登録して、90 日試用版のライセンスを取得し、テスト ハブを試すこともできます。
スプリント用テスト動作の計画
スプリントやイテレーションは、アジャイル手法やスクラム手法を実践するチームがテスト動作を計画する場合の単位です。ユーザーのストーリーに合わせてテスト作業を計画するように、1 つのスプリントに対してテスト作業を計画します。最初にテスト計画を作成し、その計画に名前を付けて、チームとスプリントに関連付けます。テスト計画には、ベータ リリースのサインオフやユーザー受け入れテスト サイクルなど、テスト サイクル外のテスト動作についての担当者やテスト サイクルの期日を含めることができます。TFS のテスト計画は作業項目です。そのため、作業項目の履歴を使った変更の追跡や、区分パスに基づくアクセス許可、リッチ テキストのサマリー フィールド、添付ファイルなど、作業項目のメリットをすべて活かすことができます。とは言うものの、作業項目の最も大きなメリットはカスタマイズです。作業項目をカスタマイズすると、組織が使用するビジネス プロセスに合わせて、成果物のワークフローとフィールドを追跡動作に使用することができます。この考え方を広げて、ソフトウェア開発モデルの一環として実施されるテスト動作をより適切に反映するようにテスト計画の作業項目をカスタマイズすることも可能です。テスト計画の作業項目をカスタマイズするプロセスは、バグやユーザー ストーリーなどの作業項目をカスタマイズするプロセスに似ています。たとえば、テスト計画の既定の状態を "アクティブ" や "非アクティブ" から "作成"、"テスト"、"アーカイブ" などに変更することができます。アカウンタビリティや監査の要件に必要なレビュー担当者、承認者、サインオフ担当者などのユーザー フィールドをテスト計画に追加することもできます。プロセスをテスト計画に統合するときに、チーム リーダーやテスト マネージャーなどの特定の担当者だけがテスト計画を作成および変更できるように、アクセスを制限してもかまいません。"テスト計画の管理" アクセス許可を使用すると、テスト計画へのアクセスをユーザー レベルまたはチーム レベルで管理できます。
テスト計画を用意したら、すぐにテストの作成と実行に取り掛かりがちです。しかし、その前に、テスト作業の再利用とエンドツーエンドの追跡可能性を可能にするために、テストを整理するのに最適な方法を考えておくことが重要です。テスト スイートとはテスト計画に含める成果物です。このテスト スイートを使用して、テスト ケースを論理単位にグループ化します。テスト スイートは、要件ベースのテスト スイート (RBS)、クエリ ベースのテスト スイート (QBS)、および静的テスト スイートの 3 種類に分類されます。静的テスト スイートは、RBS と QBS を整理するフォルダーのように機能します。テスト ケースを自身でグループ化する場合は、テスト ケースを手動で選択して静的テスト スイートに追加します。
テスト計画と同様、テスト スイートも作業項目です。そのため、前述のカスタマイズのメリットがすべてテスト スイートにも当てはまります。テスト スイートのカスタム フィールドとして、テスト アプリケーションをセットアップする指示を記述するサマリー フィールドや、機能や統合、テストの複雑さなどのテストの性質を記述するフィールドなどを用意できます。テスト計画と同様、"テスト スイートの管理" アクセス許可を使用して、テスト スイートへのアクセスをユーザー レベルまたはチーム レベルで管理できます。スイート、担当者、状態などのフィールドに含まれるテスト ケースへの変更は、テスト スイート作業項目の履歴で追跡できます。
要件ベースのテスト スイートによるエンドツーエンドの追跡可能性
要件ベースのテスト スイートは、チームが現在のスプリントで作業中のユーザー ストーリー (スクラムの製品バックログ項目と CMMI ベースのプロジェクトの要件) に対応します。RBS を作成する際にユーザー ストーリーを選択するのは、追跡可能性を有効にするのが目的です。RBS で作成したテスト ケースは、自動的にユーザー ストーリーにリンクされ、ユーザー ストーリーのテストを含むシナリオを簡単に見つけられるようになっています。テスト ケースの実行中にバグが報告される場合、それらのバグもユーザー ストーリーとテスト ケースにリンクされるため、ユーザー ストーリー、そのテスト シナリオ、未解決のバグのエンドツーエンドの可視性が得られます。これにより、機能の品質と出荷の準備状態を測定できます。
クエリベースのテスト スイートによる条件ベースのテスト
回帰テスト カバレッジは、新機能のテスト カバレッジと同様に重要です。チームは、通常、優先順位 1 のすべてのテスト、エンドツーエンド シナリオのすべてのテスト、すべての自動テストなどの条件に基づいて回帰テスト カバレッジをセットアップします。テスト ハブでは QBS による条件ベースのテストをサポートします。このようなテスト スイートを作成するには、テスト ケースのクエリを定義します。このクエリ条件に一致するテスト ケースが QBS に自動的に設定されるので、QBS を手動で更新する必要はありません。また、QBS は、現在のスプリントで修正中のバグに対するテスト ケースの追跡など、他のシナリオにも使用できます。
Excel に似たグリッドによるテスト ケースの作成
テスト ケースがテストの基本単位です。各テスト ケースには、実行する一連のアクションを記述したテスト ステップと、各テスト ステップでの検証内容を記述した予想結果を含めます。各テスト ステップには、必要に応じて、出力を示すスクリーンショットなどの添付ファイルを含めることもできます。テスト計画やテスト スイートと同様、テスト ケースも作業項目です。そのため、作業項目のカスタマイズのメリットがすべてテスト ケースにも当てはまります。
テスト ケースの作成方法は 2 つあります。1 つは、テスト ケース作業項目フォームを使用する方法です。このフォームでは、一度に 1 つのテスト ケースを作成できます。もう 1 つは、Excel に似たグリッドを使用する方法です (図 1 参照)。これは、テスト ケースを非常に簡単に作成する方法です。グリッドは、通常 Excel でテスト ケースを作成して手動でテストを行っているテスト担当者によく利用されています。グリッドを使えば、テスト担当者は一度に複数のテスト ケースを作成できます。タブ キー、矢印キー、Enter キーを使用してグリッドを移動しながら、テストのタイトル、ステップ、予想結果をスムーズに入力できます。行の挿入、削除、切り取り、コピー、貼り付けといったシンプルな操作が可能です。さらに、グリッドではすべてのテスト ケース フィールド (状態、タグ、オートメーションの状態など) を表示できるうえ、複数のテスト ケースに対応するフィールドを一括でマークすることができます。インターネット接続を利用できない場合や、Excel でテスト ケースを作成するのに慣れている方にお勧めです。Excel で作成したすべてのテスト ケースをコピーしてグリッドに貼り付け、保存するだけで、それらのテスト ケースをシステムに登録できます。実際、チームがテストに TFS テスト ハブを採用しているのであれば、グリッドは Excel からテスト ケースをインポートするのに便利です。Excel からインポートする場合の細かい要件については、Test Case Migrator Plus ユーティリティ (tcmimport.codeplex.com、英語) をご覧ください。
.png "Excel に似たグリッドによる複数のテストの作成")
図 1 Excel に似たグリッドによる複数のテストの作成
テスト ステップとテスト データの共有
テストのシナリオによっては、意味のあるテストを実行するために、入力として特定のテスト データが必要になることがあります。また、さまざまな異なるテスト データ (有効な入力セットと無効な入力セットや、買い物かごのさまざまな商品の組み合わせなど) を使用してテストを繰り返すことも考えられます。このような場合は、パラメーターを使用して、テスト ケースとテスト データとを関連付けます。大規模で複雑なテスト シナリオを扱う熟練のテスト チームは、多くのテスト ケースに類似のテスト データを使用してテストを実行することがよくあります。このような場合は、テスト データを統合して一元管理するために、共有パラメーターを使用します。Excel からテスト データをインポートし、共有パラメーターを使ってそのデータでテストを実行することも可能です。
テスト データと同様、テスト ステップも複数のテスト ケースに共通することがあります。たとえば、アプリケーションにログインするステップや、フォームに移動するステップなどは共通です。このような共通テスト ステップは、共有ステップに統合します。共有ステップを使用するメリットは、アプリケーション URL が更新されたり、ログイン時の認証ステップが追加された場合など、共通のステップに変更が加えられた場合に、共有ステップでその更新に対応できることです。共有パラメーターや共有ステップへの変更は、そのパラメーターやステップを参照しているすべてのテスト ケースに即座に反映されます。
関係者とのテストのレビュー
テストを実行する前に、プロダクト マネージャーやビジネス分析者といった関係者とテストを共有して、コメントを求めるようにします。開発チームやテスト チームが部門や組織をまたがる場合やテスト プロジェクトを外部委託する場合などは、テストを実施する前に正式なサインオフが必要になることがあります。レビューのために関係者とテストを共有するには、テスト計画や一連のテスト スイートを電子メールでエクスポートしたり、PDF やハード コピーに出力することもできます。電子メールでのやりとりの出力は、関係者に送信する前に編集できます。関係者にインラインのレビュー コメントを求めるときは、コピーして Word 文書に貼り付けてもかまいません。
Web ベースのテスト ランナーによるテストの実行
テストを実行するチームを準備するために、テスト リーダーはテストをチームのメンバーに割り当てることができます。テスト ケースの管理者とテスト担当者は分けてもかまわないため、テスト リーダーには、テスト担当者を入れ替えたり、ベンダーの助けを借りてテストを実行する柔軟性があります。Web ベースのテスト ランナーの機能のうち、手動テストの実行に使用される最も価値ある機能は、クロスプラットフォーム サポートです。テスト ランナーはブラウザーベースのため、主要ブラウザー (Internet Explorer、Chrome、Firefox、および Safari) をサポートするすべてのプラットフォームで実行できます。
テスト ランナーでは、テスト対象のアプリケーションのステップの読み取りと実行を容易にするため、幅の狭いウィンドウにテスト ステップと予想結果を表示します (図 2 参照)。テスト ケースの記述中に作成された画像の添付ファイルが表示され、これを拡大することもできます。テスト ケースにテスト データが割り当てられている場合は、テスト ケースに含まれるパラメーター値の各行がテストの 1 回のイテレーションに対応します。
.png "Web ベースのテスト ランナー")
図 2 Web ベースのテスト ランナー
テストは "Passed" (成功)、"Failed" (失敗)、"Blocked" (ブロック)、および "Not Applicable" (該当なし) という異なる結果になる可能性があります。ブロック状態は、テストがバグの解決などの外部依存関係を待機しているときに使用し、該当なし状態は、テストが現在の機能 (サービスのリリースなど) には当てはまらない場合に使用します。テストの各ステップを検証しながら、成功または失敗という印を付けます。失敗したステップについては、テスト中に気付いた問題についてのコメントを大まかにメモします。テスト ランナー セッションのコンテキストに合わせて、バグを作成することによって、開発者に失敗を報告します。問題が発生する前に実行したすべてのステップがそのバグに自動的に設定されます。また、バグをファイルに書き込む前に、コメントやスクリーンショットを追加することもできます。バグは、バグがファイルに書き込まれるときに実行されていたテスト ケースと、テスト対象の要件にリンクされます。そのため、エンドツーエンドの追跡可能性が実現されます。一方、予想結果とアプリケーションの動作に矛盾が生じ、アプリケーションを最近更新したことでこの矛盾が生じている場合は、テスト ケースの実行中にそのケースをインラインで修正できます。多数のテストを実行する非常に時間がかかるテスト セッションで、そのセッションを中断する必要がある場合、そのテストを一時停止して後で再開することができます。テストが失敗したときに、前回いつ成功したかや、成功したテストを実行したテスト メンバーを調べる場合は、テスト ケースの最近の結果を確認することができます。
テスト ランナーはテスト ケースの各テスト ステップを詳しく見ていくのに便利です。これに対して一括マーキング機能では一度に複数のテストの成功や失敗をマーキングすることができます。テスト ステップを実際に細かく見ていくのではなく、テスト ケースのタイトル別に整理されているテスト シナリオを大まかに検証する場合に、テスト ランナーを起動しないで各テストの結果をすばやくマーキングすることができます。一括マーキング機能は、多数のテストをオフラインで実行していて、それらのテストの状態をシステムに反映する必要がある場合に特に便利です。
グラフを使用したテスト進捗状況の追跡
「機能のリリース準備は整っているか」、「このスプリントのテストは順調に進んでいるか」、「このスプリント用に計画したすべてのテスト ケースを実行する準備は整っているか」など、テスト リーダー、テスト マネージャー、および関係者は、さまざまな疑問を抱きます。テスト ハブでは、このような疑問に回答できるさまざまなグラフを作成できるようになります (図 3 参照)。グラフは 2 種類あります。1 つは、テスト作成作業の進捗状況の追跡に使用するテスト ケースのグラフ、もう 1 つは、テスト実行作業の追跡に使用するテスト結果のグラフです。これらのグラフは、さまざまな形式 (円グラフ、縦棒グラフ、積み上げ横棒グラフ、ピボット テーブル グラフなど) で表示できます。担当者、状態、優先順位といったテスト ケースのフィールドを、テスト ケース グラフのピボットとして使用できます。テスト結果のグラフのピボットには、テスト スイート、結果、テスト担当者、実行日、優先順位などを使用します。たとえば、ユーザー ストーリーのテスト状態を確認するには、現在のスプリントのテスト対象となっているすべての要件ベースのテスト スイートについて、テスト スイートと結果を含む積み上げ横棒グラフをピボットとして作成できます。これらのグラフを一連のテスト スイートまたはテスト計画向けに作成し、テスト計画全体の情報をまとめることができます。また、グラフをホームページにピン留めして、グラフから得られる視点を関係者と共有することもできます。すべてのグラフはリアルタイムに測定結果が表示されます。時間的な遅れや処理の遅延が生じることはありません。
.png "テスト結果の追跡")
図 3 テスト結果の追跡
まとめ
テスト ハブは手動テストの担当者のみを対象にしているわけではありません。製品担当者とビジネス分析担当者がツールとして使用し、機能が受け入れ基準をどの程度満たしているかを測定することもできます。グリッドは要件の受け入れ基準を追跡するために使用でき、後でサインオフに使用できます。テスト ハブの機能を以下に要約します。
- テスト計画、テスト スイート、テスト ケースという作業項目によるワークフローのカスタマイズ
- 要件からテスト ケースやバグまでの、要件ベースのテスト スイートによるエンド ツー エンドの追跡可能性
- クエリベースのテスト スイートによる条件ベースのテストの選択
- テスト ケースを簡単に作成するための、グリッドによる Excel に似たインターフェイス
- 共有ステップと共有パラメーターによる再利用可能なテスト ステップとテスト データ
- 関係者とのレビューを目的とした、共有可能なテスト計画、テスト スイート、およびテスト ケース
- 任意のプラットフォームでのブラウザーベースのテストの実行
- テスト作業を追跡するためのリアルタイムのグラフ
テスト ハブは、スプリントでリリース予定のユーザー ストーリーをテストする簡単かつ包括的な方法を提供します。テスト ハブは、オンプレミスでは TFS で、クラウドでは Visual Studio Online で利用できます。すぐに無料の 90 日試用版 (visualstudio.com) をお試しください。実際にテスト ハブを確認するには、デモ (aka.ms/WebTCMDemo、英語) をご覧ください。
Manoj Bableshwar は、マイクロソフト Visual Studio Online チームのプログラム マネージャーです。彼のチームは、Visual Studio Online に手動テスト ツールを提供しています。
この記事のレビューに協力してくれたマイクロソフト技術スタッフの Ravi Shanker に心より感謝いたします。
Ravi Shanker は、Visual Studio Testing Tools チームの主席プログラム マネージャーです。