メニュー

ソフトウェアテストにおける探索的テストとは（完全ガイド）

  • メイン
  • その他
  • ソフトウェアテストにおける探索的テストとは（完全ガイド）

what is exploratory testing software testing

問題を排除するために楽器を試してください

探索的テストとは何ですか？

「探索的テスト」–名前が示すように、学習、テスト設計、およびテスト実行の同時プロセスです。このテストでは、テストの計画、分析、設計、およびテストの実行がすべて一緒に瞬時に行われると言えます。

このテストは、システムを探索し、テスターのリアルタイムで実用的な思考を促進することを目的としています。

このシリーズでは、次のチュートリアルについて説明しました。：

チュートリアル＃1： ソフトウェアテストにおける探索的テストとは （このチュートリアル）
チュートリアル＃2： ツアーを使用して完全な探索的テストを確認する
チュートリアル＃3： 探索的テストとスクリプト化されたテスト
チュートリアル＃4： HPSprinterを使用した探索的テスト
チュートリアル＃5： トップ17の探索的テストツール

************************************
探索的テスト

学習内容：

概要概要

素人の言葉で言えば、探索的テストには、テストケースの設計と、テスト対象のアプリケーションまたはシステムのテスト実行が同時に含まれます。テスターは、方向性を示すためにテストアイデアを作成または書き留め、テスト中にシステムを探索して、アプリケーションのテストを成功させるための重要で実用的で有用なテストをさらに作成します。

これには最小限の計画が必要です。テスターは、彼女の次の行動ステップについて継続的に決定を下します。それは完全にテスターの思考プロセスに依存します。

このテストは、正式なテストアプローチよりも有益な場合があります。 いくつかの微妙な欠陥を見つける 正式なテストでは欠落します。

意識的または無意識のうちに、すべてのテスターは、キャリアのある時点で探索的テストを行っていたでしょう。

ご存知のように、学習者は理論を詰め込むよりも、実践的な経験を通じてよりよく学ぶことができます。

同様に、テスターは、アプリケーション自体が提供するすべての機能を調査および学習している間のみ、アプリケーションをよりよく知ることができます。アプリケーションのテストを成功させるために、テスト中に顧客とビジネスの視点を持つことは常に良いことです。

例えば、 ショッピングサイトを開くと、このショッピングサイトでは、選択した商品を選択して料金を支払うことで買い物をすることができるという一般的な考えがあります。

このプロセス中に、Webサイトが、製品の選択プロセスに役立つ仮想の人間のそっくりさんを提供していることを知るかもしれません。また、ホームトライアル用に多数の商品を注文したり、一部の銀行のリワードポイントなどで支払いができることもわかりました。

テスターとして、システムが期待どおりに機能しているかどうかを確認するだけでなく、そのシステムが期待どおりに動作していないかどうかを確認する必要があります。

このテストを実行する際に覚えておくべきことがいくつかあります。

  • あなたの使命は明確でなければなりません。
  • バグの可能性があるため、メモを作成し、実行していることとシステムの動作についてレポートしてください。
  • 学び、観察し、新しいテストケースを考え出します。

推奨される探索的テストサービス

＃1）Digivante Direct

Digivanteダイレクトロゴ

Digivante Direct プロのテスターのグローバルネットワークを使用して探索的テストを実行し、他のテストサプライヤーや社内チームでは達成できないタイムスケールですべての主要なデバイスでのテストをカバーできるようにします。

より早く、より安全にリリースし、デジタルプラットフォームがより高い顧客満足度とオンライン収益の増加を実現できるようにします。

特徴：

  • わずか24時間で24営業日のテスト または72時間で90営業日、他の手段では達成できない比類のない包括的なレベルのテスト。
  • 低価格 、隠された余分なものがない、理解しやすい価格設定パッケージ。
  • セルフサービス 継続的な取り組みを必要としないオンラインポータル。
  • 実際のデバイスでテストする実際の人々 –社内で達成できるよりもはるかに広いデバイスとブラウザのカバレッジ、およびすべてをより速いターンアラウンドタイムで実現できます。
  • 完全な探索的テストカバレッジ –リスクを軽減し、エンドユーザーの満足度とコンバージョン率を向上させることで、コストを削減しながら収益を増やします。
