Home › Docs & Help › HowTo: › Litmus

テストケース作成方法

Mon, 2007-05-07 15:13 — sao

　Litmusのテストケースを投稿してみたいって？

大歓迎です！しかし、投稿する前に知っておいてもらいたいことがいくつかあります。その内容を今回はご紹介します。

1. テストケースの作成方法
2. テストケースの手順
3. サンプルテストケース
4. テストケースの投稿の仕方
5. テストケースの変更
6. その他のMozillaでのQA活動について

このドキュメント内容と同様のものが、http://wiki.mozilla.org/Mozilla_QA_Community:Test_Case_Writing_Day_Guidelinesに掲載されていますので参照してみてください。

Litmusのテストケース記述に関する諸注意

    1. 簡潔な言葉づかいを心がけてください
    2. テスト協力者を誘導しやすい手順を作ってください
    3. 必要に応じて詳しく説明をしてください
    4. 専門用語や難しい表現は避けてください
    5. Expected Resultsの項目は簡潔にまとめてください
    6. ブラウザやメールクライアントになじみのないテスト協力者にも配慮したテストケースを作成してください
    7. 読む人のことを考えて書いてください

1. テストケースの作成方法

　テストケースを作成する時に、実行手順を記述するという作業は、
バグを発見する時などの”ステップの再現”に似ています（Bugzillaを利用している人は、似ていると感じるでしょう）。
テストケースを記述する際に役立つガイドラインは以下の通りです。
*テストケースのタイトル：
　テストケースにタイトル付けを行う際は、タイトルをより簡潔に表現できるよう努力してください。
以下の例を参考にして、テスト協力者にとって分かりやすいタイトルをつけてください。
良いタイトル例

  • ブックマークの追加
  • キーボードのショートカットを利用したOpen Search
  • ホームページを初期設定に戻す

悪いタイトル例

  • ホームページ
  • ヘルプ
  • フォント

　悪いタイトル例では、ホームページ、ヘルプ、フォントに関して、どの部分がテストされているのかが分かりません。
それらを分かり易いタイトルに変更すると以下のようになります。

  • ホームページの設定
  • Mozilla Firefoxのヘルプを表示すること
  • キーボードコマンドを利用してフォントサイズを小さくすること

2. テストケースの手順

　Litmusの一般的なテストケースはテストを実行する手順と、テストを行った後の期待される実行結果という2部で
構成されています。以下に、テストケースを作成する上での諸注意をあげますのでよく読んで参考にしてください。

Steps to Perform:

  • 機能をテストするために、必要最小限の項目を記述してください。
    ここでは長すぎる文章は控えてください。強調したい内容を簡潔に記述してください!
  • 記述する際には、まず初めに基本的な手順を洗い出し、テストに含める1つ1つのプロセスをよく考えた後で、
    その機能を評価するのに必要だと思ったら項目を追加して下さい。
  • 新機能のテストケースを書く際には、事前にその機能についてよく理解しておく必要があります。
    ウィンドウを全て開き、すべてのボタンや設定を試してください。
    新機能の仕様が十分に理解できてからテストケースを書いてください。
  • 実際の実行画面を加えて、手順を説明することができます。その方法の1つとして、スクリーンショットを撮り、
    そこに手順を直に記述することが挙げられます。
  • もし特別な設定を行うことが必要ならば、テストケースの冒頭でそのことを必ず記載してください。
    例えば、プロファイルの新規作成が必要な機能をテストする場合は、テストの冒頭でテスト協力者に必ずプロファイルを
    新規作成させてください。そうしなければ、テスト協力者は既に使用しているプロファイルを使ってテストをしてしまいます。
  • FirefoxやThunderbirdはWindows、Mac、Linuxの3つのプラットフォームで実行されること、
    そしてそれらは、プラットフォーム毎に振る舞いがほんの僅かに異なることを念頭に置いてください。
    テストケースを記述する際、他のプラットフォームもチェックできるようでしたら、よりベストです。
    もしWindows向けに記述されたテストケースメモを投稿した場合でも、QAチームのメンバーが他のプラットフォーム向けに
    テストケースを微調整するので、大丈夫です。


