メニュー

アドホックテスト：正式なテストプロセスなしで欠陥を見つける方法

ad hoc testing how find defects without formal testing process

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

アドホックという用語は、構造の欠如または系統的ではない何かを意味します。あなたが話すとき アドホックテスト 、それはそれがの形であることを意味します ブラックボックス または、正式なプロセスを実施せずに実行された行動テスト。

ここでの正式なプロセスとは、要件ドキュメント、テストプラン、テストケース、および実行されるテストのスケジュールと順序に関する適切なテスト計画などのドキュメントを用意することを意味します。また、テスト中に実行されたアクションは通常、文書化されていません。

アドホックテスト

これは主に、テストサイクル中に行われる従来のプロセスまたは正式なプロセスでは捕捉できない欠陥や欠陥を発見することを目的として行われます。

すでに理解されているように、このテストの本質は、正式なまたは構造化されたテスト方法がないことにあります。このようなランダムなテスト手法を実行すると、次のことが明らかになります。 テスターは、システムを破壊することを目的として、特定のユースケースを考慮せずにこれを実行します。

したがって、そのような直感的または創造的なテスト方法論が必要とすることは間違いなくさらに明白です テスターは、非常に熟練し、能力があり、システムに関する深いノウハウを持っている必要があります。 アドホックテストは、実行されたテストが完全であることを保証し、テストバケットの有効性を判断するのに特に役立ちます。

推奨読書=> 探索的テスト–従来のテスト境界を超えて考える方法は？

学習内容：

アドホックテストの例から始めましょう

これは、UIウィザードに関してこのテストを実行する方法の例です。

このUIウィザードを使用して実行するある種のタスクの計画またはテンプレートを作成する必要があるとします。ウィザードは、名前、説明などのユーザー入力がある一連のペインです。

ウィザードが進むにつれて、たとえばペインの1つで、ユーザーデータを入力します。これには、UIウィザードがコンテキストポップアップボックスをスローし、関連データを追加してウィザードを完了し、ウィザードを展開/アクティブ化します。

このテスターをテストするには、次のような定期的なテストを行います。

アンドロイドのための最高のmp3曲ダウンローダー
  • すべての有効なデータを使用してウィザードを正常に完了し、計画を作成します。
  • ウィザードを途中でキャンセルします。
  • ウィザードを使用して、作成したプランを編集します。
  • 作成したプランを削除し、残りがないことを確認します。
  • ウィザードに負の値を入力すると、適切なエラーメッセージが表示されます。