=> Digivante DirectWebサイトにアクセス

探索的テストの例

例1：

次のコンポーネントを備えた在宅介護サービスプロバイダーのWebサイト：

  • ログイン
  • サービス
  • カート
  • 支払い
  • 注文履歴
  • 技術者の割り当て

開始する一般的なアイデア 探索的 テストは、ログインするか、サービスを予約することです。

テストケースをカバーする方法は？

探索的テストテストケース

最高のデータ回復ソフトウェアウィンドウ10

上記で 例、 アイデアは、あなたの知識に基づいた機能から始めることです。アプリケーションについてさらに学び、観察するにつれて、次の一連のテストケースを管理できます。

例2：

私はかつて、申請書に新しい投資信託を追加することを含む小さなプロジェクトに参加していました。私の仕事は、アプリケーションをテストして、ユーザーが新しい投資信託を購入できることを確認し、関連する評価が正しいかどうかを確認することでした。テストを完了するのにたった2日しかありませんでした。

テストの締め切りと厳しさを考慮して、私はテストの探索的アプローチを使用しました。私の目標は、新機能をテストし、互換性要件の違反を見つけることでした。

上記の目標は、このテストセッションの私の憲章になりました。

このテスト中に、次のテストケースが展開されました。

  • 新しい投資信託がアプリケーションに追加されていることを確認するためのテスト。
  • 新しいMFが正常に購入されました。
  • 新しいMFの評価は正しいです。
  • 既存のポートフォリオのために新しいMFを購入しようとしました。
  • 新しいMFをすべてのポートフォリオに追加できますか？
  • 既存の評価に対する新しいMFの影響。
  • そのため、他のテストケースでは進化しました。

テスト中にメモとレポートを作成して、BAおよび関係するクライアントと観察について話し合いました。

探索的テストの基本的な戦略は、攻撃の計画を立てることです。あなたのアイデアでテストを開始し、あなたの知識と観察に基づいて新しいテストケースを即興で作成します。

例3：

IRCTCウェブサイトの探索的テスト

=> IRCTC Webサイトの探索的テストのサンプルテストケースをダウンロードするには、ここをクリックしてください。

テストアプローチ

  • ヒューリスティックを利用してテストをガイドします。
  • テストケースの実行とテストケースの作成は密接に関連しています。
  • テストケースは、テスターの観察と学習に基づいて進化し続けます。
  • のようなさまざまなテスト手法 境界値分析 、等価性試験などをETに適用できます。
  • セッションベースのETを使用すると、より構造化され、焦点を絞ることができます。
  • テスターはそこにアイデアを分岐させることができますが、あなたの使命から逸脱することはありません。
  • ETテストはスクリプトを使用せず、代わりにテスターの直感、スキル、および経験に依存します。

利点

このテストの利点は次のとおりです。

  • リアルタイムの思考を促進し、より多くの欠陥を発見するのに役立ちます。
  • ユースケースとシナリオベースのテストを促進します。
  • 最小限のドキュメント、最大限のテスト。
  • テスターの視野を広げ、学ぶことに重点が置かれています。
  • 重複作業は避けてください。
  • 他のテスターの作業を監査する場合に便利です。

デメリット

デメリットは以下のとおりです。

  • テストは、テスターの経験、スキル、および知識に依存します。
  • アプリケーションを学ぶのに時間がかかります。テスターは、アプリケーションについてあまり知らない場合、見逃す可能性が高くなります。
  • 実行時間が長いプロジェクトには適していません。

セッションベースの探索的テスト

探索的テストを行っている間、テスターがテストした量と根拠を言葉で表現することは非常に困難です。

基本的に、作業と費やした時間を定量化することは困難です。ただし、すべてのプロジェクトで、チームリーダーとマネージャーに指標、見積もり、進捗レポートを提供する必要があります。ことわざにあるように、「定量化できなければ管理できません」。

セッションベースのテストは、このテストを実行するための時間ベースのアプローチであり、管理と追跡に役立ちます。これには、電子メール、電話、メッセージなどを中断することなく、専用のタイムボックステストセッションが含まれています。

アプローチ：

テストタスクはセッションに分割されます。

