テスト計画とその最適な書き方

Question

私たちはテスト計画でテストを記述する最適な方法を見つけようとしています。具体的には、QA スタッフを含むすべての人が使用することを目的としたテストを作成する場合、テストの手順を非常に具体的にするか、より広範囲に設定して、テスト担当者がタスクをどのように達成できるかについてより自由度を持たせる必要があります。非常に単純な例として、ワープロ文書で文書を開くことをテストしている場合、テストは次のようになります。

1. マウスを使用してファイルメニューを開きます
2. ファイルメニューから「ファイルを開く...」を選択します。
3. 表示されるファイルを開くダイアログで、x に移動し、y というドキュメントをダブルクリックします。

または

1. ファイルを開くダイアログを表示します
2. ファイルを開きますy

おそらく 1 つの答えは「何をテストしようとしているかによって異なります」ということになると思いますが、ここではより広範な質問に答えようとしています。テスト手順が具体的すぎると、a) テスト プロセスが面倒で退屈なものになるリスクがありません。さらに重要なことに、b) 目標を達成するためのパスが具体的すぎるため、何かを見落とすリスクがあります。あるいは、広範囲にすると、その時のテスターの気まぐれに依存しすぎて、顧客/クライアントにとってより一般的なパスの重要なテストが失われることになるでしょうか?

Answer 1

私の最初の質問は、なぜ QA 部門がテスト計画を作成しないのかということです。通常、ソフトウェア開発者は、ソフトウェアがどのように動作するかについての機能仕様を QA に提供し、QA はそれに基づいてテスト計画を作成します。

そうは言っても、状況を詳しく説明しているので、手順を非常に具体的にすることをお勧めします。 想定 働くこと。特定の手順で望ましい結果が得られることを確認するのがテスターの仕事であり、計画から逸脱して問題を解決しようとするのもテスターの仕事です。

目標を達成する方法が複数ある場合は、そこに到達するためのそれぞれのパスを説明する必要があります。

Answer 2

私はテスターではありませんが、混乱を避けるためにテストで実行する必要がある「UI ルート」を文書化することが重要であると考えています。

私は、テスターと同じ UI パスから関数にアクセスしていなかったという理由だけで再現できなかった無数の欠陥に取り組んできました。例えば右クリックメニューとツールバーや各種ダイアログから実行できる機能など。等

Answer 3

QA スタッフがテスト作成の責任を負っていない場合、QA スタッフは実際には QC (品質管理) であるように思えます。彼らが実際にテストを書く責任がある場合、あなたのテストは役に立ちますが、明確な仕様は、彼らが自分でテストを書くためのより良い情報源になります。さらに良いのは、仕様のレビュー プロセスの一部として彼らに参加してもらい、テストを作成するための詳細を尋ねることができるようにすることです。

実際に他の人のためにテストを作成する立場にいる場合は、考慮すべき点がいくつかあります。次のような場合には、かなりのレベルの詳細が必要になります。

• テストを実行している人はあなたに質問することができません
• テストを実行している人はあなたの製品に詳しくありません

これらが真実ではない場合は、一部の詳細を省略できます。ただし、それはまだ状況によります:)

以上のことを踏まえると、あなたが書くことになるものは、一般に「テスト計画」と考えられるものではありません。テスト計画には、実行されるテストの種類 (機能、回帰、セキュリティなど)、どの機能がテストされるか、さらにはどのようなテストが作成されるか、誰がテストを行うか、テストのグループがいつ実行されるかが記述されます。スケジュールされたアクティビティやその他の計画タイプのアクティビティ。

上記で説明したものは、単なる一連のテストです。

Answer 4

1 つ目は機能テストです。宛先へのルートが複数ある可能性があるため、UI ルートを含む詳細な手順でテストします。すべてのルートをテストします。後者はユーザビリティテストのように思えます。これも行う必要がありますが、テスターだけでなく外部の人も行う必要があります。

Answer 5

テスト計画とテストスイートを区別しましょう:)

テスト スイートはテスト自体のセットです

テスト計画は、テスト スイート [の一部] + 利用可能なリソース (人材、ハードウェア、時間など) です。

テスト文書に両方のバリエーション (詳細と「大まかな」) を記述しても問題ありません。詳細なテストと「大まかな」テストを別の文書に配置し、これらの文書に優先順位を付けるだけです。

