初版(研究会公式版)

JaSST'16 Tokyoのコミュニティブース発表時に来場者のみなさまから頂いたいくつかのフィードバックを反映したものです。

探索的テスト研究会について

 探索的テスト研究会は、「探索的テストについて知りたい、議論したい」と考える有志により発足したコミュニティです。
 書籍と実体験を通じて探索的テストの考え方・行い方について議論を交わしながら、その成果を外部にも発信し、フィードバックを得ることを方針としています。
 その議論の中で、探索的テストのイメージが人によって異なり、議論するための土台作りをする必要があることがわかりました。
本発表では、わたしたちが解釈した探索的テストの形を「モデル」とし、探索的テストについてよく出る疑問を「FAQ」として整理したものを公開します。

わたしたちが考えた探索的テストのモデル

  • 一回の探索的テストの中で、思考・実行・学習を繰り返し行います。
  • テスト対象から得られるふるまいに対するプロセスを、「感知する」と 学習する」に分けています。「感知する」プロセスから得た「直感・感情」はすぐに「思考する」に影響を与え、「学習する」プロセスは「知識・経験」として蓄積され、「テストケース」につながります。
  • 「直感・感情」と「知識・経験」を通じた「思考する」が、このモデルにおけるテスト設計にあたります。
  • このモデル上の成果物は、実体のないものでも構いません。たとえば「思考する」のアウトプットである「テストケース」は、必ずしも実体としてのファイルになっている必要はなく、頭の中にあることもあります。

Q1. 探索的テストとは何ですか?

 Cem Kaner氏、James Bach氏らによって提唱された、テストのスタイル、あるいはアプローチです。探索的テストはテスト対象を触ってその反応を観察し、知識・経験・直観を駆使して次のアクションを決めていきます。
テスト設計・実装・実行というプロセスを順に行っていく「スクリプトテスト」に対し、探索的テストはテストの設計・実行、そして学習を同時に行い、フィードバックを繰り返していくのが特徴です。
 また、探索的テストでは厳密なテストケースを必須としませんが、テストに一定の方向性を与えるために、目的・内容・方法などの何らかの指針を事前に準備しておくことが多く、この指針を「チャーター」と呼ぶこともあります。
 探索的テストの定義は提唱者によって何度か改訂されています。このFAQの内容は主に、現在最も知られているであろう2006年~2015年の定義をベースにしています。2015年の改訂「探索的テスト3.0」では、これまで探索的テストと呼んできたものが、本来「テスト」自体が備えているべき性質であるという結論に至っており、探索的テストとテストを区別することに疑問が呈されています。
http://www.satisfice.com/blog/archives/1504

Q2. 探索的テストとモンキーテスト・アドホックテストはどう違うのですか?

 探索的テストとしばしば比較されるのが、「モンキーテスト」と「アドホックテスト」です。特にアドホックテストの定義や捉え方はさまざまで、人によって意見が異なることがありますが、ここではJSTQBの用語集の定義に沿う形で説明します。
 モンキーテストは文字通り解釈すれば、「猿がソフトウェアを触るように」、製品の使用法についてまったく考慮せずに操作を行うテストです。特定のキーを繰り返し連打したり、通常のシナリオではまず発生しないような手順などを実行したりするかもしれません。テストの再現性には期待できません。
 アドホックテストは、非公式に実施するテストとされます。事前の十分なテスト分析・設計を行わず、テスターの直感や経験を頼りにすることから、一般的にはテスト対象のソフトウェアに精通したベテランのテスターが行うべきとされます。テスト方法が毎回変わるのでテスト結果も毎回変わります。
 この意味でアドホックテストは探索的テストとそう違わないと考えることもできますが、「指針の有るか無」と「ログの必要性」が差異に挙げられることがあります。
 探索的テストでは、テストの目的を大まかに定めておき、その目的から逸脱しないように進めていくのが一般的ですが、アドホックテストでは多くの場合、そういった縛りがありません。
 また、探索的テストにおいては実施した手順や思考の過程を記録に残すことが推奨されますが、アドホックテストはそうでないことが多く、「再現性がない」と説明されることもあります。