以下は、セッションベースのテスト（SBT）のコンポーネントです。

  • ミッション： ミッションはセッションの目的を叫び、ある意味でテスターに​​焦点を当てます。また、セッション期間も含まれます。
  • チャーター： テストの範囲が含まれます。基本的に、セッション中に完了する必要がある目標を詳述する議題。

在宅介護サービスウェブサイトのログイン機能のテスト憲章の例：

ログイン機能のテスト憲章の例

  • セッション： 中断することなく、事前定義されたタイムボックステストセッション。各セッションの期間は次のとおりです。
    • 「短い」（60分）
    • 「ノーマル」（90分）
    • 「長い」（120分）
  • セッションレポート： リーダーとマネージャーに指標を提供するために、メモと軽量レポートを含めます。チャーターセッションの残りまたは完了、セッションのセットアップ時間、テストされたシナリオ、テストプロセス、バグと検出された問題のリスト、およびメトリックに関するその他の情報に関する詳細が表示されます。
  • セッションの報告： テストセッションの結果を確認するための、テスターとテストリード/マネージャー間の短い会議またはスタンドアップ。

管理者は、セッションレポートに基づいて、次の指標を実践的に入手できます。

  • 完了して残っているセッションの数。
  • 報告されたバグの数。
  • セッションのセットアップに費やされた時間。
  • テストに費やした時間。
  • 問題または問題の分析に費やされた時間。
  • カバーされている機能。

上記を要約すると：

SBTは、説明責任が探索的テストであることを可能にし、テストに費やされた時間のより良い管理を提供します。また、生産性が向上し、バグ検出をより正​​確に把握できます。これは、プロジェクトの進捗状況を確認するための指標をチームリーダーとマネージャーに提供するための優れた方法です。

ペアベースの探索的テスト

ペアテストは、2人がPCを共有することにより、アプリケーションの同じもの/機能を同時にテストするアプローチです。彼らは継続的に自分の考えやアイデアを共有しています。このテストでは、1人がキーボードを担当し、もう1人がテストケースを提案してメモします。

パートナー間で良好なコミュニケーションを取り、両者が何が行われているのか、そしてその理由を認識できるようにすることは常に役に立ちます。テスターの強さが相互に弱さを補完するペアは、強いグループと見なされます。

このようなペアリングは、当事者の両方に利益をもたらし、それぞれがパートナーから何かを学ぶことができます。また、経験豊富なリソースと組み合わせて、新しいリソースをトレーニングするための良い方法でもあります。

ペアテストの利点

  • テスターが目前のタスクに集中するのに役立ちます。
  • パートナー間の相互信頼と尊重を奨励します。
  • 通常、ペアのテスター間でブレインストーミングを行うと、より建設的なアイデアが生まれます。
  • トンネル視を避けてください。
  • 他の人がそれらを妨害する可能性は低くなります。

探索的テスト手法

ツアー： これは、テスターが自分の想像力を使って、自分が訪れた都市を探索する観光客であると考えることができる簡単なテクニックです。ここでテストするアプリケーションは都市であり、テスターは観光客です。時間とお金が足りない限り、街全体を探索するのは非常に難しいので、観光客は特定の目標を念頭に置いて計画を立てる必要があります。

観光客は次のツアーに参加できます。

  • ガイドブックツアー –アプリケーションの強調表示された機能をテストします。ユーザーベースのシナリオを使用します。
  • 街の歴史を探る –アプリケーションの古い機能をテストします。
  • マネーツアー、 これは、顧客またはクライアントに関連するすべての重要な機能がテストされ、正常に機能していることを確認することを意味します。
  • 犯罪まくるツアー –無効な入力を入力し、否定的なシナリオをテストします。
  • 路地裏ツアー –アプリケーションの最も使用されていない機能をテストします。
  • 退屈なツアー –アプリケーションの各画面で最小限の時間を費やし、最小限のフィールドに入力して、最短パスを使用します。これは、デフォルト値と検証テストに役立ちます。

ツアーに参加している間は、いつでもどのルートを選択することもできます。ソフトウェアをナビゲートして、機能をテストするための一意のパスを見つけることができます。