次に、製品を完全にテストするのに十分な時間があれば、たとえばカテゴリ A のすべての文書を取得し、これらの文書に従って製品をテストします。時間がないが、品質について迅速に結論を得る必要がある場合は、カテゴリー B の文書を取得し、そこに記載されているチェックに合格します。

良い面：製品のテスト方法を選択できます

悪い面：「複製」書類が必要です

Answer 6

誰かが問題を見つけたときに、正確で詳細な再現手順が必要になるのはまったく問題ありません。しかし、そのようにテスト計画を作成すると、次の問題が発生する危険があります。

1) 不注意による失明 - 詳細な手順のテスト スクリプトを実行し、すべてのステップを忠実に実行して細心の注意を払って記録しているにもかかわらず、目の前にある明らかなエラーをまったく見逃している人々を私は見てきました。それは「台本になかった」からです。彼らの注意は、すべての面倒なテスト手順に集中しすぎて、文字通り目の前にある問題が見えなくなりました。

2) 非常に詳細かつ具体的な手順から一歩外れたところにあるバグをすべて見逃すことになります。顧客は製品を入手しても、詳細なテスト計画には従わないでしょう。彼らはさまざまな方法でアプリ内を移動します。彼らは考えを変えるでしょう。彼らは、あなたが予想していたよりも長い、または短い名前を持っている可能性があります。彼らは取引の途中で取引を放棄するでしょう。彼らはさまよってしまうだろう。彼らは一つの道に固執しません。そして、誰かがテストを繰り返すたびに、再びそれらのバグを見逃すことになります。

3) 「誰でもこれに従うことができる」テスト スクリプトを作成するには、信じられないほど長い時間を費やすことになります。信じてください、私はこれを完璧にするために何年も費やしましたが、それは人間には不可能です。さらに悪いことに、これを行うために無駄に費やした時間は、別の方法ではるかに有益に費やされる可能性があるため、製品の状態は悪化します。

4) 結局、大量の繰り返しをすることになり、すべてを読まないとテストの要点が何なのかを理解するのが難しくなります。テストをすばやく調べて、見逃した可能性のあるユースケースを確認するのは簡単ではありません。

テスト計画は幅広いものにし、テストを行う人が判断できるようにしてください。テストする必要がある特定の使用シナリオに関する情報、またはターゲット ユーザー グループがどのように運用したいかに関する情報がある場合は、それをテスト計画とともにテスターに​​提供します (おそらくユーザー ペルソナの形式で、あるいは単にそのままの形で)。ユースケースの形式。特定の項目にチェックを入れる必要がある場合は、チェックリストの使用を検討してください。(詳細については、Cem Kaner の優れたプレゼンテーションを参照してください)www.kaner.com/pdfs/ValueOfChecklists.pdf).

あるいは、テスト計画を短い探索的計画書として作成します。たとえば、次のようなガイダンスを与えることができます。「コールセンターのユーザーは、マウスが接続されていないワークステーションを使用することになります。顧客に代わってチケットを発行するプロセスを調査し、キーボード ショートカットのみを使用してすべてのアクティビティを完了できることを確認します。これは、テスターが「フィールド 1 にタブで入力してください」と言うよりもはるかに欠陥を発見する可能性が高くなります。「回線品質に関する苦情」と入力します。Tab キーを押してフィールド 2 に移動します。ドロップダウンメニューから「電話」を選択します。... にタブを入力します。フィールド68。」

Answer 7

テスターをシステムやコンピューター全般についての知識がないかのように扱うことには、良い点と悪い点があります。

物事を非常に詳細に説明する場合（例：「ファイル メニューから、[開く] を選択します...」) よりも利点は、システムに精通していない請負業者を使用できることです。 しかし このように書くとさらに時間がかかります

多くの詳細を省略した場合（例：「ドキュメント ファイルを開いてください...」)、あなたのテスト計画を使用する人が行き詰まって、説明を中断する可能性が高くなります。 しかし 書くほうがずっと早いです

QA 担当者にシステムを説明するのに余分な時間を費やすだけになってしまったら、きびきびバージョンを実行した方が早いと考えるのは誤った経済性になる可能性があります。

このトピックについてさらに詳しく説明した記事があります。 システムテスト計画の作成

この記事では、より詳細なアプローチを支持します。しかし私は最近、これら 2 つのアプローチの間の「中間点」を開発しています ( 機能テスト計画）、しかしまだ共有できるほど成熟した段階には達していません

-- LM