探索的テスト

探索的テストとは、ソフトウェアテストのアプローチの一種であり、簡潔に言えば、学習、テスト設計、テスト実行の同時進行と説明されます。1984年にこの用語を造語したCem Kaner氏[ 1 ]は、探索的テストを「テスト関連の学習、テスト設計、テスト実行、そしてテスト結果の解釈を、プロジェクト全体を通して並行して実行される相互に補完的な活動として捉えることで、個々のテスターが自身の作業品質を継続的に最適化できるよう、個人の自由と責任を重視するソフトウェアテストのスタイル」と定義しています。[ 2 ]

ソフトウェアがテストされている間、テスターは様々なことを学び、経験と創造性と相まって、実行すべき新たな優れたテストを生み出します。探索的テストはしばしばブラックボックステスト手法と考えられていますが、実際には、それを研究した人々は、開発プロセスのどの段階においても、あらゆるテスト手法に適用できるテストアプローチであると考えています。重要なのは、テスト手法でも、テストまたはレビューの対象となる項目でもありません。重要なのは、テスターの認知的関与と、テスター自身の時間管理責任です。[ 3 ]

歴史

探索的テストは、常に熟練したテスターに​​よって行われてきました。1990年代初頭には、「アドホック」という言葉は、しばしばずさんで不注意な作業と同義語とされていました。その結果、テスト方法論者グループ（現在はコンテキスト駆動派と自称）は、「探索的」という用語を使い始め、スクリプトのないテストにおける主要な思考プロセスを強調し、この実践を教育可能な分野へと発展させようとしました。この新しい用語は、Cem Kanerの著書『Testing Computer Software』[ 4 ]で初めて発表され、 『 Lessons Learned in Software Testing』[ 5 ]でさらに詳しく述べられています。探索的テストは、他の知的活動と同様に規律あるものであり得ます。

説明

探索的テストは、ソフトウェアが実際にどのように動作するかを調べ、困難なケースや容易なケースにどのように対処するかを検証することを目的としています。テストの質は、テストケースを考案し、欠陥を見つけるテスターのスキルに依存します。テスターが製品と様々なテスト手法についてより深く理解しているほど、テストの質は向上します。

さらに説明すると、フリースタイルの探索的テストとその対極​​にあるスクリプト化されたテストを比較することができます。後者のアクティビティでは、テスト ケースが事前に設計されます。これには、個々のステップと予想される結果の両方が含まれます。これらのテストは、実際の結果と予想される結果を比較するテスターに​​よって後で実行されます。探索的テストを実行する場合、期待はオープンです。一部の結果は予測され、予想されますが、そうでないものもあります。テスターは、製品とその動作を設定、操作、観察、評価し、結果を批判的に調査して、バグ (一部の人にとって製品の価値を脅かすもの) または問題 (テスト作業の品質を脅かすもの) である可能性が高い情報を報告します。

実際には、テストはほとんどの場合、探索的テストとスクリプト化されたテストの組み合わせですが、コンテキストに応じてどちらか一方に傾向します。

KanerとJames Marcus Bachによると、探索的テストは方法論というよりも、むしろ考え方、あるいは「テストについての考え方」である。[ 6 ]また、彼らは、探索的テストは、やや探索的（やや曖昧、あるいは漠然としたスクリプト化されたテスト）から高度に探索的（フリースタイルの探索的テスト）まで、連続体であるとも述べている。[ 7 ]

探索的テストのドキュメント化は、実行したすべてのテストを文書化することから、バグのみを文書化するまで多岐にわたります。ペアテストでは、2人が共同でテストケースを作成します。1人がテストを実行し、もう1人が文書化します。 セッションベーステストは、探索的テストをより広範囲で監査および測定可能にするために特別に設計された手法です。

探索的テスターは、探索的セッションの記録としてスクリーン キャプチャやビデオ ツールなどのツールや、James Bach の Perlclip などの興味のある状況をすばやく生成するのに役立つツールをよく使用します。

利点と欠点

探索的テストの主な利点は、必要な準備が少なく、重要なバグがすぐに見つかり、実行時にスクリプト化されたテストを実行するよりも知的に刺激的なアプローチになる傾向があることです。

もう一つの大きなメリットは、テスターが過去のテスト結果に基づいて演繹的推論を行い、今後のテストを即座に導けることです。テスト担当者は、よりターゲットを絞り込んだ環境の調査や検証に着手する前に、既存の一連のスクリプトテストを完了する必要はありません。これを賢く活用すれば、バグ検出も加速します。