以下は、ETで使用できるいくつかのヒント/コツです。

  • アプリケーションをモジュールに分割し、モジュールを異なるページに分割します。ページからETを開始します。これにより、適切なカバレッジが得られます。
  • すべての機能のチェックリストを作成し、それがカバーされたらチェックマークを付けます。
  • 基本的なシナリオから始めて、徐々に拡張して、テストする機能を追加します。
  • すべての入力フィールドをテストします。
  • エラーメッセージをテストします
  • すべてのネガティブなシナリオをテストします。
  • GUIを標準と照合してください。
  • アプリケーションと他の外部アプリケーションとの統合を確認してください。
  • 複雑なビジネスロジックを確認します。
  • アプリケーションの倫理的なハッキングを試みてください。

ETに影響を与える要因は次のとおりです。

  • プロジェクトの目的
  • テスト戦略
  • 特定のフェーズのテスト目標
  • 利用可能なツールと設備
  • テスターの役割とスキル
  • 利用可能な時間
  • 管理サポート
  • ピアサポート
  • 利用可能なリソース（学習資料、テスト条件など）
  • クライアントの関心
  • 製品の理解しやすさ。
  • アプリケーションのUI
  • アプリケーションの機能
  • 以前のテスト結果
  • アプリケーションに関連するリスク
  • 以前の欠陥
  • 最近の変化
  • テストに使用するデータの種類
  • それを使用するユーザーのタイプ

テスターに​​何を実行するかを尋ねる代わりに、テスターの判断に任せて、何をテストし、どのようにテストするかを決定します。

探索的テストとアドホックテストの違い

ETと混同しないでください アドホックテスト 。

  • アドホックテストとは、スクリプト化されていない、計画されていない、即席の欠陥検索のプロセスを指しますが、探索的テストは、アドホックテストに対する思慮深い方法論です。
  • アドホックテストはバグを見つけるためのヒットとトライアルの方法ですが、ETはそうではありません。 ETアプローチでは、テスターは、取得した知識を使用してテストを探索し、最終的に進化させるときに、システムについて学習します。
  • アドホックテストは構造化されていないアクティビティですが、ETは構造化されたアクティビティです。

探索的自動テスト（EAT）

探索的自動テストは、テスターがバグの報告と再現、スナップショットの収集、および将来の回帰訴訟の準備を合理化するのに役立つ方法です。これは、自動化テストと探索的テストを組み合わせたプロセスです。

EATアプローチには2つのタイプがあります。

  • パッシブEAT
  • アクティブEAT

パッシブEAT

パッシブEATは、1人のテスターまたはペアで実行することもできます。この方法では、通常、テストリソースによって実行されたすべてのアクティビティをキャプチャして記録し、リソースのPCにインストールされるツールです。

パッシブEATは、キャプチャされたセッションに基づいてテスト結果を作成する以外に、テストの実行方法に変更がないため、手動で実行されるETに似ています。これらのテスト結果は、記録されたアクションを後でレポートおよび再現するために使用できます。

インストールされたビデオツールは、テストケースの記録と欠陥の報告でテスターを支援します。

また、次のような他の利点もいくつかあります。

  • バグを再現するための明確な手順を提供します。
  • 欠陥レポーターが利用できない場合でも、欠陥の再現は簡単です。
  • 断続的なバグが報告された場合は、テストチームと開発チームの間の競合を解消してください。
  • 特定の時点でのシステム応答時間を取得することにより、パフォーマンステストに役立ちます。

パッシブEATの前に考慮すべき他のいくつかのポイントは次のとおりです。

  • Automated EATにツールを完全に適合させる前に、パイロットテストを実行することをお勧めします。これは、テストセッション中に作成されたテストログの再設計に必要な時間がテストの実行を超えないようにするためです。 その場合、チームは次の点について相互に決定する必要があります。
    • 特定のプロジェクトでテストの自動化が必要な場合。
    • 使用している工具を変更する必要がある場合。
    • 使用しているツールのパフォーマンスを最適化できるかどうか。
  • 自動EATの実行に使用するツールは、テストに関係するすべてのテストリソースにインストールする必要があります。また、開発者にVPNまたはテストマシンへのリモートアクセスを提供するか、開発環境にツールをインストールすることで実現できる開発者を関与させることもお勧めします。
  • アプリケーションのGUIオブジェクトをテストツールで整理して、バグや問題を分析するときが来たときに、意味のある名前でオブジェクトを認識できるようにすることをお勧めします。
  • AUTで使用されるGUIオブジェクトに意味のある名前を付け、後で使用できるように整理しておくことをお勧めします。