Expected Results:

  • テストを実行した結果、アプリケーションや機能がどのような動作を行うべきかを記述します。
  • “期待された振る舞いが見られるはずだ”というよう曖昧な表現は避けてください。
    何が起こったのかをテスト協力者が推定できるような形で表現してください。

3. サンプルテストケース

例1： Firefoxのツールバーにアイコンを追加する機能をテストするテストケースを作成する
　最初にアイコンをツールバーに追加するのに必要な一連の手順について考えなくてはいけません。
それが出来たら、今度は「ツールバーのカスタマイズ」を起動する方法を思い出してみましょう。
もしかしたらテストケースを記述する時に、それを考慮しなくてはいけないかもしれません。
まずは、ツールバーにアイコンを追加する最小限の手順から始めましょう。

Title：

    Firefoxツールバーにアイコンを追加する

Steps to Perform:

    1. ツールバーを右クリックし、ドロップダウンメニューから「カスタマイズ」を選択してください。
    2. アイコンとスペースを格納している「ツールバーのカスタマイズ」ダイアログボックスが表示されます。
    3. マウスでアイコンを1つ選択してください
    4. アイコンをツールバーにドラッグし、URLバーの右（URLバーと検索バーの間）に配置してください。
    5. 「完了」をクリックして、「ツールバーのカスタマイズ」ダイアログボックスを閉じてください。
    6. Firefoxを再起動してください。

Expected Results:

    1. ツールバーの指定した場所にアイコンが追加される。

これは基本的なテストケースの例です。しかし、以下のような、たくさんの不明確な仮定が存在します。

    • 右クリック以外にも「ツールバーのカスタマイズ」ダイアログボックスを表示する方法があります（メニューやキーボードコマンド）。

　必ずしもテストケースにすべてを含む必要はありませんが、含まれていればテスト協力者が様々な方法で実行してもカバーでき、
またその部分も合わせてテストが出来るので有益です。
Litmusにはキーボードコマンドをカバーするテストケースが別途あるので、たとえあなたが作るテストケースに
キーボードコマンドをカバーするテストが含まれていなくても、差し支えはありません。
　さらに、このテストケースはアイコンを追加できるかどうかのテストですが、追加されたアイコンの実際の機能については
どうでしょうか（例えば印刷アイコンをクリックした時、本当に印刷ダイアログが起動したかどうか）？
「一石二鳥」なテストケースを記述する事は有益です。単に「追加したツールバーのアイコンをクリックし、期待通りの機能が
起動したか確認する」というような1行を付け加えるだけでもテストケースはそれまでよりも良いものになります。
今回の例では、たった1行追加する事で大きな利益が得られましたが、全てのテストケースでただ1行追加すれば
済むわけではありません。あなたがテストケースを記述する時には、今回のような類の事をまずは考えてみてください。
1つのテストケースに様々な項目を盛り込むような事はしたくないですが、同時に行えることで生まれる利点も多くあります。

テストケースを書き直し、印刷アイコンの機能のテストを追加しました。
Steps to Perform:

    1. ツールバーを右クリックして、ドロップダウンメニューから「カスタマイズ」を選択してください。
    2. アイコンとスペースを格納した「ツールバーのカスタマイズ」ダイアログボックスが表示されます。
    3. 印刷アイコンをマウスで選択してください。
    4. 印刷アイコンをツールバーにドラッグし、URLバーの右（URLバーと検索バーの間）に配置してください。
    5. 「完了」をクリックして、「ツールバーのカスタマイズ」ダイアログボックスを閉じてください。
    6. Firefoxを再起動してください。

Expected Results:

    1. 印刷アイコンが指定された場所に追加されます。
    2. 印刷アイコンをクリックすると、印刷ダイアログが起動します。

手順6のFirefoxの再起動は強制ではない事に注意してください。
しかし、この手順を行う事により、再起動後もFirefoxがユーザ設定を保っているかどうかが確認できます。

