探索的テスト
探索的テストとその歴史について学んでください。探索的テストの長所と短所、スクリプト テストとの違い、それを使用する適切なコンテキストをご覧ください。
Deepak Parmar
寄稿ライター
探索的テストはソフトウェア テストへのアプローチであり、学習、テスト設計、実行を同時に行うことであるとしばしば説明されます。発見に焦点を当てて個々のテスト担当者にガイドを任せることで、他のテストの範囲では簡単にカバーできない欠陥を発見します。
近年、探索的テストが盛んに実施されるようになってきています。テスターと QA マネージャーは、包括的なテスト カバレッジ戦略の一環として探索的テストを含めることが推奨されます。
探索的テストの歴史
探索的テストは以前から存在していましたが、多くの場合は「アドホック テスト」と呼ばれていました。「探索的テスト」という言葉は、ソフトウェア テストの専門家である Cem Kaner 氏による名著『Testing Computer Software』から広く使用されるようになりました。
その紹介文はよく知られています。「どれほど多くの種類のテスト ケースをどれほど多く作成しても、正式に計画されたテストはいつか枯渇します。それでも、テストを続けられます。テストの準備や説明に多くの時間を費やすことなく、思うままにテストを実施しましょう。本能を信じましょう」
探索的テストを使用する理由
現在のチームは、継続的なインテグレーションを採用して高品質のデジタル エクスペリエンスの市場需要に応え、高まる顧客の期待に応える必要があります。市場投入までの期間は重要ですが、数百万ドルのバグや単純なユーザー エクスペリエンスの問題が発生すると、非常にコストがかかります。Boeing から Instagram に至るまで、納期に間に合わせるために急いだり質の低いテストを実施したりすることが、評判の低下と財務的な損失に繋がった例が枚挙に暇がありません。
ほとんどのソフトウェア品質テストは、構造化されたアプローチを使用しています。テスト ケースはすでに定義されたユーザー ストーリーに基づいて定義されて、テスト データは定義されたテスト ケースに基づいて構造化されています。テスト カバレッジは、ソフトウェア エンジニアリング指標を使用して測定されます。ほとんどの場合、このカバレッジは技術的に適切です。
ソリューションを見る
Open DevOps によるソフトウェアの構築と運用
関連資料
DevOps の自動テスト
見逃されがちなのが、ユーザー受け入れテスト (UAT) によって検出されてユーザー ペルソナに基づいてテストされる、極端なケースです。一方、探索的テストは本質的にランダムまたは非構造的であって、テストの構造化された段階では発見されないバグを明らかにする可能性があります。
探索的テストでは、テスターは特定のシーケンスに続くユーザー ストーリーを利用できます。テスターは、欠陥に注釈を付けてアサーションやボイス メモを追加し、その場でドキュメントを作成できます。これは、どのようにユーザー ストーリーをテスト ケースに変換するかです。この情報は、QA にも使用できます。
実質的に、テストの実行は正式にテスト ステップを作成せずに実装されます。探索的テスト ツールは、自動化の先駆けとなります。これは、調査結果をして自動で文書化するのに役立ちます。視覚的なフィードバックと共同テスト ツールを活用することで、誰もが探索的テストに参加できます。これによってチームは変化に迅速に対応して適応でき、アジャイルなワークフローが促進されます。
さらに、テスターは自動化されたテスト ケース文書化のためのツールを使用して、探索的テスト シーケンスを機能テスト スクリプトに変換できます。これは、従来のテスト プロセスを強化します。
Jira やテスト管理製品などのツールと統合することで、チームは記録されたドキュメントをテスト ケースに直接エクスポートできます。
そのため、探索的テストは文書化をスピードアップして単体テストを容易にし、迅速なフィードバック ループを作成するのに役立ちます。Context-Driven School of Software Testing の共同創設者である James Bach は、「探索的テストは、リアルタイムで科学的思考を促進します」と述べています。
探索的テストはいつ使うべきですか?
探索的テストは、誰かが迅速に製品やアプリケーションについて学んで迅速なフィードバックを提供する必要がある場合など、具体的にテスト シナリオに適しています。これは、ユーザーの視点から製品の品質を確認するのに役立ちます。
多くのソフトウェア サイクルでは、チームにテストを構築するのに十分な時間がない場合は、初期のイテレーションが必要です。探索的テストは、このシナリオでは非常に役立ちます。
ミッション クリティカルなアプリケーションをテストする際は、探索的テストによって重大な品質障害につながる極端なケースを見逃すことがなくなります。さらに、探索的テストを使用して、単体テスト プロセスを支援して手順を文書化し、後のスプリント中に広範囲にテストするためにその情報を使用します。
テスト カバレッジを強化するために、新しいテスト シナリオを見つけることは特に有効です。
探索的テストを使うべきではないケース
組織は、探索的テストとスクリプト テストの間で適切なバランスを取れる必要があります。探索的テストだけでは、十分なカバレッジを提供できません。チームはいくつかの初期マイルストーンを達成するまでは、このテストは試みるべきではありません。
特に、規制またはコンプライアンス ベースのテスト タイプでは、スクリプト テストを実施すべきです。法令上の理由によって、特定のチェックリストと義務に従う必要があるコンプライアンス ベース テストでは、必ずスクリプト テストを採用することをお勧めします。その一例として、いくつかの法律がテスト プロトコルに適用されていて合格する必要がある、定義された標準があるアクセシビリティ テストが挙げられます。
CI/CD の探索的テストの重要性
探索的テストは、訓練されたテスターだけでなくすべての主要な関係者でも実行可能です。探索的テスト ツールを使用して、スクリーンショットをキャプチャしてボイス メモを録音し、セッション中にフィードバックに注釈を付けられます。これによって、従来のソフトウェア テスター以外の人でもより迅速に効率的にレビューできます。
探索的テストは、QA チームの既存のテスト戦略を補完するものです。これは、未発見の問題/バグを発見するための、文書化されていない一連のテスト セッションで構成されています。自動テストやその他のテスト プラクティスと組み合わせることで、テスト カバレッジを増やして極端な例を発見します。さらに、新しい機能を追加してソフトウェア製品を全体的に改善する可能性まで秘めています。柔軟な構造によって、チーム内の実験、創造性、発見を促します。
即座にフィードバックが得られるため、テスターと開発者の間のギャップを埋めるのに役立ちます。中でも、探索的テストの結果によって、開発チームはユーザー指向の視点とフィードバックを得られます。目標は、従来のテストを補完して、通常は定義されたワークフローの背後に隠れてしまう致命的な欠陥を見つけることです。
Atlassian Marketplace にアクセスして、テスト管理アプリケーションの詳細をご覧ください。さらに、アトラシアンやサードパーティのツールがどのようにワークフローのテストを統合するのかを DevOps テスト チュートリアルでご確認ください。
この記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
DevOps コミュニティ
ブログを読む