それでは、2番目のアプローチに移りましょう。

アクティブEAT

ペアテストでアクティブEATを実行することをお勧めします。このアプローチでは、キーワード駆動型テストがセッションテストと同期して使用されます。 1人のテスターが自動テストスクリプトを作成し、2人目のテスターが最初のテスターが作成したテストスクリプトを実行します。

このアプローチでの自動化テストスクリプトの作成は、従来のテストとは異なるパスを取ります。自動化されたテストスクリプトはテスト中に作成され、以前のテストで発見されたものがそれらの設計を決定します。

クローズフェーズは、テストセッションの最後に実行されます。また、次のタスクが必要です。

  • 関係するテスターは、テストスクリプトを作成したテストリソースがスクリプトを再実行して、作成されたスイートの信頼性と堅牢性を確認できるように、役割を交換する必要があります。
  • 自動化されたテストスクリプトごとに、簡単な説明といくつかの識別特性を提供する必要があります。
  • 回帰テストに使用できる自動テストスクリプトを特定するための基準を定義する必要があります。

EATのメリット

  • 各セッションの開始時に、作成済みの自動テストスクリプトが実行されるため、毎回テストカバレッジが向上します。
  • 欠陥再現のためのより良いバグ報告と文書化。
  • EATは、利害関係者が進捗状況を確認するのに十分な証拠と文書を提供します。

探索的テストの種類

ETのいくつかのタイプを以下に示します。

1）フリースタイルAND：

アドホックスタイルでのアプリケーションの調査。

このタイプのETには、ルールやカバレッジの説明などはありません。ただし、このタイプのテストは、アプリケーションにすばやく精通する必要がある場合、他のテスターの作業を検証する必要がある場合、および欠陥を調査したい、または簡単なスモークテストを実行したい。

2）シナリオベースのET：

名前自体が示すように、実行されるテストはシナリオベースです。それは、実際のユーザーのシナリオ、エンドツーエンドのシナリオ、またはテストシナリオから始まります。最初のテストの後、テスターは学習と観察に従ってバリエーションを注入できます。

シナリオは、ET中に何をすべきかについての一般的なガイドのようなものです。テスターは、シナリオの実行中に複数の可能なパスを探索して、機能が機能するためのすべての可能なパスを確認することをお勧めします。テスターはまた、さまざまなカテゴリからできるだけ多くのシナリオを収集する必要があります。

3）戦略ベースのET：

探索的テストと組み合わせた、境界値分析、同等性テクニック、リスクベースのテクニックなどの既知のテストテクニック。このタイプのテストには、経験豊富なテスターまたはアプリケーションに精通したテスターが任命されます。

ソフトウェア工学におけるライフサイクルモデル

アジャイル探索テスト

アジャイル環境で働いたことがなくても、人気が高まっているので、読んだり聞いたりしたに違いありません。アジャイル手法はスプリントが短く、期限が厳しいため、チームは計画、見積もり、開発、コーディング、テスト、リリースを完了するのに数週間かかります。

このテストアプローチでは迅速で有用な結果に重点が置かれているため、探索的テストはこのような厳しい締め切りで便利になります。要件を理解したら、経験と知識に基づいてテストを開始できます。

アプリケーションの機能と動作に慣れたら、アプリケーションの機能を検証し、計画外のバグを検出するためのテストケースをさらに設計できます。これはフリースタイルのテストアプローチであるため、すべてを文書化する必要があります。ただし、テストした内容、見つかったバグや問題などに関するメモと簡単なレポートを維持する必要があります。

アジャイルにおける探索的メリット

  • できるだけ早く開発者にフィードバックを提供します。
  • さまざまな欠陥が発見されています。
  • スクリプト化されたテストケースがなく、それぞれが異なる視点をもたらすため、開発者、テスター、BA、設計者などのリソースの多様なグループがETを実行できます。
  • ETで行われる偵察は、新しい領域を探索し、重大なバグを明らかにするのに役立ちます。
  • アプリケーションの反復コーディングの場合、ETは新機能のテストに集中でき、自動化はリグレッションと下位互換性のテストを行います。
  • 要件が不安定な場合、ETは限られた時間内に新しい要件をテストするのに役立ちます。

