手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ

<<クロスポスト:この Blog は、「Visual Studio 日本チーム Blog」へ投降した「手動テストの品質向上~Visual Studio 2012 ソリューションシナリオ」と同内容のクロスポストです。>>

<< ”Visual Studio 2012 ソリューションシナリオ" では、開発現場における様々な課題を Visual Studio 2012 によってどのように解決できるのかを紹介いたします。>>

image 

開発プロジェクトにおける手動テストは、開発者が行う単体テストや結合テストと異なり、ユーザーの代弁者としてアプリケーションに対する操作を通じて品質検証を行う活動です。従ってアプリケーションに対しては技術的な視点よりも、ビジネス的な視点に立って検証を進める必要があります。

 

このソリューションシナリオでは、手動テストの実施に当たって、どのようなことを考慮することで手動テスト自体の品質向上を図っていくことができるのか、またその中で Visual Studio 2012 のどのような機能を活用できるのかを紹介します。

 

image

開発の現場において手動テストを実施する際には、経験豊富なテスト担当者によって用意されたテストドキュメントをもとに、担当者が実際にアプリケーションを操作しながらアプリケーションの検証を進める、といったスタイルがとられることが多いのではないでしょうか?

この過程においては、以下のような課題が発生しがちです。

 

  • 経験豊富なテスト担当者に依存しがちになり、他のメンバーにとって十分なドキュメントが用意されていなかったり、品質基準の定義があいまいなままテストが進んでしまう。

 

  • 手動テスト(特に探索的テスト)においてバグに遭遇した場合に、再現性のあるシナリオの特定に手間がかかってしまう。

 

  • 手動テストによってアプリケーションのどれだけの割合がテストできたのかが把握しづらい。

 

  • いくつかの条件の組み合わせが必要なテストシナリオの場合、アプリケーションの操作が長くなってしまい、テスト途中における操作の抜けや誤りによって、再度テストを初期状態からやり直す必要がある。

 

  • 同様の場合に、操作の誤りに気づかないままテストを続けてしまい、間違ってアプリケーションのバグを報告してしまう。あるいは、アプリケーションのバグに気づかずにアプリケーションをリリースしてしまう。

 

自動化が行いやすい単体テストや負荷テストと異なり、手動テストは人による関与が大きいため、設定したテストシナリオによってアプリケーションの品質が十分に検証できるのか、テストにおけるアプリケーションの操作自体に誤りがないのか、等の基準があいまいなまま、担当者の経験に依存して実施されることが多くあります。

 

image

このような問題を解決し、手動テストの品質を向上するには、以下のようなプラクティス(行動)の実践が挙げられます。

 

手動テストの実施環境を整えよう

手動テストにおいては、特別な実施環境を用意することなく、テストシナリオが書かれたドキュメント(多くの場合は Excel や Word に書かれた操作手順)と、アプリケーションを使用するであろう一般的なユーザーと同様のPC環境でテストを実施することがほとんどです。

しかし、テストにおけるアプリケーション操作の間違いを最小化し、またバグ(あるいはその可能性)を発見した際に、再現性のあるシナリオ特定をスムーズに進めるためにも、テスト担当者に対する支援環境を用意し、テストメンバー全員が同じ手順で、同じ品質基準をもとにテストを実施できる環境を用意すべきなのです。

手動テストの実施環境としては、(1) アプリケーション操作を間違わないためにもわかりやすくシナリオ(操作手順)を伝える環境、(2) テスト実施時の操作やアプリケーションのふるまいを効率的にまとめることのできる環境、(3) バグ発見時にその報告を簡単に実行できる環境、などの環境が考えられます。

このような手動テストの実施環境を用意することで、手動テストの品質を向上していくことを心がけましょう。

 

 

手動テストシナリオの品質を高めるために、数値データを活用しよう

手動テストにおける課題の一つが、テスト自体の品質が、テスト担当者の技量に強く依存してしまう、ということです。この問題に対処するためには、メンバー全員が共有できる指標として、「数値データ」を活用するのがよいでしょう。

例えば、手動テスト自体の品質指標として、以下の二つの数値データの活用が考えられます。

(1) ユーザーの要件(ユーザー ストーリー)に対して、どの程度のテストが実施されているか。

(2) テストによって、どの程度のコードがカバーされているか。

一昔前の開発環境であれば難しかったこのような指標の計測についても、技術的な進歩にともない、いくつかのツールにおいて手軽に計測ができるようになってきています。