さて、上記の例では アドホックテストのテストケースを次に示します。 実行できる できるだけ多くの欠陥を発見するには：

  • 負のデータを追加しようとしているときに、適切に処理されるかどうかを確認するために制限されていない特定の特殊文字を追加します。 例えば、 ウィザードが{または(中括弧を制限しない場合もありますが、特定の状況では、これは、記述されている言語に基づくコードと競合し、非常に信頼性の低い動作を引き起こす可能性があります。
  • 別のテストは、特にポップアップに関するものです。ユーザーはポップアップを起動させてから、キーボードのバックスペースボタンを押そうとすることができます。そうすると、バックグラウンドウィザードが完全に消え、ポップアップが起動するまでに入力されたユーザーデータ全体が失われることに何度も気づきました。

アドホックテストの特徴：

上記のシナリオに注意すると、このタイプのテストの非常に明確な特徴がわかります。

彼らです：

  • それらは常にテストの目的に沿っています。ただし、これらはシステムを破壊する目的で実行される特定の抜本的なテストです。
  • テスターは、テスト対象のシステムに関する完全な知識と認識を持っている必要があります。このテストの結果、テストプロセスの抜け穴を浮き彫りにしようとするバグが見つかりました。
  • また、上記の2つのテストを見ると、それに対する自然な反応は次のようになります。この種のテストは、関連する欠陥がない限り再テストを実行できないため、一度だけ実行できます。

アドホックテストはいつ行いますか？

確かに百万ドルの質問！

ほとんどの場合、テストチームは、限られたタイムライン内でテストするには機能が多すぎるという負担を常に負っています。その限られた期間の中で、正式なプロセスから派生した多くのテスト活動も完了しなければなりません。このような状況では、テストへの道を見つけるアドホックテストはスリムです。

ただし、私の経験から、1回のアドホックテストでは、製品の品質に驚かされ、多くの設計上の問題が発生する可能性があります。

アドホックテストは、構造化する必要のない「ワイルドチャイルド」テスト手法であるため、一般的な推奨事項は、現在のテストバケットの実行が完了した後に実行する必要があることです。もう1つの観点は、これは、時間が短いために詳細なテストを実行できない場合に実行できるということです。

私の見解では、 アドホックテストは、最初、途中、最後に向けて、ほぼいつでも実行できます。 それはいつでもその場所を見つけるだけです。ただし、最大値を引き出すためにアドホックテストを実行する必要がある場合は、テスト対象のシステムについて深い知識を持っている経験豊富なテスターが判断するのが最適です。

いつ実行しないのですか？

前の質問が100万ドルの価値がある場合、これは10億ドルの価値があるはずです。

アドホックテストがどれほど効果的で実り多いものであるかを確立しましたが、熟練した有能なテスターとして、このタイプのテストに投資しない場合を解読する必要もあります。テスターの裁量ですが、ここにあります それが必要でないかもしれないときのいくつかの推奨事項/例。

  • 欠陥が存在するテストケースがある場合は、このテストを避けてください。このような状況では、テストケースの障害点を文書化し、修正されたときに欠陥を検証/再テストする必要があります。したがって、ここでは適用されません。
  • 顧客またはクライアントが招待される可能性がある特定のシナリオもあります ソフトウェアのベータ版をテストする 。このような場合、このテストは実行しないでください。
  • もう1つのシナリオは、非常に単純なUI画面が追加されている場合です。ここでは、最大の欠陥を引き出すには、従来の陽性および陰性のテストで十分です。

アドホックテストの種類

アドホックテストは、以下の3つのカテゴリに分類できます。

＃1）バディテスト

この形式のテストでは、同じモジュールで作業するために選択されるテストメンバーと開発メンバーが存在します。直後 開発者はユニットテストを完了します 、 テスターと開発者が一緒に座る モジュールで作業します。この種のテストにより、機能を両方の当事者にとってより広い範囲で表示できます。

開発者は、テスターが実行するすべてのさまざまなテストの見通しを取得し、テスターは、無効なシナリオの設計を回避して無効な欠陥を防ぐのに役立つ固有の設計の見通しを取得します。それは、一方が他方を考えるように考えるのに役立ちます。

＃2）ペアテスト

このテストでは、2人のテスターが、同じテストセットアップを共有するモジュールで共同作業を行います。この形式のテストの背後にあるアイデアは、2人のテスターに​​、いくつかの欠陥があるアイデアと方法をブレインストーミングさせることです。どちらもテストの作業を共有し、行われたすべての観察結果について必要な文書を作成できます。

＃3）サルのテスト

このテストは、主に単体テストレベルで実行されます。テスターは、データまたはテストを完全にランダムな方法で解析して、システムがクラッシュに耐えられることを確認します。このテストは、さらに2つのカテゴリに分類できます。

アドホックテストの利点

テストは、必要なだけ創造的であるために多くの力を持つテスターを保証します。

これにより、以下のようにテストの品質と効率が向上します。

  • 際立っている最大の利点は、ソフトウェアのテストに適用できるさまざまな革新的な方法により、テスターが従来のテストよりも多くの欠陥を見つけることができることです。
  • この形式のテストは、SDLCのどこにでも適用できます。テストチームだけに限定されているわけではありません。開発者はこのテストを実施することもできます。これにより、コーディングが改善され、発生する可能性のある問題を予測することができます。
  • 別のテストと組み合わせて最良の結果を得ることができ、通常のテストに必要な時間を短縮できる場合があります。これにより、より高品質のテストケースを生成し、製品全体の品質を向上させることができます。
  • テスターの余分な負担を防ぐために、文書化を行う必要はありません。テスターは、基盤となるアーキテクチャを実際に理解することに集中できます。
  • テストに利用できる時間があまりない場合、これはテストカバレッジと品質の点で非常に価値があることがわかります。

アドホックテストの欠点

アドホックテストにもいくつかの欠点があります。いくつかを見てみましょう 顕著な欠点：

あまり整理されておらず、文書化が義務付けられていないため、最も明白な問題は、テスターがアドホックシナリオのすべての詳細をメモリに記憶して思い出す必要があることです。これは、特に異なるコンポーネント間に多くの相互作用があるシナリオでは、さらに困難になる可能性があります。

  • 最初のポイントから続けて、これはまた、情報を求められた場合、その後の試行で欠陥を再現することができないという結果になります。
  • これが明らかにするもう1つの非常に重要な質問は、努力の説明責任です。これは計画/構造化されていないため、この種のテストに費やされた時間と労力を説明する方法はありません。
  • アドホックテストは、チーム内の非常に知識が豊富で熟練したテスターのみが実行する必要があります。これは、潜在的な欠陥のある領域を予測するという点で、積極的かつ直感的である必要があるためです。

このテストをより効果的にするためのベストプラクティス

このテストに関連する長所と短所について詳しく説明しました。

理想的には、アドホックテストはSDLCでその場所を見つける必要がありますが、適切な方法でアプローチしないと、コストがかかり、貴重なテスト時間の無駄になる可能性があります。したがって、アドホックテストを効果的にするためのいくつかの指針を以下に示します。

＃1）欠陥が発生しやすい領域を特定します。

特定のソフトウェアのテストをしっかりと把握していると、他の機能よりもエラーが発生しやすい特定の機能があることに同意することになります。システムを初めて使用する場合は、先に進んで、それらに対して開かれている機能と欠陥を確認してください。

特定の機能の欠陥の数は、その機能が敏感であることを示しているため、アドホックテストを実行するにはその領域を正確に選択する必要があります。これは、いくつかの重大な欠陥を明らかにするための非常に時間効率の良い方法であることが証明されています。

C ++とJavaの違い

＃2）専門知識の構築：

間違いなく、経験の豊富なテスターは、経験の浅い人と比較して、より直感的で、エラーがどこにあるかを推測できます。経験があるかどうかにかかわらず、思い切ってテスト対象のシステムに関する専門知識を構築するのは個人の責任です。

はい、経験豊富なテスターは、長年にわたって蓄積されたスキルが役立つため、優位に立っていますが、新しいテスターは、これをプラットフォームとして使用して、より適切なアドホックシナリオを設計するために可能な限り多くの知識を得る必要があります。

＃3）テストカテゴリを作成します。

テストする機能のリストを認識したら、それらの機能を分類してテストする方法を決定するために、数分を取っておきます。 例えば、 ソフトウェアの成功にとって重要であると思われるため、ユーザーが最も目に見え、最も一般的に使用する機能を何よりも先にテストすることを決定する必要があります。

次に、それらを機能/優先度ごとに分類し、セグメントごとにテストできます。

これが特に非常に重要なもう1つの例は、コンポーネントまたはモジュール間に統合がある場合です。このような場合、多くの異常が発生する可能性があります。分類を使用すると、この種のテストに少なくとも1回または2回触れるのに役立ちます。

＃4）大まかな計画を立てる：

はい、はい。アドホックテストを計画やドキュメントがないはずのテストとして説明したため、この点で少し混乱する可能性があります。ここでの考え方は、アドホックテストの本質に固執することですが、それでも、テストの計画方法についていくつかの大まかな指針を書き留めておきます。

非常に基本的な例は、実行しようとしているすべてのテストを思い出せない場合があることです。したがって、それらを書き留めておけば、何かを見逃すことはありません。

＃5）ツール：

私たち全員が非常によく直面する例を見てみましょう。多くの場合、機能のテスト自体は成功し、動作に矛盾は報告されていません。ただし、舞台裏のログは、テストの目的をまったく妨げないため、テスターが見逃す可能性のあるいくつかの例外を報告している可能性があります。

これらはさらに重大度が高い可能性があります。したがって、これをすぐに特定するのに役立つツールを学ぶことが非常に重要です。

＃6）その他の欠陥に関する文書：

繰り返しになりますが、これにより眉が再び上がる可能性があることを理解しています。ドキュメントは詳細である必要はありませんが、カバーされているすべてのさまざまなシナリオ、関連する手順の逸脱、および特定のテスト機能カテゴリのそれらの欠陥を記録するための独自の参照のための小さなメモです。

これにより、テストバケット全体を改善することもできます。これにより、既存のテストケースを即興で作成する方法を決定したり、必要に応じてさらに追加したりできます。

結論

アドホックテスト手法について詳しく説明しました。その長所、短所、有益な状況とそうでない状況です。

これは、テスターの創造性に最大限に応え、満足させることを保証する1つのテスト手法です。私の全体で テストキャリア 、私はアドホックテストから最大限の満足を得ています。革新的であることに制限はなく、あなたはより知識が豊富になるだけだからです。

そうは言っても、上記のすべての情報から取り戻す主なことは、 アドホックテストの長所を活用して、テストプロセス全体と製品品質に付加価値を与える方法を決定します。

著者について： これはSnehaNadigによるゲスト記事です。彼女は、手動および自動化テストプロジェクトで7年以上の経験を持つテストリーダーとして働いています。

プロジェクトでアドホックテストを実行しますか？アドホックテストを成功させるためのあなたの提案は何ですか？

推奨読書

^