覚えておくべきポイント：

1.さまざまなスキルが必要です。 ETを実行するテスターは、優れたリスニング、リーディング、思考、およびレポートのスキルを持っている必要があります。スクリプトやテストケースがないため、ドメインの経験が必要です。

2.時々難しい バグを報告： ETフローでは、欠陥が発生する可能性がありますが、再現できない場合があります。これは、テスト手順を追跡しておらず、その問題を再現するための正確な手順を忘れている可能性があるためです。

3.レクリエーション活動として行うことができます： 通常のテスト実行サイクルから抜け出したいときは、個人的にETを実行します。しかし、多くのチームは、テストサイクルの別個のフェーズとしてETを持っています。

4.すべてのテストフェーズで実行できます。 テストフェーズの開始前にETを実装できます。機能テストフェーズの前でもETを実行できます。

5.迅速なフィードバック： ETは、問題や発生した異常について迅速なフィードバックを必要とします。

6.6。 批判的思考 と多様なアイデア： このテストには批判的思考が必要です。テスターは、論理的な方法でアイデアを再現、レビュー、表現できる必要があります。テスターは、自分が取り組んださまざまなテクノロジーやドメインでの経験を実装できます。

探索的テストで従来のテスト境界を超えて考える方法

「この製品に対するあなたの懸念と、エンドユーザーの視点を理解する上で私たちを助けてくれたことに本当に感謝しています。とても役に立ちます。良い仕事をありがとう、そしてそれを続けてください!!!」

これは、クライアントからの21通の電子メールを含む電子メールチェーンの最後の電子メールでした。真夜中だったのですが、重大なバグが見つかったため、製品のリリースが遅れました。あなたは、その中で何が新しいのかと思うかもしれません。それは何度も起こるかもしれません。しかし、私たちが報告した重大なバグは文書化されたテストケースの結果ではなかったため、これは実際には異なっていました。

完了後 回帰試験 その夜最後に、私はちょうど製品で遊んでいました。どういう意味ですか？あなたはあなたがすることになっていないことを自由に行うことができます。私の経験とプロジェクトの知識に基づいて、通常のテストリポジトリとは別に製品をテストする方法についていくつかのアイデアがありました。 と呼ばれる 探索的テスト 。

行われた探索的テストでは、予期しないことを行っているときにサーバーのハングの問題に関連する重大なバグが見つかりました。

探索的テストのファンである私は、さまざまな方法で製品を探索するのが大好きです。 私にとって、ソフトウェアの定義は次のとおりです。

「それはそれがすることになっていることをするべきであり、そしてそれはそれがすることになっていないことをするべきではありません。」

探索的テストプロセス

テストの境界を制限して、機能するはずの製品が機能しているかどうかを確認すると、テスターが不完全になります。実際、テスターの人生は、文書化された回帰テストが終了し、結果が更新されたときに始まります。さまざまな視点から製品を見て、さまざまなシナリオでエンドユーザーの要件を理解することは、大きな違いを生みます。それでは、今日、その違いをどのように生み出すことができるかを一緒に理解しましょう。

さまざまな視点から製品を見る方法は？

探索的テスト

＃1。顧客/エンドユーザーを理解する

ソフトウェアテストとは、顧客満足度の観点から製品の品質をチェックすることです。顧客の視点をどのように知っていますか？答えは簡単です-あなたは顧客でなければなりません。 OK、訂正させてください。顧客であることは十分ではありません。顧客が製品をどのように扱いたいかを理解する必要があります。同じ原材料を購入した2人の顧客が同じレシピを準備することはありません。はい、私たちが開発/提供する製品は、お客様のビジネスの原材料であり、使用中の考え方が異なります。

ソフトウェアテスターとして、製品の目的や側面ではなく、製品の目的を確認する必要があります。

実際の実用的な例をいくつか挙げましょう。

  • はさみは切り紙だけに限定されることはありませんでした。カットは目的であり、紙（オブジェクト）ではありません。
  • 携帯電話は電話だけにとどまらず、「電話ができる」ことが常に基本的な目的でした。
  • 保管箱は保管に使用されますが、保管される材料の安全性は保管と同じくらい重要です。

