探索的テストとは何ですか?
トーマス・ハミルトン
⚡ スマートサマリー
探索的テストとは、テスト担当者が事前にスクリプトを作成せずにテストケースを設計・実行するテスト手法であり、調査、学習、そしてテスト担当者の直感を重視して、スクリプト化されたテストでは見逃されがちな欠陥を発見することを目的としています。アジャイル開発で広く用いられています。
探索的テストとは何ですか?
探索的テスト ソフトウェア テストの一種で、テスト ケースは事前に作成されず、テスターがその場でシステムをチェックします。 テストを実行する前に、何をテストするかについてのアイデアを書き留める場合があります。 探索的テストでは、「思考」アクティビティとしてのテストに重点が置かれています。
探索的テストはアジャイル モデルで広く使用されており、発見、調査、学習がすべてです。 これは、個々のテスターの個人の自由と責任を強調します。
なぜ探索的テストを行うのか?
スクリプト化されたテストでは、最初にテスト ケースを設計し、その後テストの実行を進めます。一方、探索的テストは、テストの設計とテストの実行を同時に行うプロセスです。
スクリプトによるテスト実行は、通常、思考を必要としない作業であり、テスターはテスト手順を実行し、実際の結果と期待される結果を比較します。このようなテスト実行作業は、高度な認知能力を必要としないため、自動化が可能です。
ソフトウェアテストの現在の傾向は、 オートメーション、探索的テストは新しい考え方です。 自動化には限界がある
スクリプト化されたテストと探索的テストの違い
| スクリプト化されたテスト | 探索的テスト |
|---|---|
| 要件から導かれる | 要件から指示され、テスト中に調査 |
| 十分な事前のテストケースの決定 | テスト中のテストケースの決定 |
| 要件を満たしたテストの確認 | システムまたはアプリケーションの調査 |
| 予測と意思決定を重視する | 適応性と学習を重視する |
| 確認済みのテストが含まれます | 調査が含まれる |
| テストの制御に関するものです | テスト設計の改善についてです |
| スピーチをするのと同じように、草稿から読み上げるのです | 会話をするように、それは自然なことです |
| スクリプトが制御しています | テスターの心はコントロールされています |
探索的テスト手法
- ランダムなテストではなく、バグを見つけることを目的としたアドホックなテストです
- 構造化されていて厳格である
- スクリプト化されたテストの手順構造と比較して、認知的（思考的）に構造化されています。この構造は、憲章、タイム ボックスなどから来ています。
- 非常に教えやすく、管理しやすい
- それはテクニックではありませんが、アプローチです。 次に実行するアクションは、現在実行している内容によって決まります
探索的テストの実行方法
以下は、セッション ベース テスト管理 (SBTM サイクル) とも呼ばれる探索的テストを実行する方法に関するステップ バイ ステップのプロセスです。
ステップ 1) バグ分類法 (分類) を作成する
- 過去のプロジェクトで見つかった一般的なタイプの障害を分類する
- 問題や障害の根本原因分析を分析する
- リスクを見つけて、アプリケーションをテストするためのアイデアを開発します。
ステップ 2) テスト憲章
- テスト憲章は次のように提案する必要があります
- 何をテストするか
- どのようにテストできるか
- 見るべきものは何か
- テストのアイデアは探索テストの出発点です
- テスト憲章は、エンドユーザーがシステムをどのように使用できるかを決定するのに役立ちます
ステップ3) 時間 Box
- この方法には、90 人のテスターが協力して XNUMX 分以上作業することが含まれます。
- 90 分間のセッションには中断時間があってはならない
- タイムボックスは45分延長または短縮できます
- このセッションでは、テスターがシステムからの応答に反応し、正しい結果に備えるよう促します。
ステップ4） Rev結果を見る
- 欠陥の評価
- テストから学ぶ
- カバーエリアの分析
ステップ5) 報告会
- 出力結果の集計
- 結果を憲章と比較する
- 追加のテストが必要かどうかを確認する
ベストプラクティスの探索的テスト
探索的実行中は、次のことを行う必要があります。
- テストの使命は非常に明確でなければなりません
- 何をテストする必要があるのか、なぜテストする必要があるのか、製品品質の評価をメモしておきます。
- Tracking 探索的テスト中に提起された質問と問題点
- 効果的なテストを行うにはテスターをペアにすることをお勧めします
- テストをすればするほど、必要なシナリオに対して適切なテスト ケースを実行できる可能性が高くなります。
文書を取って以下の点を監視することが非常に重要です。
- テストカバレッジ – テストケースのカバレッジについてメモを取り、ソフトウェアの品質を向上させたかどうか
- リスク – どのリスクをカバーする必要があり、どれがすべて重要ですか?
- テスト実行ログ – テスト実行の記録
- 問題/質問 – システムに関する質問と問題についてメモを取ります。
よりスマートな探索的テストにより、より短い時間でより多くのエラーが発見されます。
探索的テストの長所と短所
優位性
- このテストは、要件ドキュメントが利用できない場合、または部分的に利用できる場合に役立ちます。
- これには、通常のテストよりも多くのバグを発見するのに役立つ調査プロセスが含まれます。
- 他のテスト手法では通常無視されるバグを発見します
- より多くのテスト ケースを実行することでテスターの想像力を拡張し、最終的に生産性も向上します。
- このテストはアプリケーションの最小部分までドリルダウンし、すべての要件をカバーします。
- このテストはあらゆる種類のテストをカバーし、さまざまなシナリオやケースをカバーします。
- 創造性と直観力を促進します
- テスト実行中の新しいアイデアの生成
デメリット
- このテストは純粋にテスターのスキルに依存します
- テスターのドメイン知識によって制限される
- 実行時間が長い場合には不向き
探索的テストの課題
探索的テストには多くの課題があり、それらについては以下で説明します。
- アプリケーションやソフトウェア システムの使い方を学ぶのは困難です
- 失敗の再現は難しい
- ツールを使用する必要があるかどうかの判断は困難な場合があります
- 実行するのに最適なテスト ケースを決定するのは難しい場合がある
- レポートには実際の結果や結果と比較するための計画されたスクリプトやケースが含まれていないため、テスト結果のレポートは困難です
- 実行中のすべてのイベントを文書化するのは困難です
- 探索的テストには実行する明確なテストケースがないため、いつ停止するかを判断することが困難です。
探索的テストをいつ使用するか?
探索的テストは次の場合に広範囲に使用できます。
- テストチームには経験豊富なテスターがいます
- 早期の反復が必要です
- 重要なアプリケーションがあります
- 新しいテスターがチームに加わりました