テスト担当者の経験に頼ってテストシナリオの準備を行うだけでなく、このような数値を用いることでシナリオの過不足を直観的に理解できるようにし、手動テストの品質を高めましょう。

 

 

技術的に可能な部分は自動化を進めよう

手動テストが「手動」である理由は、UIを使ったテストの自動化が難しいという技術的な理由と、人の経験や洞察力に基づく操作でテストを行いたいという「人」に依存するテストである、という2つの理由があります。

この前者に関しては、ツールの進化により UI を使ったテストの自動化が低価格でかつ簡単に実施できるようになってきていますので、最適なツールの検討を行い自動化を進めましょう。「手動でしかできない」と思っていたテストが、そのようなツールを利用することで「自動化」することができ、テスト実施のための手間の削減や、テスト自体の品質向上が可能になります。

また、後者に関しては、一般的に「探索的テスト(Exploratory Testing)」と呼ばれる手法で、テスト担当者の経験や洞察力をもとにアプリケーションの検証を行うテストですが、こちらに関しても操作記録をビデオで残す、等の部分的な自動化(この場合は記録の自動化)を行うことは可能ですので、積極的に自動化を進め、テストそのものに注力できる環境を構築しましょう。

         

 

image

Visual Studio 2012 では開発チームがこれらのプラクティス実践をスムーズに行えるように、様々な支援機能を提供しています。

 


プラクティス1:手動テストの実施環境を整えよう


単体テストや Web パフォーマンステストなど、豊富なテスト機能を用意している Visual Studio 2012 ですが、テスト担当者による手動テストに関する支援機能もまた提供しています(※)。

 

その機能の一つ目が、テスト手順とその期待される結果を「テスト ケース」と呼ばれる単位で管理するための仕組みです。

 

「テストケース」ではテスト担当者が手動テストにおいて確認したい内容をシナリオとして記述するともに、テストケースとしての優先度を設定します。以下のサンプルは、ある Web サイトにおいて、不正なユーザーアクセスがあった場合のシステムのふるまいの確認のためのシナリオです。

image

 

このテストケースをもとに、Visual Studio から 「テストの実行」 を行うと、それぞれのステップの内容、ならびに、期待される結果が PC に表示されますので、それを参照しながらテストを行いたいアプリケーションの操作を行います。また、アプリケーションの操作を行った結果が、期待される結果にあっているかどうかを確認し、ステップごとの「成功」、「失敗」を記録することが可能です。

image

 

ステップ途中で報告すべき事象が発生した場合は、メモとして情報を残したり、画面のスクリーンショットを簡単に記録として残すことが可能です。下記の画面では、「四角形キャプチャのスクリーンショット」の機能により、ID/Password 入力部分のスクリーンショットイメージを記録しているところです。

image

 

 

テストが終了すると、テスト実行の記録が以下のようにまとめられ、チームで共有することが可能です。

このテストの記録では、ステップ4にて、予期せぬエラーが発生しており、その件に関する「メモ」および「画面ショット」を共有しています。また、テストの実行記録は「ビデオ」としても記録されており、ステップごとに、ビデオの頭出し用のインデックスも自動的に用意されているため、実際に行った操作に関するより詳細な情報、状況を確認することが可能です。

 

image

 

 

さて、テストの実行においては、「一つのテストケースに、一つのテスト結果」、という関係ではなく、「一つのテストケースに、複数のテスト結果」が結びつくことになります。

 

Visual Studio の手動テスト管理機能では、実際に「テストケース」ごとに複数のテストの実行結果を関連付け、管理することが可能です。下記の画面ショットでは、一つのテストケースに対して、3回のテストが実施され、最初の2回はテストが失敗したものの、3回目のテストでテストが成功した、という状況が読み取れます。

image

           

また、上記のテストの実行結果の一覧画面や、テストを実行中にテストのステップを表示している画面等から、バグ情報の作成を行うことができます。

 

image

 

作成したバグ情報は、バグを発見した際のテスト実行結果と自動的に結びつきチームメンバーに共有されるため、バグを報告するテスト担当者としてはバグ情報入力の手間を削減できます。また一方で開発者としては、実際にテスト担当者が行った操作手順や、遭遇したエラーの状況などをビデオ等で確認しつつ、バグ撃退を進めることが可能です。

 