利害関係者とその幅広い期待を理解することは、探索的テストのベースラインとなるはずです。

＃2。考え方

求人広告を探しているときに（たとえば）、その大当たりと太字のフォントがページの間に表示されていますか？私たちのほとんどはそうしません（私を信じてください、それは本当です）。何が役に立つのか、何をチェックするのかを心に指示したからです。それ以外は役に立たないので、精神は私たちがそれを認識することを否定します。

心を開いて、製品の探索を開始するときに期待を設定しないでください 。製品が本来の機能を果たしているかどうかは問題ではないことを常に忘れないでください。また、本来の目的を果たさないことも重要です。

私は1つの古典的な例を覚えています：

Linuxでは、「cat」コマンドを使用してファイルの内容を確認し、「ls」コマンドを使用してディレクトリの内容を確認します。 Linuxで作業し、5年間ソフトウェアのテストを行っていたので、頭が決まったので猫をやろうとは思いませんでした。 dirコンテンツが必要な場合は、「ls」を使用する必要があります。それはうまくいきましたが、期待の裏側は、製品が想定されていたように動作するはずがなかったということです。 Linuxをよく知らなかったお客様の1人が誤って猫を飼い、システムがクラッシュしました。私たちはこの考え方にお金を払いました。

エンドユーザーがやろうとしていることなので、常にソフトウェアを間違える準備をしてください。 ソフトウェアをテストするために、あなたは訓練を受けていますが、エンドユーザーはあなたほど訓練されていません または彼/彼女はあなたほど技術的な専門家ではないでしょう。また、困ったときはソフトウェアで何でもします。

それらのシナリオについて考え、テストのフィードバックを提供します。ソフトウェアと（テスターとしての）あなたの人生は揺らいでいます。

＃3。競合他社を知る

クライアント用のソフトウェアアプリケーションをテストしているときに、同じ目的で他のソフトウェアを知り、理解しようとしたことがありますか？競合他社の製品で観察した便利な機能を提案したことはありますか？それは私たちの仕事の説明には当てはまりません、それが典型的な答えです。しかし、あなたはそれをすることの利点を知っていますか？

ここに、要点を理解させるための実際の例をいくつか示します。

  • ドレスをステッチするだけでなく、一致するアクセサリーについての情報を提供するデザイナーが好きではありませんか？
  • 素晴らしいピザを作るだけでなく、宅配便を最も時間どおりに配達するピザブランドが好きではありませんか？
  • 良い写真を撮るだけでなく、写真撮影のために別の種類のフレームを提案する写真家が好きではありませんか？

誰もが彼らが支払うもののために何か特別なものを持ちたいと思っています。競合ソフトウェアの分析は、同じように機能します。 顧客は常に価値のある提案を聞くことを好みます。主に、製品をより有用または市場性のあるものにするための比較提案です。

また、このような同じ範囲の製品の比較と分析により、分析がより強力になり、最終的にはいつでも戻って役立つものを見つけることができる宝物が作成されます。

結論

探索的テストは、従来のテスト方法には当てはまりませんが、それでも非常に強力なテスト方法です。

テスターの独創的な思考を引き出し、欠陥を見つけるための実用的でリアルタイムのテストケースを考え出すように促します。そのフリースタイルの性質により、他のテストタイプよりも優れており、アジャイルやウォーターフォールを使用するプロジェクト、または最小限のドキュメントを必要とするその他のプロジェクトなど、どこでも実行できます。

探索的テストの成功は、テスターのスキル、効果的なテストケースを作成する能力、経験、腸の感覚に従うコツなど、多くの無形資産に依存します。

ETは予測プロセスではなく適応プロセスであり、探索的テストとスクリプトテストまたは定期テストの間の健全なバランスを維持することが不可欠であることを覚えておく必要があります。

あなたは典型的な探索的テストの経験を持つテスターですか？ご意見をお待ちしております。以下のコメントセクションでそれらを自由に共有してください。

次のチュートリアル＃2： ツアーを使用して完全な探索的テストを確認する方法

推奨読書

^