Planning For Ad Hoc Testing
この記事では、アドホックテストについて、その種類、メリット、デメリット、およびアドホックテストを実施するためのベストプラクティスを取り上げました。
アドホックテストとは？
アドホックテストは時に「ランダムテスト」または「モンキテスト」としても呼ばれますが、非公式のテストの一種として定義されます。 このプロセスの目的は、型破りな方法を使用してシステムを破壊することです。 このタイプのソフトウェア テストは一般に無計画で、テスト ケースを作成するための特定のテスト設計技術に従いません。
アドホック テストの主な目的は、ランダムにチェックすることで欠陥を見つけることです。 テスト者は、任意に実行することによって、ステップを即興で作成します。
アドホック テストの最も驚くべき側面は、テスト設計技法を一切含んでいないことです。 つまり、この方法では、通常は見つからないような不具合が見つかるものの、テストケースや文書がないため、再現するのがより困難です。 アドホックテスト技法は、「非構造化テスト」カテゴリに直接該当します。
Structured Vs. Unstructured Testing
Structured Testing
このアプローチにより、テストケースの作成から連続実行まで、テスト手順の間に行われるすべての活動はスクリプト化されていることが確認されました。
非構造化テスト
この方法は、エラーを推測してテストを行うものです。
Types of Ad Hoc Testing Method
Buddy Testing
このタイプのアドホックテストは最低2人で実施するものである。 モジュールのユニットテストが実施され、完了した後に行われる。 このタイプのテストは、システムテストとユニットテストの両方の組み合わせと考えることもできます。
主な目的は、2人の「バディ」が同時に同じモジュールの欠陥やバグを特定することに取り組むことです。 このチームは一般に、1 人のソフトウェア開発者と 1 人のソフトウェア テスターで構成されます。
2人の「仲間」は、有効なテスト ケースを作成するためにそのモジュールで一緒に作業します。 このプロセスは、無効なテストケースが生成した可能性のあるエラーをテスターが報告しないようにします。
Buddy testing は、テスターがより良いテストケースを開発するのを助け、開発チームができるだけ早く設計変更を行うことを可能にするため、成功していることが証明されています。 モンキー テストは、ユニット テスト レベルで最も一般的に行われます。 ここでは、テスト担当者は、テストケースなしでランダムにアプリケーションまたは製品をテストします。 テスト担当者の主な目標は、完全にランダムな方法でデータまたはテストを分析し、システムがどんなクラッシュにも耐えられるようにすることです。
テスト担当者は、ソフトウェアにランダムな入力を与え、対応する出力を観察します。 出力データに基づいて、エラーや矛盾、システムクラッシュをよりよく判断できます。
ペアテスト
ある意味で「バディテスト」に似ている「ペアテスト」は、テスト対象のモジュールに対して、一対のテスターが一緒に作業することを含みます。 2 人のテスターは、欠陥やエラーを特定するために、同じマシン上でアイデアや知識、意見を共有します。
このテスト方法では、専門知識や知識のレベルに応じてペアになったテスターを使用し、特定した問題に対して異なる洞察を可能にします。 2 人のテスターは同じセットアップを共有し、また、テストの作業を共有し、2 人の間ですべての観察を文書化します。 このテスト方法では、一方のテスターがテストを実行し、もう一方のテスターが調査結果についてメモを取ることもできます。 よりよい受け入れテストのためにペアテストを使う
Buddy vs. Pair Testing
バディテストとペアテストの主な違いは、バディテストがユニットテストとシステムテストの組み合わせであるということです。 もうひとつの重要な違いは、バディテストは開発者とテスターが一緒に実行することです。
When And When Not To Conduct Ad hoc testing
Ad hoc testing は、より長く、より徹底したテストプロセスを実行する時間がない場合によく実施されるものです。 より徹底したテスト方法には、テスト要求文書、テストケース、およびテストケース設計の作成が含まれます。
アドホックテストを実施する理想的な時期は、すべての公式テスト技法が完了した後です。 しかし、アドホックテストは、ソフトウェア開発の途中、ソフトウェアの完全な開発後、またはいくつかのモジュールがすでに開発された後でも行うことができます。
アドホックテストが推奨されないいくつかのシナリオに注意することが重要です。 アドホック テストを実施すべきでない条件には、次のようなものがあります。
ベータ テストを実施しているとき
すでにエラーがあるテスト ケース
Advantages Of Ad Hoc Testing
アドホック テストの主なメリットは、通常、正式なテスト方法では気づかないエラーを特定できることです。 構造化されたテストのような計画を必要としないので、これは多くの時間を節約できます。
別の利点は、テスターが、アプリケーションの自分の知識と理解に従って、自由にアプリケーションを探索することができることです。 3905>
第三に、テストケースを必要としないため、アプリケーションのテスターおよび開発者は、自分自身で簡単にアプリケーションをテストできます。 これは、開発者がより効率的でバグのないコードを簡単に作成することを可能にします。
アドホックテストは、他のテスト技術と組み合わせて、全体としてより効果的で有益な結果を生み出すためにその後実行することもできます。
Disadvantages Of Ad Hoc Testing
アドホックテストの主なデメリットは、実際のテストプロセスが特定のテストケースに従っていないので文書化されていないことです。 これは、テストがエラーを再生成することをより困難にします。 なぜなら、そのエラーを取得するために、テスト者は、そこに到達するために彼/彼女が取った正確な手順を覚えておく必要がありますが、それは常に可能とは限りません。
時折、テスト者が開発した無効なテストケースの結果として、無効なエラーが報告されることがあります。 これは、以下のエラー修正処理で問題になることがあります。 テスト担当者がテスト対象のアプリケーションの機能について予備知識を持っていない場合、アドホック テストは役に立たず、エラーを特定することはできないでしょう。 アドホック テスティングの成功は、テスト担当者のスキルと知識に依存しています。 事前に作成または文書化されたテスト ケースがないため、これらのテストに費やされる時間、労力、およびリソースの量は不特定なままです。 3905>
Best Practices When Conducting the Testing
Tests that are not conducted in the right way is caused unnecessary time wastage. このことを念頭に置いて、成功するアドホックテストを効率的に行うために、プロセスを最適化する方法を知ることが重要です。
以下のベストプラクティスは、プロセスに費やす時間を、望ましい結果を得るための最善のチャンスに賢く費やすことを保証します。 より良い「エラー推測」を確実にするために、テスト者はアプリケーションのすべての主要な機能に精通していることが重要です。 正しい知識があれば、テスト担当者はより多くのバグ、エラー、および一般的な矛盾を見つけることができます。
Identify Areas Likely To Have Errors
テスト担当者がアプリケーションに精通していない場合、アプリケーションのエラーが起こりやすい領域を特定し、そこから始めることが推奨されています。
Prioritize Areas The End-User Accesses Most Readily
顧客およびエンドユーザーによって最も使用されているアプリケーションの領域をテストすることから始めます。 そうすることで、重要な機能を最初に評価し、バグを事前に報告することができます。
Loosely Formulate The Test Plan
アドホックテストは事前の計画や文書を必要としませんが、事前に大まかな計画を立てることは役に立ちます。 テストが必要な主な領域を書き留めておくことは、テスト担当者が最短時間で可能な限り多くの領域をカバーするのに役立ちます。 テスト中に例外が識別されない場合があるため、これらは、エラーを分離するテスト担当者の能力を補います。 その代わりに、その場しのぎの性質により、また、創造力があり、アプリケーションの機能についての予備知識を持っているテスターを選択することにより、時間を節約できます。
Join 60,000+ Subscribers
For latest blogs, industry updates and exclusive tips.
*Your email is safe with us, we also hate spam
Leave a Reply