もう一つの利点は、初期テストの後、ほとんどのバグが何らかの探索的テストによって発見されることです。これは、「特定のテストに合格したプログラムは、同じテストに引き続き合格する傾向があり、まだ調査されていない他のテストやシナリオに失敗する可能性が高くなります」と述べることで論理的に証明できます。

欠点は、その場で考案され実行されるテストは事前に確認することができず（それによってコードやテストケースのエラーを防ぐことができず）、どのテストが実行されたかを正確に示すことが難しい場合があることです。

フリースタイルの探索的テストは、再検討する際に全く同じ方法で実行される可能性は低いため、新たなエラーを発見することが重要な場合にはメリットとなり、以前のテストの特定の詳細を繰り返すことの方が重要な場合にはデメリットとなります。これは、テスターへの具体的な指示、あるいは実現可能かつ適切で必要な場合、そして理想的にはユニットレベルに近い自動テストを準備することで制御できます。

科学的研究

複製実験により、スクリプトテストと探索的テストは欠陥検出の有効性（発見された欠陥の総数）は同程度であるものの、テストケースの事前設計に労力が費やされないため、探索的テストの方が効率（時間単位あたりの欠陥数）が高くなることが示されています。[ 8 ]探索的テスターに​​関する観察研究では、ドメイン、テスト対象のシステム、顧客に関する知識の活用が、探索的テストの有効性を説明する重要な要素であると提案されています。[ 9 ] 3社のケーススタディでは、迅速なフィードバックを提供できることが探索的テストの利点である一方で、テストカバレッジの管理が欠点であると指摘されています。[ 10 ]ある調査では、探索的テストは重要なドメインでも使用されており、探索的テストのアプローチでは、テストを実施する担当者に高い要求が課されることがわかりました。[ 11 ]

参照

参考文献

  1. ^ Cem Kaner、「探索的テストのチュートリアル」 Wayback Machineで2013年6月12日にアーカイブ、p.2
  2. ^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013 年 6 月 12 日にアーカイブ、p. 36。
  3. ^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013 年 6 月 12 日にアーカイブ、p. 37-39、40-。
  4. ^ Cem Kaner、「Testing Computer Software」、TAB Books、Blue Ridge Summit、PA、1988 年、p. 6、7-11。
  5. ^ Kaner, Cem ; Bach, James; Pettichord, Bret (2001). 『ソフトウェアテストにおける教訓』John Wiley & Sons . ISBN 978-0-471-08112-8。
  6. ^ Cem Kaner, James Bach, Exploratory & Risk Based Testing , www.testingeducation.org Archived 2008-05-11 at the Wayback Machine , 2004, p. 10
  7. ^ Cem Kaner, James Bach, Exploratory & Risk Based Testing , www.testingeducation.org Archived 2008-05-11 at the Wayback Machine , 2004, p. 14
  8. ^ Itkonen, Juha; Mäntylä, Mika V. (2013-07-11). 「テストケースは必要か？探索的ソフトウェアテストとテストケースベースソフトウェアテストの反復比較」Empirical Software Engineering . 19 (2): 303– 342. CiteSeerX 10.1.1.363.6524 . doi : 10.1007/s10664-013-9266-8 . ISSN 1382-3256 . S2CID 254472881 .   
  9. ^イトコネン、J.マンティラ、MV;ラッセニウス、C. (2013-05-01)。 「探索的なソフトウェア テストにおけるテスターの知識の役割」。ソフトウェアエンジニアリングに関するIEEEトランザクション。39 (5​​): 707–724 .土井: 10.1109/TSE.2012.55。ISSN 0098-5589。S2CID 1763558。  
  10. ^イトコネン、J.ラウティアイネン、K. (2005-11-01)。 「探索的テスト: 複数のケーススタディ」。2005 年経験的ソフトウェア工学に関する国際シンポジウム、2005 年。 10ページ –土井: 10.1109/ISESE.2005.1541817。ISBN 978-0-7803-9507-7. S2CID  7974121 .
  11. ^ Pfahl, Dietmar; Yin, Huishi; Mäntylä, Mika V.; Münch, Jürgen (2014-01-01). 「探索的テストはどのように利用されているか？ 現状調査」.第8回ACM/IEEE国際経験的ソフトウェア工学・測定シンポジウム議事録. ESEM '14. ニューヨーク、ニューヨーク州、米国: ACM. pp. 5:1–5:10. doi : 10.1145/2652524.2652531 . hdl : 10138/153363 . ISBN 9781450327749. S2CID  17924562 .
「 https://en.wikipedia.org/w/index.php?title=Exploratory_testing&oldid=1306186221」より取得