※ テスト担当者向けのテスト支援機能の多くは、Visual Studio Test Professional 2012 にて提供されています。Test Professionalo は Visual Studio 2010 のリリースの際に登場した新しいエディションであり、開発ツールとしての “Visual Studio” を含まず、純粋にテスト担当者が利用するツールとしてデザインされたツールです。Test Professional には、”Microsoft Test Manager” というツールが提供されており、このツールを利用してテストの管理、実施を行います。

 

手動テスト機能の使用イメージは「手動テストによる問題の容易な再現」のビデオの前半(4:05あたりまで)の内容をご参照ください。

手動テスト機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「テスト ツール」の項目をご確認ください。また Visual Studio ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください)。

 


プラクティス2:手動テストシナリオの品質を高めるために、数値データを活用しよう


Visual Studio 2012 においては手動テスト自体の品質向上を行う際に、以下の2つの観点で数値を利用したテストの管理が可能になります。

 

(1) Visual Studio 2012 では、ユーザーの要件(ユーザー ストーリー/バックログ)に対して、どの程度のテストが実施されているかをポータル(チームプロジェクトのポータル機能)で確認することが可能です。

 

ユーザーの代弁者としてアプリケーションの検証を行う手動テストは、テストによって「アプリケーションの機能」を検証する、というよりも、「アプリケーションがユーザーに価値を提供できているか」、という視点で検証を行う作業と言えます。

 

従って、手動テストを用意する際には、ユーザーの価値の視点でテストケースを用意していきます。Team Foundation Server / Service においては、選択するチーム プロジェクトのプロセス テンプレートにより、ユーザーにとっての価値、を「ユーザー ストーリー」(チーム プロジェクトのプロセス テンプレートとして MSF for Agile を選択時)「要件」(同 MSF for CMMI を選択時)、あるいは「プロダクトバックログ」(同スクラムを選択時)と表現しています。

手動テストの計画を行う際には、これらのユーザーにとっての価値をベースとし、テスト計画とテストの設計を行い、また実行状況の把握を行うことになります。

 

Visual Studio 2012 では下記の画面イメージのように要件(ユーザーストーリー、バックログ)に対して関連づいているテストの情報とそのテストがどのような状況かを確認できるようになっています。

ユーザー ストーリー テスト状態 Excel レポート

ユーザー ストーリー テスト状態 Excel レポート (アジャイル)

 

この機能によりプロジェクトマネージャーは、それぞれの要件がどの程度実装されているのか、と同時にテストがどの程度用意されており、またテストが終了しているのかを確認することができます。

 

上記のテストの実施状況に関するレポートは、Team Foundation Server における要件(ユーザーズトーリー、バックログ)に対して、Microsoft Test Manager を利用した「テストケース管理」の機能を組み合わせて実現しています。

 

テストケース管理機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「テスト ツール」の項目をご確認ください。開発チーム内にテスト専門の担当者が存在し、またその担当者がコード開発に携わらない場合、Visual Studio Test Professional が最適なエディションになります。テスト担当者がコード開発も合わせて行いたい場合は Visual Studio Premium 以上が最適となります。また、いずれのエディションも MSDN Subscription 付きで購入することで Team Foundation Server のサーバーライセンス、ならびにユーザーごとに必要となるクライアント アクセスライセンス(CAL)が付属します。

また Visual Studio ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください)。

 

(2) Visual Studio 2012 では、Update 1 を適用することによって、ASP.NET の Web アプリケーションの手動テストにおいて、どの程度のコードがカバーされているかを把握することが可能です。

 

この機能を利用するには、Visual Studio 2012 の Update 1 の適用が必要です。Update 1 を適用することにより、Microsoft Test Manager の「テストの設定」画面においてテストを実施する Web サーバーの設定として、「コードカバレッジ」の項目が表示されますので、この中で設定を行ってください。

 

image

 

これによって、IIS 上で動作する ASP.NET アプリケーションを利用するアプリケーションの手動テストにおいて、コードカバレッジの数値データを取得ることが可能です。このデータを利用し、実際に行った手動テストによりどの程度のコード、ロジックがカバーされているのかを数値として理解でき、手動テストシナリオの過不足を判断する材料として活用できます。

 

手動テストにおけるコードカバレッジデータの取得に関しては、次の2つの Blog も参照ください。

Code Coverage in Microsoft Test Manager in Visual Studio Update 1

