探索的テスト

探索的テストは、学習、テスト設計、テスト実行の迅速なサイクルを重視するテストのスタイルです。ソフトウェアが事前に書かれたテストスクリプトに準拠していることを検証するのではなく、探索的テストはソフトウェアの特性を探索し、合理的な動作または失敗として分類される発見を提起します。

探索的テストの考え方は、スクリプト化されたテストとは対照的です。スクリプト化されたテストでは、テスト設計者はテストのスクリプトを作成し、ソフトウェアの各操作は、ソフトウェアの予想される動作とともに書き留められます。これらのスクリプトは、通常、何度も、通常は作成者とは異なるアクターによって、個別に実行されます。いずれかのテストが、テストによって設計された予想される動作と一致しない動作を示す場合、これを失敗と見なします。

長い間、スクリプト化されたテストは通常、テスターによって実行されていました。そして、スクリプトに従って画面をクリックし、結果を確認する比較的ジュニアな人が、ブースの中にたくさんいるのを見たものです。エクストリームプログラミングのようなコミュニティの影響により、スクリプト化されたテストを自動化することにシフトしてきました。これにより、テストをより高速に実行でき、予想される動作の評価に伴う人的エラーが排除されます。私は長い間、このような自動化されたテストを強く支持しており、その使用でバグが大幅に減少するという大きな成功を収めてきました。

しかし、最も熱心な自動化テスターでさえ、この手法には根本的な限界があることを認識しています。これは、スクリプト化されたテストのあらゆる形式の限界です。スクリプト化されたテストは、スクリプトにあるものを検証することしかできず、既知の条件のみをキャッチできます。このようなテストは、それを通過しようとするバグをキャッチする優れたネットになる可能性がありますが、ネットがカバーするべきものをすべてカバーしていることをどうやって知るのでしょうか？

探索的テストは、ネットの境界をテストし、スクリプトにはない新しい動作を見つけようとします。多くの場合、スクリプトに追加できる新しい失敗が見つかります。場合によっては、無害であり、歓迎されることさえあるが、以前は考えられていなかった動作が明らかになります。

探索的テストは、スクリプト化されたテストよりもはるかに流動的で非公式なプロセスですが、うまく行うには依然として規律が必要です。これを行う良い方法は、時間制限のあるセッションで探索的テストを実行することです。これらのセッションは、ソフトウェアの特定の側面に焦点を当てています。セッションのターゲットと、見つけたい情報を特定するチャーターは、この焦点を定めるのに最適なメカニズムです。

このようなチャーターは焦点を絞ることはできますが、セッションで何が起こるかの詳細を定義しようとするべきではありません。探索的テストには、試してみること、ソフトウェアが何をするかについてさらに学ぶこと、その学習を適用して質問と仮説を生成すること、およびより多くの情報を収集するためにその場で新しいテストを生成することが含まれます。多くの場合、これによりチャーターの範囲外の質問が促され、後のセッションで調査できます。

探索的テストには、ソフトウェアについて学び、セッション中に新しいテスト設計を思いつくことに慣れている、熟練した好奇心旺盛なテスターが必要です。また、彼らは、奇妙に見え、さらに調査する価値があると思われる動作に注意を払い、観察する必要があります。ただし、多くの場合、彼らはフルタイムのテスターである必要はありません。一部のチームは、ペアまたは単一のモブで、チーム全体に探索的テストを実行させたいと考えています。

探索的テストは、ソフトウェア開発プロセス全体で定期的に行われるアクティビティである必要があります。残念ながら、プロジェクト内でどれだけ行うべきかについてのガイドラインを見つけるのは困難です。私は、数週間ごとに1時間のセッションから開始し、セッションがどのような種類の情報を明らかにするかを確認することをお勧めします。一部のチームは、ストーリーを完了するたびに、30分程度の探索的テストを手配したいと考えています。

バグが本番環境に侵入していることに気づいた場合、それはテスト体制にギャップがある兆候です。本番環境にエスケープするバグを調べ、バグがそこに行かないようにしたり、本番環境で迅速に検出したりするためにどのような対策を講じることができるかを検討する価値があります。この分析は、より多くの探索的テストが必要かどうかを判断するのに役立ちます。以前に探索的テストをあまり行ったことがない場合は、探索的テストをうまく行うスキルを身につけるのに時間がかかることに注意してください。

たとえ自動化テストが優れていたとしても、チームが探索的テストをまったく行っていない場合は、危険信号と見なします。最も優れた自動化テストでさえ、本質的にスクリプト化されたテストであり、それだけでは十分ではありません。