Q3. 探索的テストを学ぶのにおすすめの教材や文献はありますか?

 書籍ですと『知識ゼロから学ぶソフトウェアテスト改訂版』『はじめて学ぶソフトウェアのテスト技法』にまとまった解説があります。英語文献ですと『Explore It!』『How to Break Software』Exploratory Software TestingMore Agile Testing』が専門書籍として有力です。
 ウェブでも有益な解説資料が複数公開されていますが、日本語文献は限られている状態です。

Q4. どのような内容のログを残せばいいですか?

 探索的テストのログが適切かどうかは、テストの目的によります。 重要なのは「何をしたのか」を記録し「再現できるようにすること」と「何が問題か」「問題でなかったのか」を説明できることです。
 残した方が良い情報の例としては時刻、準備内容、意図といった目的に関わるものと、確認したこと、手順、結果、違和感、メモなどの結果に関わるものがあります。※ただしテストの実行を阻害するほどの量の記録は推奨しません。

Q5. なぜ探索的テストが必要なのですか?

 決まった時間の中でできるだけ多くの欠陥を見つける「効率」を重視してテストを行う場合、探索的テストが有力な選択肢になります。事前にテスト仕様書を作る時間が不要なこと、またテストエンジニアの能力に基づいて、欠陥のありそうな箇所を積極的に狙っていけるためです。
 一方、「欠陥がないこと」も含めたテストの網羅性を重視する場合であっても、テストスクリプトに基づくテストに加えて探索的テストを行うことで、テスト実行前には考えていなかった観点・シナリオ・手順がテストの対象となり、より有効なテストになると期待できます。

Q6. 探索的テスターに必要なスキルはどのようなものですか?

 マインドセットとして「その製品/プロジェクトが提供したい価値を理解しようとする姿勢」が重要です。 また、スキルや知識としておおまかに以下が有効です。これらは見分けの観点となります。

  • 製品知識(ドメイン知識)。製品の要求、仕様、構造の知識。
  • テスト技術のスキル。目的に応じて適切なテストを組み立てたり、既存のテストの穴を見つけたりするスキル
  • 欠陥の知識。欠陥を推定するための知識
  • 欠陥の兆候を見逃さない観察力、よりよいテスト条件を導く好奇心

Q7. チャーターはどのようなものですか?

 チャーター(またはテストチャーター)とは探索的テストを実施する上での指針となる情報を記したものです。チャーターに記述される項目や情報の粒度は様々で、なにがしかの決まりがあるわけではありません。単に探索する範囲として機能を示した一言程度の非常にシンプルなものもあります。一方、テーマ、目的、優先度、データなど多様な項目をもつかなりボリュームのあるものもあります。
 探索的テストについて書かれた書籍「Explorer it!」でのフォーマットを例に示すと、「Explore <target> with <resources> to discover <infomation>」といったシンプルなものです。何処を探索するのか、どんな資源を使うのか、どのような情報を見つけたいのかをチャーターとして示すことで、その指針に沿った探索的テストを実施します。良いチャーターとは、プロンプト(想起させるもの)であり、正確なアクションや結果などは示さずに、インスピレーションの源泉になります。
 探索的テストはかなり自由度の高いスタイルですので、チャーターそれ自体に細かな決まりなどはありませんし、チャータ自体も必須ではありません。すべてが探索的テストの実施者に任されるフリースタイルの探索的テストもあれば、チャーターを用意するのではなく断片的なテストケースを指針として使って探索的テストも実施する場合もあり得ます。

Q8. 探索的テストを実施する時間はどの程度がよいですか?

 探索的テストの目的、テスト対象の複雑度、テスト実施者の経験やスキルなどに依存するため、一概には言えませんが、文献(※)によると、「45分~2時間程度」としているものがあります。実際のところは、 テスト計画時に関係者間で合意した時間やコストで実施することになるのだと考えます。
 なお、 探索的テストを実行する時間単位を「セッション」と呼ぶことがあります。
※Session-Based Test Management ( http://www.satisfice.com/articles/sbtm.pdf )

Q9. 探索的テストの終了をどのように判断すればよいですか?

 終了基準は定番の課題で、絶対解はありません。通常、主観判断が要求されます。
 参考例として、探索的テストの担当者が「目的を達成したと言えるぐらい十分に探索した」と判断することをもって、終了とする場合があります。またチャータやセッションの達成率も終了基準となります。
 また、信頼度は劣りますが、見積もりに対する欠陥除去率、検出欠陥の収束具合など一般的な終了基準の指標も、参考になる場合があります。

Comments