アドホックテスト。
アドホックという言葉はまさに、構造の欠如、または方法論的でない何かを意味します。
ここでいう正式なプロセスとは、要件ドキュメント、テスト計画、テストケース、およびスケジュールとテストの実行順序の点で適切なテスト計画のようなドキュメントを持つことを意味します。
これは主に、テストサイクル中に続く従来のまたは正式なプロセスでは捉えられない欠陥や欠点を明らかにしようとする目的で行われます。
すでに理解されているように、このテストの本質は、テストの公式または構造化された方法を持たないということにあります。 ランダムなテスト技術のような種類が実行されると、テスト担当者は、システムを破壊する目的で念頭に置いて、特定のユースケースなしでこれを実行することが明らかである。
したがって、それは間違いなく、このような直感的または創造的なテスト方法は、テスト担当者が非常に熟練した有能でシステムの深い知識を持っていることを必要とするより明らかである。 アドホック テストは、実行されたテストが完全であることを保証し、テスト バケットの有効性を判断する際に特に非常に役立ちます。
Let’s Start With An Ad-hoc Testing Example
ここで、UI ウィザードに関して、このテストをどのように実行するかの例を示します。 ウィザードは、名前、説明などのユーザー入力がある一連のペインです。
ウィザードの進行に伴い、ペインの 1 つでユーザー データを入力する必要があり、UI ウィザードがコンテキスト ポップアップ ボックスをスローし、ウィザードを完了しウィザードを展開/アクティブにするための関連データを追加します。
これをテストするために、テスト担当者は次のような通常のテストを行います。
- すべての有効なデータでウィザードを正常に完了し、プランを作成します。
- ウィザードで作成したプランを編集する。
- 作成したプランを削除して、その残りがないことを確認する。
- ウィザードで負の値を入力し、適切なエラーメッセージが表示されたことを確認する。
さて、上記の例について、できるだけ多くの不具合を発見するために実行できるアドホック テストのテスト ケースをいくつか紹介します：
- 負のデータを追加しようとしている間に、制限されていない特定の特殊文字を追加して、それらが適切に処理されるかどうかを確認します。 たとえば、ウィザードでは {or [ 中括弧 ] を制限しないことがありますが、特定の状況では、これは記述されている言語に基づくコードと衝突し、非常に信頼性の低い動作を引き起こす可能性があります。 ユーザーは、ポップアップを起動させ、キーボードのバックスペース ボタンを押そうとすることができます。 そうすると、バックグラウンド ウィザードが完全に消え、ポップアップが起動した時点まで入力されていたユーザー データがすべて失われることが何度も観察されています！
アドホック テストの特徴:
上記のシナリオを注意すると、このタイプのテストに何か非常に明確な特徴があることがわかるでしょう。
When Do We Do Ad-hoc Testing?
A million-dollar question indeed!
ほとんどの場合、テストチームは常に限られた時間内にテストする機能が多すぎて負担になっている。 その限られた時間枠の中では、正式なプロセスから派生した、完了しなければならない多くのテスト活動が存在します。
しかし、私の経験では、1ラウンドのアドホックテストは製品品質に大きな影響を与え、多くの設計上の疑問を提起することができます。
アドホック テストは構造化する必要のない「野生児」のようなテスト手法なので、一般的な推奨は、現在のテスト バケットの実行が終わった後に実行されなければならないことです。
私の見解では、アドホックテストはほとんどいつでも行うことができます – 最初、中間、そして最後に! それはただ、任意の時点でその場所を見つけるだけです。 しかし、最大限の価値を引き出すために、いつアドホック・テストを行わなければならないかは、テストされるシステムについての深い知識を持つ経験豊富なテスターが判断するのがベストでしょう。
実行しないときは？
前の質問が100万ドルの価値があるなら、これは10億ドルの価値があるはずです！
アドホックテストがどれほど効果的で実りあるものかを確立しましたが、熟練し能力のあるテスターとして、このタイプのテストに投資しないときにも解読が必要です。 これはテスターの裁量によりますが、ここでは、必要でない場合の推奨事項や例をいくつか紹介します。
- 欠陥が存在するテストケースがある場合、このテストは避けてください。 そのような状況では、テストケースの失敗箇所を文書化し、欠陥が修正されたときに検証/再テストを行う必要があります。
- また、顧客やクライアントがソフトウェアのベータ版のテストに招待されるようなシナリオもあるかもしれません。
- もう 1 つのシナリオは、非常にシンプルな UI 画面が追加される場合です。
Types Of Ad-hoc Testing
Ad-hoc testingは以下の3つのカテゴリに分類される。
#1) バディテスト
このテストでは、テスト担当者と開発担当者を決めて、同じモジュールを担当させます。 開発者がユニットテストを完了した直後に、テスターと開発者が一緒に座ってモジュールに取り組みます。
開発者は、テスト者が実行するさまざまなテストの見通しを得ることができ、テスト者は、無効なシナリオを設計することを避け、それによって無効な欠陥を防ぐのに役立つ固有の設計がどうであるかの見通しを得ることができます。
#2) ペアテスト
このテストでは、2人のテスターが同じテスト設定を共有しながら、ひとつのモジュールで一緒に作業します。 この形式のテストの背後にある考え方は、2人のテスターが欠陥の数を持つようにアイデアや方法をブレインストーミングすることです。 どちらもテストの作業を共有し、すべての観察の必要な文書を作ることができます。
#3) モンキーテスト
このテストは、主にユニットテストレベルで実行されます。 テスターは、システムがどんなクラッシュにも耐えられることを保証するために、完全にランダムな方法でデータまたはテストを解析します。 このテストはさらに 2 つのカテゴリに分類できます。
アドホック テストの利点
このテストは、必要なだけ創造的になるために多くの力を持つテスターを保証します。
これにより、以下のようにテストの品質と効率が向上します。
- 際立つ最大の利点は、ソフトウェアをテストするために適用できるさまざまな革新的なメソッドにより、テスターが従来のテストよりも欠陥の数を見つけることができるということです。 開発者もこのテストを実施することができ、より良いコードを書くのに役立ち、また、どのような問題が発生するかを予測することができます。
- 最高の結果を得るために別のテストと組み合わせることができ、時には通常のテストに必要な時間を短縮することができます。 これは、より質の高いテストケースを生成し、全体として製品の品質を向上させることができます。
- それは、テスターに余分な負担を防ぐために行われる任意のドキュメントを義務づけていません。 テストに利用できる時間があまりない場合、これはテスト カバレッジと品質の面で非常に価値があることがわかります。
アドホック テストの欠点
アドホック テストにもいくつかの欠点があります。 顕著な欠点をいくつか見てみましょう。
あまり組織化されておらず、文書化が義務付けられていないため、最も明白な問題は、テスターがアドホック シナリオのすべての詳細を記憶して思い出さなければならないことです。
- 最初のポイントに続いて、これは、情報を求められた場合に、その後の試行で不具合を再現できないことにもつながります。
- アドホックテストは、潜在的な欠陥のある領域を予見するという点で、積極性と直感が求められるため、チーム内の非常に知識豊富で熟練したテスターによってのみ実施されなければならない。
このテストをより効果的にするためのベストプラクティス
私たちは、このテストに関連する長所と短所について長々と議論してきました。
#1) 欠陥が発生しやすい領域を特定する：
あなたがソフトウェアの特定の部分をテストする上で良いホールドを持っているとき、あなたは、他のものよりエラーが発生しやすい特定の機能があることに同意することでしょう。
特定の機能における欠陥の数は、それが敏感であることを示すので、アドホック テストを実行するためにその領域を正確に選択する必要があります。
#2) 専門知識の構築：
確かに、経験の浅い人と比べると、経験の豊富なテスターはより直感的で、どこにエラーがあるのかを推測することができます。 しかし、新しいテスターは、これをプラットフォームとして、より良いアドホックなシナリオを設計するために、できるだけ多くの知識を得るべきです。
#3) テスト カテゴリを作成する：
テストする機能のリストを認識したら、それらの機能をどのように分類してテストするかを決めるために数分を確保してください。 たとえば、最も目につきやすく、ユーザーが最もよく使用する機能は、ソフトウェアの成功に不可欠であると思われるので、何よりも先にテストすることに決定すべきです。
次に、機能/優先順位で分類し、セグメントごとにテストすることができます。 このような場合、多くの異常が発生する可能性があります。
#4) 大まかな計画を立てる：
アドホックテストとは、計画や文書化を必要としないテストと説明したので、この点は少し戸惑うかもしれませんね。 ここでのアイデアは、アドホック テストの本質にこだわることですが、それでも、どのようにテストを計画するかについて、いくつかのラフなポインタを書き留めておくことです。
#5) ツール：
私たち全員が非常によく直面する例を挙げてみましょう。 多くの場合、機能そのもののテストは成功し、動作に不一致は報告されません。 しかし、舞台裏のログは、テスト担当者がテストの目的を妨げないように見逃してしまうような、いくつかの例外を報告している可能性があります。
#6) より多くの欠陥のためのドキュメント:
繰り返しになりますが、これがまたいくつかの眉をひそめるかもしれないことは理解しています。 ドキュメントは詳細である必要はありませんが、カバーされるすべての異なるシナリオ、関与するステップの偏差、および特定のテスト機能カテゴリのこれらの不具合を記録するための小さなメモを自分自身で参照することができます。
結論
アドホック テスト技法について、その長所、短所、有益な状況、有益でない状況などを詳しく説明してきました。 私のテストキャリア全体では、革新的であることに制限はなく、より多くの知識を得ることになるため、アドホック テストから最大の満足感を得ています。
そうは言っても、上記の情報すべてから取り戻すべき主要なことは、アドホック テストの長所をどのように利用し、全体のテスト プロセスと製品品質に価値を付加するかを決定することでしょう。
著者について。 これは、Sneha Nadig によるゲスト記事です。 彼女は、手動および自動テスト プロジェクトで 7 年以上の経験を持つテスト リーダーとして働いています。
プロジェクトでアドホックテストを行っていますか？ アドホックテストを成功させるために、何か提案はありますか？
最終更新日: 2012年11月28日 2021年2月18日