探索的テスト

探索的テストは、ソフトウェアテストのアプローチであり、簡潔に言えば、同時学習、テスト設計、テスト実行です。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 などの興味のある状況をすばやく生成するのに役立つツールをよく使用します。

利点と欠点

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

もう 1 つの大きな利点は、テスターが以前の結果に基づいて演繹的推論を使用して、今後のテストを即座にガイドできることです。テスターは、よりターゲットが豊富な環境に焦点を当てたり、探索したりする前に、現在の一連のスクリプト化されたテストを完了する必要はありません。これを賢く使用すると、バグ検出も高速化されます。

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

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

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

科学的研究

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

参照

参考文献

^ Cem Kaner、「探索的テストのチュートリアル」Wayback Machineに 2013-06-12 にアーカイブされました、p.2
^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineで 2013-06-12 にアーカイブ、p. 36。
^ Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013-06-12 にアーカイブ、p. 37-39、40-。
^ Cem Kaner、「コンピュータソフトウェアのテスト」、TAB Books、Blue Ridge Summit、PA、1988 年、p. 6、7-11。
^ Kaner, Cem ; Bach, James; Pettichord, Bret (2001).ソフトウェアテストで学んだ教訓. John Wiley & Sons . ISBN 978-0-471-08112-8。
^ Cem Kaner、James Bach、「探索的およびリスクベースのテスト」、www.testingeducation.org Archived 2008-05-11 at the Wayback Machine、2004年、p. 10
^ Cem Kaner、James Bach、「探索的およびリスクベースのテスト」、www.testingeducation.org Archived 2008-05-11 at the Wayback Machine、2004年、p. 14
^ 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.
^ イトコネン、J.マンティラ、MV;ラッセニウス、C. (2013-05-01)。「探索的なソフトウェアテストにおけるテスターの知識の役割」。ソフトウェアエンジニアリングに関するIEEEトランザクション。39 (5): 707–724。土井：10.1109/TSE.2012.55。ISSN 0098-5589。S2CID 1763558。
^ イトコネン、J.ラウティアイネン、K. (2005-11-01)。「探索的テスト: 複数のケーススタディ」。2005 年経験的ソフトウェア工学に関する国際シンポジウム、2005 年。 10ページ～土井：10.1109/ISESE.2005.1541817。ISBN 978-0-7803-9507-7. S2CID 7974121。
^ 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。

外部リンク

ジェームズ・バッハ、探索的テストの説明
Cem Kaner、James Bach、「探索的テストの性質」、Wayback Machineで 2008-05-11 にアーカイブ、2004
ジェームス・カナー、ジェームズ・バッハ、コンテキストドリブンスクールの7つの基本原則
ジョナサン・コール『探索的テスト：ソフトウェア調査の音楽を見つける』Kohl Concepts Inc.、2007年

[1] Cem Kaner、「探索的テストのチュートリアル」Wayback Machineに 2013-06-12 にアーカイブされました、p.2

[2] Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineで 2013-06-12 にアーカイブ、p. 36。

[3] Cem Kaner、「探索的テストのチュートリアル」、Wayback Machineに 2013-06-12 にアーカイブ、p. 37-39、40-。

[Kaner7-11-4] Cem Kaner、「コンピュータソフトウェアのテスト」、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、「探索的およびリスクベースのテスト」、www.testingeducation.org Archived 2008-05-11 at the Wayback Machine、2004年、p. 10

[7] Cem Kaner、James Bach、「探索的およびリスクベースのテスト」、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。