例2:ウェブページ上でドラッグと選択を行うテストケースを作成する

Title:

    ウェブページ上でのドラッグと選択

Steps to Perform:

    1. どこかのWebページを閲覧します
    2. ページをドラッグ選択します
    (具体的に言うと、マウスのボタンを押したまま、ブラウザ内のコンテンツのある点から下方までマウスポインタをドラッグすることです。)

Expected Results:

    画面が下方へスクロールされます。スクロールされたコンテンツは選択されています。

　どのようにしてこのテストケースを改良出来るのでしょうか。
このテストケースは最初の方はよいですが、いくつか改善すべき点がまだあります。
例えば、Expected Resultsでは、テスト協力者がどのようなコンテンツを選択するのかを決めつけていますが、
コンテンツと言っても様々な種類があり、それらをすべて同一に扱うことができるのでしょうか。
また、たいていコンテンツを選択すると、選択されたコンテンツは色が反転されています。
それは、指定した範囲を明確にするのにとても役立つので、そのことも記述すべきでしょう。
　加えて、このテストケースはスクロール出来るだけのページサイズが必要です。
なので、コンテンツをスクロールするのに十分なページをテスト協力者に対して素早く紹介するために、
サンプルとなるURLを提示してください。

上記のテストケースを改善したものを作ります。
このテストケースの改善したものを作りたければ、以下のように行います。

Title:

    ”すべて選択”を使用したウェブページのドラッグと選択

Steps to Perform:

    1. どこかのWebページを閲覧します
    2. コンテンツ画面上で右クリックし、”すべて選択”をクリックします

Expected Results:

    ページ上のすべてのコンテンツが強調されます。
    注意:反転された色はシステムの設定によって異なります。

4. テストケースの投稿の仕方

　テストケースを書いたら、どうやってLitmusに投稿すればよいでしょうか?
テストケースをtestday@mozilla.orgに送信して、レビューを受けてください。
Mozilla QAチームの誰かが、あなたのテストケースをレビューして、その後Litmusへこのテストケースを登録します。
もしあなたが必要であれば、Mozilla QAチームはirc.mozilla.org(http://irc.mozilla.org)上の
#testdayや#qaチャンネルで喜んでお手伝いします。

5. テストケースの変更

　Litmusを実行している時に、間違っているもしくは問題のあるテストケースに気づいた時には、2つの修正方法があります。

    1. そのテストケースのResultをTest unclear/brokenで回答します。
    その際には、どこが問題なのかを必ず分かりやすくコメントに記述してください。
    2. 上記のテストケース作成例を参照にテストケースを書きなおし、
    書きなおしたテストケースをQAチームに送信してください。

Litmusとテストケース改善にご参加していただき、ありがとうございます。

6. 他のMozilla QAの活動

　Litmusのテストケースを改良するのを手伝っていただけるのならば、出来れば他のMozilla QA活動にも
参加していただけると幸いです。
MozillaコミュニティQA Testday :

    新しいリリースとビルドをテストします。世界の他の国々の人々と交流し、テストを楽しむためのよい空間です。
    TestdayはMozilla QAブログで告知されています。(http://weblogs.mozillazine.org/qa/)

Bugday :

    Bugdayに参加していただけるとMozillaのQA活動にとても役立ちます。
    Bugdayへ参加するのに、あなたが長い期間Mozillaに関わっているかどうかや、
    オープンソースコミュニティに参加するはじめの一歩かどうかということは問題ではありません。
    みなさんに参加していただくことで、MozillaのQA活動が活性化されるのです。
    予定された時間内でBugzillaに参加してくれる人を集めます。
    週によってBugdayの厳密な内容や話題が変更になるかもしれませんが、おおまかな見解としては、
    チームとしていくつかのバグのリストを解決することです。
    (http://wiki.mozilla.org/Mozilla_QA_Community:Bug_Day)

‹ Litmus チュートリアルupSource Code ›