早期および頻繁なテスト
欠陥をできるだけ早く見つけることが、ソフトウェア品質を確保する最も低コストな方法です。Kent Beck と Cynthia Andres はこう述べています。"ソフトウェア開発にはジレンマがある。欠陥は高くつくが、それを排除するにも同じように費用がかかる。それでも、ほとんどの欠陥は対策を講じた方が安上がりである" (示すエクストリーム プログラミング: 許容の変更) は、ベスト プラクティスとツールは、チームがライフサイクルのプロジェクトの品質を維持することで問題を防ぐと固定コストを最小限に抑えることができます。
作業を進めながら欠陥を見つけ、修復し、検証すると、チームはいつでも、プロジェクトの品質をより正確に測定できます。テストを頻繁に行うことによって、チームと利害関係者は絶えずコードの最新の状態を認識でき、プロジェクトのどの段階でも十分な情報に基づいた意思決定が可能となります。結果、"リリースしても大丈夫か" という問いに対して明確な回答を示すことができるうえ、ソフトウェアのユーザーに対する影響まできちんと把握することができます。
このトピックでは、次の作業手順を推奨します。
各クラス、およびすべての主要コンポーネントの API に対する自動化された単体テスト セットを作成します。単体テストの記述には、チーム メンバーの作業時間の約 40% を要します。詳細については、「Microsoft テスト マネージャーを使用した自動テストの作成」を参照してください。
各ユーザー ストーリーのテストを作成します。自動化することをお勧めします。詳細については、「プロダクト バックログ項目、ユーザー ストーリー、または要件のためのテストの作成」を参照してください。
コードのチェックイン前に単体テストを実行することをチーム メンバーに促すチェックイン ポリシーを作成します。詳細については、「Add Check-in Policies」を参照してください。
完全なテスト セットを実行する継続的ビルドまたは夜間ビルドを設定します。
テスト カバレッジを監視して、すべてのコードがテストされていることを確認します。70% 以上のカバレッジを目指します。詳細については、「テスト ギャップ Excel レポート (アジャイル)」を参照してください。
スプリントの終わりに近づくたびに、手動テストを実行します。
Microsoft Test Manager、Visual Studio アプリケーション ライフサイクル管理 (ALM)、Visual Studio Team Foundation Server を連携させながら、チームでプロジェクトの初期にこれらのテスト アクティビティを管理および拡張することができます。詳細については、「アプリケーションのテスト」を参照してください。
このトピックの内容
テスト方針
テスト計画
受け入れテスト
単体テスト
テスト駆動開発と早期テスト
手動テストと自動テスト
テスト結果の報告
テスト方針
チームでのテストの成功は、チームの規模、テスト方式、管理ツールなど、いくつかの要因によって左右されます。アジャイル方式を使用すると、テスト結果を継続的に改善していくことができます。この方式は、きわめて限定的なリソースしかない状態でテストを始めることができ、しかも、プロジェクト中、必要に応じていつでも進め方を調整することができます。
.gif "Ee330950.collapse_all(ja-jp,VS.110).gif")
アジャイル テストを導入する際の考慮事項
既存のアプリケーションにアジャイル テストを導入するチームは、スプリント レベルとプロジェクト レベルの両方でテスト方針を考えることができます。スプリント レベルでは、現在のスプリントの各ユーザー ストーリーをカバーする一連の受け入れテストを取り入れることができます。プロジェクト レベルでは、エンド ツー エンド テスト (全体テスト) など、プロジェクト全体を対象にしたテストを設けます。複数のスプリントにまたがる機能を検証する場合にはこれが役に立ちます。スプリント中、チームがコードを作成している間に、さまざまな種類のテストを作成することができます。これらのテストには、単体テスト、受け入れテストのほか、パフォーマンス テスト、セキュリティ テスト、ユーザビリティ テストなど、機能面以外のテストも含まれます。
アジャイル テスト方式を適用するには、まずアプリケーションのこれまでの経緯と、チームが使用するシステムを考慮する必要があります。アジャイル テスト方式は、新しいアプリケーションにも、既存のアプリケーションにも適用できます。プロジェクト全体のテスト計画と、プロジェクト内の各スプリントのテスト計画は、Microsoft Test Manager を使用して作成できます。こうしたテスト計画によって、実行テストに優先順位を設けたり、テスト結果を把握したりしやすいよう、テスト ケースをテスト スイートにまとめることができます。詳細については、「プロダクト バックログ項目、ユーザー ストーリー、または要件のためのテストの作成」を参照してください。Visual Studio ALM では、いくつかの方法でテスト ケースをテスト スイートにグループ化できます。
テスト ケースの静的なグループを作成、管理する。
テスト ケースの動的な (つまり、優先度に基づいてテスト ケースを検索する) グループを作成、管理するためのクエリを使用する。
ユーザー ストーリーまたは要件をテスト計画に追加し、そこでテスト ケースを要件にリンクさせる。
別のテスト計画から既存のテスト スイートをコピーする。
詳細については、「テスト スイートを使用したテスト ケースの整理」を参照してください。
次に、コードに対するテストの容易性を考慮する必要があります。そのためには、アプリケーションのアーキテクチャとパターンを知ることが大切です。Model View Controller (MVC)、Model View ViewModel (MVVM)、Model View Presenter (MVP) などのパターンを使用すると、特定の機能を分離して、ユーザー インターフェイス テストに悪影響を及ぼすことなく機能テストを実行することができます。ただし、実際には、こうしたパターンで表すこともできないケースもあります。たとえば、アプリケーションから、リファクタリングの対象となる機能だけを切り離すことはできません。また、特定のコード領域に到達するために、どうしてもユーザー インターフェイスやネットワーク イベント ハンドラーを経由しなければならないこともあります。テスト品質を大幅に向上させるためには、テスト可能なコードの比率を高めることが重要となります。このようなパターンの詳細については、「ASP.NET Model View Controller (MVC)」を参照してください。
加えて、アジャイル テストを実際に導入する前に、あらかじめチームの能力を考慮しておく必要があります。機能を実装するときには、単体テストを作成できるチーム メンバーが何人か必要です。アプリケーションのビジネス ルールに精通し、手動ユース ケースとワークフロー テストを作成、定義できる人材も必要です。それだけではありません。これらの手動テストに基づいて、より詳細な自動化されたテストを作成できる、必要な技術的スキルを持った人材も必要となります。
テストのライフサイクルを管理する方法
テストは、プロジェクト期間全体を通じて行われる反復的なプロセスです。次の手順を参照してください。
テストの目的を明確にし、チーム全体が同意するようにする。テスト方針は、これらの目的に基づいて決定します。たとえば、方針を "すべてのチェックイン前にテストを実行し、単体テストのコード カバレッジを 70% にして、すべてのユーザー ストーリーに 1 つ以上の自動テストを用意する" のようにします。
プロジェクトのユーザー ストーリー、設計の前提条件、および機能面以外の要件に基づいて現在のスプリントのテスト計画を定義する。
- ユーザー ストーリーをバックログに追加して、今後のスプリントの計画を立てることができます。それぞれのテスト計画は、少なくとも 1 つのスプリントと対応している必要があります。つまり、スプリントのすべてのユーザー ストーリーにはテスト ケースが割り当てられていなければなりません。
テスト ケース (受け入れテスト、単体テスト、機能テスト、パフォーマンス テストなど) を定義して構築する。
テスト ケースをテスト スイートとしてグループ化する。テスト作業の指針となる定義済みのテスト計画にこれらのテスト スイートを当てはめることができます。
スプリントの期間全体を通じてテスト スイートとそこに含まれているテスト ケースを繰り返し実行する。スプリントの早期にテストを開始し、テスト スイートにテスト ケースを継続的に追加する。テストの重要な条件と状況を特定するには、探索的テストを適用し、チーム内で何度も話し合います。
ユーザー ストーリーのすべての受け入れテストに合格したことを確認してから、ユーザー ストーリーの状態を完了に設定する。
.png "反復テストの有効期間")
ソフトウェアの分割方法によっては、ワークフローはもっと複雑になる場合もありますが、前に示した図は、ワークフローの主な構成要素の本質をよく捉えています。
コードからビルドが生成される。
コードは、定義されている作業、テスト計画、およびビルドの品質の影響を受ける。
テスト計画、テスト スイート、およびテスト ケースは、計画されているゴールなど、この図には示されていない、プロジェクトのさまざまな側面から影響を受ける。
コードの変更がテスト ケースに影響を及ぼすこともある。
バグの修正
バグにはできるだけ早く対処する必要があります。重大なバグは、影響を受けるユーザー ストーリーが完了していないことを意味します。
テストまたはその他のアクティビティで見つかったバグのバグ作業項目を作成します。バグの重大度を設定して、ユーザー ストーリーに与える影響の度合いを示します。0 や 1 などのように重大度が高い場合は、重要なユーザー ストーリーが実装されていないか、またはユーザーが重要な対処法を実行してストーリーを実現する必要があることを示します。3 などのように重大度が低い場合は、ユーザーが追加の作業を行わずに引き続き主要目的を達成できることを示します。
チームの他のメンバーと一緒に各バグに対する行動計画を決定します。
修正したらすぐにバグを解決します。バグを別の検証担当者に割り当てます。できるだけ早くバグを検証して終了します。
バグの状態を追跡します。各イテレーションの終了時の振り返り会議で、バグの傾向レポートを確認し、異常な増加の理由について話し合います。詳細については、「バグの傾向レポート」を参照してください。
テスト計画
テスト計画は、チームがプロジェクトの全体像を把握するプロセスであり、また、チームがさまざまなテストを準備するプロセスでもあります。アジャイル テストはスプリント レベルから開始します。それぞれのスプリントで、チームは、そのスプリントに組み込まれたユーザー ストーリーを検証するためのテストを作成します。現在のスプリントと以前のスプリントの両方で作成されたテストを実行します。プロジェクト全体を通じて、すべての機能を対象にした多数のテストが構築されます。次の図は、プロジェクトのテスト計画のテンプレートを示しています。
.png "マスター テスト計画")
各スプリントおよびプロジェクトのテスト計画の作成
Visual Studio ALM のテスト機能を使用すると、チームは、テストの計画、編成、実行、レポートを増分的に行うことができます。テスト計画のテンプレートはチームで作成し、テスト スイートはチーム メンバーで埋めていくことが可能です。テスト計画でチームは、どこに自動テスト ケースを使用し、どこに手動テスト ケースを使用するかを見極めることができます。
テスト計画の作成は、プロジェクトのスプリントごとに着手することができます。この計画を使用することによって、現在のスプリントの対象となる機能に的を絞って検証することができます。当初、計画が空だったとしても、テスト スイートのプレースホルダーとして使用することは可能です。後日テスト ケースを適切なテスト スイートにまとめることができます。プロジェクトの利害関係者から時期を逃さずフィードバックを受けるには、これらのテスト ケースを早期に、なおかつ、スプリント期間全体を通じて作成していく必要があります。
プロジェクト全体を対象としたテスト計画を作成することもできます。プロジェクトのテスト計画を使用すると、先行するスプリントのテストを結合して、プロジェクト全体に適用するテスト スイートを編成することができます。回帰テスト スイートは継続的に実行する必要があります。大規模なプロジェクトを構築する場合、安定性と流れを維持するために重要です。特に、規模が大きく、距離的にも離れた場所で作業する分散チームの場合、後の工程に影響を残すような変更が原因のエラーを回帰テスト スイートによって捕捉することが可能です。適切な対策が設けられていないと、こうしたエラーは捕捉がきわめて難しく、サイクルの終わりに近づいたころや、納入後に発覚することも少なくありません。
プロジェクト全体にまたがるテスト計画を定義することもできます。この種のテスト計画は、複数のスプリントにわたって存在する関連する機能を検証するために用いられ、プロジェクト期間を通じて終始実行されるテスト スイートが含められます。たとえば、スプリントの境界のない複数のユーザー ストーリーにわたる機能は、その機能全体が完成して初めてテストすることができます。
スプリントの前の受け入れテストの定義
スプリントの前に受け入れテストを定義する必要があります。ユーザー ストーリーの完成は、この受け入れテストによって判断することができます。各スプリントのテスト計画に "Acceptance Tests" という名前のテスト スイートを作成すると、受け入れテスト ケースを追跡することができます。詳細については、このトピックで後述する「受け入れテスト」を参照してください。
スプリント中の単体テストの構築
スプリント中、チームは単体テストを構築する必要があります。単体テストでは、コードのパフォーマンス (コードの実行に要する時間的、リソース的コストなど) を検証することができます。その他の種類のテスト、たとえば、機能面以外のテスト (つまり、パフォーマンステストおよびセキュリティ テスト) は、構築して適切なテスト スイートに追加する必要があります。これらのテスト スイートは、そのコストを容易に識別できるように編成することが大切です。
使用頻度の高い領域へのテストの集中
ソフトウェアの変動要素がどこにあるかがわかれば、要所は特定できます。ユーザー入力、ソフトウェアの実行環境、ネットワーク、ハードウェアなどは、構成上の代表的な変動要素であり、チームはそれを基にソフトウェアの要所を見極めることができます。特定の条件がまれにしか発生しない場合や、複雑に絡み合うさまざまな条件がテスト中に発生する可能性がある場合、欠陥がもたらしうる影響が特別に大きい場合を除いて、テストの価値は小さくなります。一般に、機能はできる限り分離することが望ましいとされています。大きな影響をもたらす状況をテストすることも重要です。Microsoft Test Manager を使用して構成を管理する方法の詳細については、「テスト構成 - テスト プラットフォームの指定」を参照してください。
既存のプロジェクトの場合は、欠陥の数が最も多い部分に注目し、そのような欠陥が存在する理由を調べます。また、コード チャーンにも注目してください。根底にある前提が見落とされている可能性があります。コードに欠陥が存在する理由の 1 つに、状況 (ネットワーク、ユーザー インターフェイスなど) だけでなくコードも管理する、ということの難しさが挙げられます。
受け入れテスト
受け入れテストでは、ユーザー ストーリーを検証します。このテストによって、顧客が必要とする機能をプロジェクトのライフサイクル全体を通じて確実に構築できることに加え、顧客との信頼関係を構築し、自分が負っている責任を明確に示すことができます。詳細については、『Acceptance Test Engineering Guide (受け入れテスト エンジニアリング ガイド)』を参照してください。
受け入れテストを行う方法
Microsoft Test Manager を開き、テスト計画に "Acceptance Tests" という名前のテスト スイートを作成します。チームはスプリントごとの受け入れテストをグループ化 1 文字以上のテスト スイートが必要です。詳細については、「テスト計画の定義」を参照してください。
手動テストから自動テストへの移行
手動テストは自動テストよりも定義が簡単ですが、実行の負荷は大きくなります。したがって、手動テストから始めて、より重要なテストを徐々に自動テストに置き換えていくことをお勧めします。
まず、スプリントに対して定義されている各ユーザー ストーリーを検証するための一連の手動テスト ケースから構築します。スプリントの開始時点ではコードが存在しないため、テスト ケースでは、ユーザー ストーリーの構成要素に対応する表面的なアクションを大まかに示す必要があります。たとえば、"認証されたユーザーとして～を行う" という内容をテスト ケースの手順として用います。手動テスト ケースから始めることによって、チームは、適切な受け入れテストをスプリントの開始前にいち早く定義することができます。
スプリントに含まれるユーザー ストーリーを実装したコードが完成したら、今度は具体的にユーザーが体験することを反映するように、受け入れテストを修正して更新します。ただし、既存の受け入れテストに変更を加えることが難しい場合は、新しいテスト スイートに既存のテストをインポートし、それを土台として、より詳細なテストにしあげていくことも可能です。たとえば、先ほどのテスト ケースの手順では、"ユーザー名]ボックスに名前の型であり、また銀行口座に記録するにはログイン ボタンを選択します"。
最後に、完成した受け入れテストに基づき、操作の記録を使用しながら、コード化されたユーザー インターフェイス (UI) テストを作成します。詳細については、「既存の操作の記録からのコード化された UI テストの生成」を参照してください。機能を分離する手順を作成すると、"コード化された UI テスト" から、無駄のないコードを生成することができます。コード化された UI テストを手動テスト ケースに添付すると、テスト計画から自動テストを実行することができます (詳細については、「方法: テスト ケースに自動テストを関連付ける」を参照してください)。
自動テストの作成には、スプリントの最初に定義された手動テストを役立てることができます。手動テストは人によって実行されるものであり、自動テストも、コードまたはユーザー エクスペリエンスに変更が生じた場合は更新する必要があるため、手動テストであれ自動テストであれコストがかかるのは同じです。詳細については、このトピックの「手動テストと自動テスト」を参照してください。
受け入れテスト ケースをだれが実行するか
受け入れテスト ケースは、チーム、製品所有者、および顧客が実行できます。できるだけ頻繁に実行して、スプリントを無事通過するために必要な一連のテストの基準を確立する必要があります。製品の所有者と顧客が受け入れテストを実行したり、スプリントが無事完了したことの証明を求めたりすることもできます。
チームは Microsoft Test Manager を使用して、各受け入れテスト ケースを実行し、テスト結果のビデオ画面キャプチャを記録することができます。このようにすると、テスト結果の視覚的な記録を残し、結果を顧客と共有することもできます。マルチサーバー構成など、必要な構成を作成するのが困難な場合には、この方法を利用することができます。
受け入れテスト ケースとユーザー ストーリーの定義
承認基準はユーザー ストーリーを定義した直後に定義できます。受け入れテストを定義することによって、現在のスプリントに製品所有者および顧客が求めている承認基準をチームに浸透させることができます。受け入れテストには顧客の同意が必要であるため、受け入れテスト ケースは、スプリントの開始前に作成することをお勧めします。
単体テスト
単体テストは、コンポーネント、クラス、メソッド、プロパティの各レベルで機能を検証する自動テストです。プロジェクトの長期的な安定性と将来にわたる保守性をもたらす自動テストと回帰テストの基本単位となります。
単体テストがアプリケーションの設計をどのように進化させるか
単体テストを作成し、その一方でテスト済みのコードをビルドするというプロセスによって、コードの姿は明らかになっていきます。大切なのは、単体テストで点検できるコードを作成することです。コードの単体テストを作成することが難しいとしたら、それは、コードをリファクタリングする必要があることの表れです。
単体テストをどのように編成するか
コードを記述する各チーム メンバーは、自分が作成しているコンポーネントの単体テストを作成し、Visual Studio プロジェクト内のバージョン コントロールに単体テストのコードをチェックインする必要があります。テスト ケースの作業項目は、("継続的インテグレーション" のもとでビルドごとに実行される) ビルド確認テスト スイートに追加されるほか、対応するユーザー ストーリーを検証するテスト スイートにも追加されます。
テスト コードに変更を加えずに単体テストの変動要素をどのように扱うか
プロジェクト コードの機能を検証する各テストが互いにどれだけ似ているか (違っているか) は、テスト入力の変動要素によって特徴付けられます。たとえば、Web アプリケーションのログオン コンポーネントをテストする場合、ユーザー アカウントを作成するシーンでさまざまな種類のパスワードを与えることができます。このようなシステムには通常、使用できる文字種の組み合わせや順序などの規則が設けられます。
Visual Studio Test Professional では、データ ドリブン単体テストおよびコード化された UI テストを作成するための機能を提供します。詳細については、「方法: データ ドリブン単体テストを作成する」および「方法: データ ドリブンのコード化された UI テストを作成する」を参照してください。
テスト駆動開発と早期テスト
テスト駆動開発 (TDD: Test Driven Development) は、プログラマがコーディングの前にテストを作成し、その結果を鑑みながらコード行を記述していく設計とプログラミングの手法です。実装しようと思っているコードの "利用者に自分がなる" という考え方は、コードがどのように使用され、どのように設計されなければならないかを常に現実的な見地から捉えることができる非常に強力な手法です。
TDD では、開発者は多数の小さなインクリメントで作業します。小さな各インクリメントの開発には、数分から数時間がかかります。通常、このような多数のインクリメントでユーザー ストーリーが構成されます。開発者は、ユーザー ストーリーが機能するときにテストおよびコードをチェックインします。開発者は次のサイクルで作業します。
インクリメントを記述するときに合格すると予想される自動テストを記述します。
テストが動作するかどうかを確認するために、新しいテストが不合格になることを検証します。
テストに合格するコードを記述します。
テストを実行して、正常に動作することを検証します。
他のすべてのテストも同じ領域で実行して、バグが発生していないことを確認します。
必要に応じてコードをリファクタリングして、動作を追加せずに構造を改善します。テストを再実行して、コードが引き続き動作することを確認します。
完全なユーザー ストーリーが実装されるまで、これらすべての手順を繰り返します。前述のインクリメントが完全なストーリーに統合されたら、完全なストーリーを検証するテストを追加します。
実装コードと単体テストをチェックインします。
早期テスト方式の利点に興味がある場合は、まず手動 (または手動受け入れ) テストの作成をお勧めします。この手動テストは、コード化された UI テストを作成することによって自動化することができます (詳細については、「方法: テスト中のアプリケーションの記録によるコード化された UI テストの生成」を参照してください)。Visual Studio ALM の単体テスト フレームワークを使用した統合テストを作成することによって、実装しようとしている機能を検証することもできます。イテレーションの早期に作成された一連のテスト ケースは、機能の検証とバグの検出を目指してイテレーションの早い段階で実施されます。これらのテスト スイートおよびテスト ケースは、回帰テストとして、プロジェクトのライフ サイクル中、継続して実行することができます。このテストを継続して行うことによって、後からプロジェクトに生じた変更が、イテレーションの早期に検出されたバグと検証済みの機能に作用しないように徹底することができます。
継続的インテグレーションのための単体テストの使用
早期テスト型の慣例に沿って作成された単体テストは、現在のスプリントおよびユーザー ストーリーに対応するテスト スイート内で編成する必要があります。この単体テストをプロジェクト全体のテスト計画に昇格し、チームが継続的インテグレーション サイクルの中で定期的に実行することができます。単体テストは統合テスト、ロード テスト、およびパフォーマンス テストの基本単位としても使用されます。
最初の段階で作成された単体テストを、継続的インテグレーションの一部として使用することができます。ビルド時にテストを実行する方法の詳細については、「TestToolsTask Task」を参照してください。
仮想化を使用したテスト構成の管理
単体テストを実行するには、Microsoft Test Managerのマネージ Hyper-V イメージである一連の環境を作成できます。Microsoft Test Managerを使用してテスト計画から自動テストを実行する方法の詳細に 方法: Microsoft Test Manager を使用してラボ環境で自動テストを実行するを参照してください。
手動テストと自動テスト
自動テスト ケースと手動テスト ケースは相補的な関係にあります。アジャイル チームでは、テストを頻繁にまたは継続的に実行するため、できるだけ多くのテスト ケースを自動化しようとします。継続してテストを実行するには、すばやく頻繁に実行できなければなりませんが、手動テストではそれは困難です。
手動と自動のテスト ケースの配分を決める際には、いくつかの考慮事項があります。
テストの種類を配分するうえで組織内のスキルがどのように影響するか
製品所有者は、プロジェクトのユーザー ストーリーを定義する役割に加え、受け入れテストの作成に貢献します。製品所有者はコード化されたテストを作成することはまずありませんが、該当するビジネス ドメインに関しては深い知識を有している必要があります。したがって、製品所有者は、ビジネス上の語彙や規則のレベルでテスト ケースを定義することになります。たとえば、輸送会社の製品所有者は、その会社が持っているさまざまな輸送手段 (トラック、列車、航空、船、または、その組み合わせなど) を指定します。そのうえで、製品所有者は、異なる可能性を行使するテスト ケースをいくつか定義できます。このような手動テストでは、別の選択肢 (この場合は輸送手段) を行使するテストの最低数を指定することが重要となります。
コードを作成するチーム メンバーは、手動テストまたはその他の独立したテストから、コード化された UI テストを構築することができます 詳細については、「How to: Generate a Coded UI Test by Recording the Application Under Test」を参照してください。コード化された UI テストでは、コード プロジェクトを管理および開発する機能を備えたチーム メンバーによってサポートされる必要があります。
いつ手動テストを自動テストに変換する (または自動テストをゼロから作成する) か
自動テストを構築するタイミングは、テストを繰り返し実行してコードの安定性維持を図る必要性が生じたときです。自動化に伴う投資はチームのリソースに影響するため、自動テストの作成に要する手間を考慮することが重要です。コード チャーンがほとんどなければ、テスト コードの変更も少なくて済むので、それだけ自動テストの作成による投資収益率 (ROI) は大きくなります。ただし、ロジックとデザインの両面から問題を発見しやすくなるため、早期にオートメーション化する価値はあります。いずれにしても、自動テスト コードをサポートするために必要なリソースは考慮する必要があります。
オートメーションの利点の 1 つには、コードの安定化があります。自動化するテストが決まったら、できるだけ早くそれを完了するよう行動に移してください。オートメーションに必要な工数は、コードそのものの安定性と、オートメーションの過程で発覚する欠陥の数によって左右されます。結局のところ、手動テストと自動テストのバランスは、プロジェクト期間中に構築し、実行する必要のある各種テストの優先順位を抜きにしては語れません。
どのような種類のテストを自動化するか
単体テスト
単体テストでは、コードの機能を検証します。または、単体テストは TDD などのプロセスで実行します。コード内の依存関係と安定性を維持する効果があるため、単体テストは重要です。TDD には、依存関係および優れたレイヤー定義を持った質の高い設計を促進する効果もあります。コードの利用者の視点から設計を理解することができるためです。
ロード テスト
ロード テストは、既存の自動テスト ケースを使用して作成できます。つまり、アプリケーションまたはサービスに対して特定の種類の負荷 (ロード) を生成するテストを作成できます。テスト エージェント コントローラーおよびテスト エージェントを使用し、テスト負荷をシミュレートして生成する方法の詳細については、「方法: テスト コントローラーおよびテスト エージェントを使用してテストを実行する」を参照してください。
Visual Studio ALM を使用したロード テストの詳細については、Microsoft Web サイトの「ロード テストの概要」ページを参照してください。
継続的インテグレーション テスト
Visual Studio ALM と継続的インテグレーションによって、開発およびチェックインされたコードが必ず既存のコードで正しく動くようにすることができます。チームおよびコード ベースが大きくなると、継続的インテグレーションは欠かせません。テスト パラメーターを含んだビルドの種類を定義して、ビルドの完了後に実行するテストを指定することができます。テストを実行するビルドの定義方法の詳細については、「既定テンプレートに基づくビルド プロセスの定義」を参照してください。
どのような種類のテストを自動化できるか
構成テスト
複数のインストール環境でのテストは、きわめて根気のいる作業です。Microsoft Test Manager には、仮想マシンまたは物理マシンを使用して、テスト スイートを異なる構成で実行することのできる機能があります。複数の環境でテストを実行してデータを収集する方法の詳細については、「テスト コンピューターでのテストの実行またはデータの収集の設定」を参照してください。
ユーザー インターフェイス テスト
Visual Studio ALM には、ユーザー インターフェイスに対する自動テストを直接作成できる機能があります。コード化されたユーザー インターフェイス テストを作成する方法の詳細については、「方法: コード化された UI テストを作成する」を参照してください。
インストール テスト
アプリケーションのインストール プログラムが思いどおりに動くかどうかを検証するために使用できる構成グループを設定するには、Microsoft Test Manager のラボ機能を使用します。
オートメーションの障壁にはどのようなものがあるか
チームの能力
オートメーション化を実現するためには、テスト チームのうち何人かがコードの記述方法を覚える必要があります。オートメーション コードの作成とテスト コードの設計を覚えるにはそれなりに時間がかかります。その時間を考慮に入れるようにしてください。本番コードと同様、目指す目標 (保守が容易、構成がしやすい、長く使用できるなど) に向けてオートメーション コードを設計します。
Visual Studio Test Professional を使用して自動テストを作成する方法の詳細については、Microsoft テスト マネージャーを使用した自動テストの作成"を参照してください。
コード チャーン
頻繁に変更されるコードは、動いている標的をねらうようなものです。テストのオートメーション コードにも変更が必要になるため、その影響は連鎖的です。このような連鎖的な影響は避けるには、変更の可能性が低いコンポーネントとインターフェイスを対象にテスト オートメーション コードを作成します。
コードの設計
チーム メンバーは、コード フレームワーク (ASP.NET MVC や MVVM など) に沿ってコードを記述することにより、コードの各部分を検証するために必要な要素である "コードの分離性" を高めることができます。ユーザー インターフェイスに緊密に関連付けられているコードは、テストが困難です。ユーザー インターフェイスのコントロールをユーザーが操作しなければならないことがあるためです。
手動テスト ケースの利点とは
手動テスト ケースには、次の利点があります。
手動テストでは、調査のプロセスでバグを見つけることができます。
適宜抽象化して一連の手順を定義でき、成否の定義を好きなように決めることができるという点で、手動テスト ケースは定義しやすいという利点があります。
手動テスト ケースは、コードが記述される前のプロジェクトの早い段階で、きわめて手軽に書き始めることができます。受け入れテストを定義するプロセスでは、このことが重要となります。
Visual Studio Test Professional を使用すると、テスト ケース、共有ステップで同様のテストをテストのサブセットの一つのバージョンを再利用できる時間の短縮を定義するときに役立つ、チームが構成できます。共有ステップは、テスト ケースを変更する場合にも有利です。共有ステップに変更を加えると、その共有ステップを使用するすべてのテスト ケースが自動的に変更されます。共有ステップを作成および使用する方法の詳細については、「How to: Share Common Test Case Steps Using Shared Steps」を参照してください。
手動テスト ケースは、プロジェクトまたはスプリントの早い段階でのコミュニケーション手段となります。
手動テスト ケースは、コードをレビューする担当者がいなくても自動テスト ケースの文書化の手段となります。
Visual Studio ALM を使用した場合、手動テストの実行によって、コード カバレッジ メトリックを収集することができます。
手動テスト ケースの欠点とは
手動テスト ケースには、次の欠点があります。
成功の基準を定義するのが複雑になる場合があります。成功の基準は見方によって変わるうえに、テストの定義に使用されている言語によっても左右されます。言語によって解釈が異なれば、エラーの余地が生まれることになります。
手動テスト ケースを含んだテスト スイートを実行するには、テスト ステップを物理的に実施し、結果を報告する人材が必要です。このプロセスは多大な時間を要する場合があります。結果、テストを実行するための人員を確保したり、テスト スイートの実行期間を延長したりしなければならないこともあります。Visual Studio Test Professional を使用して、チームは、アクションが以降のテストの実行で実行できるテストで使用される記録または ""、手動テストを早送りできます。
テストの実行に要する時間と工数が、コードの安定性によって左右されます。結果的に、手動テストを実行すると、チームの流れに影響が生じる場合があります。
手動テストの最大の欠点は、バグの検出にヒューマン エラーが伴うという点です。テスト担当者は目の前にバグがあっても気付かないことがあります。
自動テスト ケースの利点とは
自動テスト ケースには、次の利点があります。
自動テストには、安定性を維持する効果に加え、コード変更によって生じる予想外の影響 (回帰) を発見しやすくなる効果があります。
自動テストの実行は無人化することができます。
自動テストはソフトウェアであるため、他の再利用可能なコードと組み合わせて設計することができます。これが自動テストの柔軟性と保守の容易さにつながります。
Microsoft Test Manager を使用することによってオートメーションを複数の構成で実行できます。
自動テストの実行時にコード カバレッジ メトリックを収集することができます。
自動テスト ケースの欠点とは
自動テスト ケースには、次の欠点があります。
特殊な条件をコードを使用して考慮し、実装する必要があります。オートメーション コードを作成して実行するとき、追加で見つかった条件は随時実装することになります。
コードの変更またはリファクタリング時に、連鎖的な影響が生じる場合があります。対応する自動テストにも変更を加える必要があり、その分の工数がかかります。
コードの変更が原因で多くのテストで不合格になる場合は、チームに心理的な影響が出る可能性があります。テストが何かの目安として使用されているならば、あえてそれを蒸し返すことはしたくないものです。
テスト ケースの条件設定が正しくないと、すべてのテストに合格しているので問題ないと誤って認識される可能性があります。テスト スイートをメンテナンスし、正しい条件で結果を検証する必要があります。
テスト結果の報告
バグや集計メトリックに基づいて現在の品質の状態を Team Foundation Server に報告 (または照会) することは、アジャイル テストの観点から見るとフィードバック ループの輪を形成する要素の 1 つと言えます。チームは、その中で作業を反復的に行いながら、コードやプロジェクト計画、テスト計画に変更を加えていきます。詳細については、「テスト計画の進行状況レポート」を参照してください。
または Microsoft テスト マネージャーのテスト計画の結果の機能を使用して監視して、テスト計画の進行状況ができます。テスト計画の結果が渡され、壊れた、アクティブなテストのグラフと数統計情報が含まれます。また、テスト計画の結果は失敗の種類と解決方法の詳細なデータを示すグラフが含まれています。テスト計画の結果は、テスト計画に特定のテスト スイートを含めるか、除外フィルター処理できます。また、テスト チームの個々のテストの結果を表示できます。詳細については、「方法: Microsoft Test Manager でテスト計画の結果を表示する」を参照してください。
.png "テスト計画の結果")
チームにどの程度のテストまで報告すればよいか
Visual Studio Test Professional および Team Foundation Serverを使用して、チームは、テスト計画の状態を把握できます。Team Foundation Server には、テスト計画、テスト スイート、テスト ケース、テスト結果など、テスト プロセスを通じて生成されるすべての関連データが格納されます。Team Foundation Serverの報告機能と作業項目クエリと Microsoft Test Manager をまとめればテストおよび品質管理のプロセスを視覚化できます。さまざまな状態のバグを照会するには、を Microsoft Test Manager を使用できます。他のチーム メンバーによって修正済みとしてマークされたバグは、"解決済み" の状態となります。後続のビルドを使用して、修正済みのバグを検証できます。バグが修正されているかどうかを検証する方法の詳細については、「方法: Microsoft テスト マネージャーを使用して、バグが修正されたことを確認する」を参照してください。