Code Coverage in Microsoft Test Manager – Deep Dive

 

また、Visual Studio 2012 の Update 1 に関しては、以下の Blog もご参照ください。

Visual Studio 2012 の Update 1 がご利用いただけるようになりました。

 

コードカバレッジ機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「テスト ツール」の項目をご確認ください。また Visual Studio ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください)。

 

 


プラクティス3:技術的に可能な部分は自動化を進めよう


Visual Studio 2012 ではステップ数の長い手動テストにおいて、途中のステップでテスト中のアプリケーションの終了ボタンを押してしまったり、誤ったデータを入力してしまった場合などに、テストを中断したうえで、最初のステップから、途中のステップまでの操作を記録した情報をもとに「再生」することができます。

 

具体的にはテストを実行しているウィンドウ(Test Runner)において、再生を行いたいステップを選択している状態で、「再生」ボタンを押すだけです。

image

 

これにより、ステップ中で記録されていた操作を Visual Studio が自動的に再実行(再生)します。

(下記の画面ショットは、Password の入力を再生しているシーンです)

image

 

 

また、通常のアプリケーションのテストにおいて手動で実施しているであろうテストを、Visual Studio の「コード化されたUIテスト」の機能を使用することで、自動化し、繰り返し実行することが可能です。

コード化された UI テストでは、「コード化された UI テスト ビルダー」と呼ばれるツールを利用し、アプリケーションに対する操作情報を記録するとともに、画面上に表示されている項目に対するアサーション(「XXXと表示されるべき」という表明)を設定することが可能です。

 

「コード化された UI テスト ビルダー」で操作情報の記録を開始し、実際にアプリケーションの操作を行います。

image

 

また、操作の途中で、アサーションを追加したい場面になったら、操作記録をいったん中断し、画面の任意の場所を選択し、その項目に対するアサーションを追加します。

以下の画面では、テキストボックスに表示されている Text 情報として、”3” が表示されているべきだ、というアサーションを追加しています。

 

image

 

「コード化された UI テスト ビルダー」で記録されたテストは、Visual Studio にて確認、編集が可能です。機能名に、「コード化された」、とついているように、生成されたテストはコードとしてメンテナンスを行うことができます。

 

image

 

「コード化された UI テスト」の機能は WPF や Windows フォームアプリケーションに対応しています。

またブラウザでテストを行う場合、記録に関しては IE のバージョン8以降が必要ですが、テストの実施に関しては Visual Studio 2012 の Update 1 を適用することで、Chrome や FireFox でのテスト実行も可能になります。

詳しくは、以下の参考情報をご確認ください。

コード化された UI テストと操作の記録でサポートされている構成とプラットフォーム

クロスブラウザでの自動UIテスト~Visual Studio 2012 Update 1

 

また、コード化された UI テストの実施イメージに関しては、「コード化された UI テストによるユーザー インターフェイスのテストの簡単な実施」のビデオをご参照ください。

 

 

最後に、Visual Studio 2012 では「探索的テスト(Exploratory Testing) 」のサポート機能も用意しています。

探索的テストは Microsoft Test Manager の機能の一つとして提供されており、テスト担当者が行った作業をビデオで記録し、また問題を発見した際にスクリーンショットの取得や、バグ報告を行うための機能を統合し、提供しています。

image

 

テスト担当者は探索的テストを行う際に、ステップごとに操作記録や画面ショットを記録する、といった手間をかけることなく、探索的テストを自由に進めることが可能になります。

 

探索的テストの実施イメージに関しては、「手動テストによる問題の容易な再現」のビデオの後半(4:05あたりから最後まで)の内容をご参照ください。

 

コード化されたUIテスト、ならびに探索的テスト機能を利用できるVisual Stduio 2012 のエディションは「Visual Studio 2012 の機能比較」のページの「テスト ツール」の項目をご確認ください。また Visual Studio ライセンスについては「Visual Studio 2012 と MSDN のライセンスホワイトペーパー」を参照ください)。

 

 

今回の Visual Studio 2012 ソリューションシナリオでは、手動テストの品質向上のためのプラクティスと、Visual Studio 2012 の支援機能を紹介しました。

 

ソリューションシナリオには、以下のシナリオがあります。

受け入れテストのリスクコントロール

チーム開発における単体テストの実践

・手動テストの品質向上(本エントリ)

 ・コード品質の向上 ~ その1 ~

 

それでは!