経験ベースのテストには、次の長所がある。 テスト(　)が厳しく制限されている場合に適用できる。

経験ベースのテストには、次の長所がある。 ドメインおよび技術で利用可能な(　)知識を、テストに適用できる。 これには、例えばビジネスアナリスト、顧客、クライアントなど、テストに関与しない人たちからの専門知識も含まれることがある。

経験ベースのテストには、次の長所がある。 開発者へ早期に(　)を提供できる。

経験ベースのテストには、次の長所がある。 作成するソフトウェアに関して(　)が精通するのに役立つ。

経験ベースのテストには、次の長所がある。 運用上の故障を効果的に(　)できる。

経験ベースのテストには、次の長所がある。 多様なテスト(　)を適用できる。

経験ベースのテストには、次の短所がある。 詳細なテスト(　)を必要とするシステムでは不適切なことがある。

経験ベースのテストには、次の短所がある。 高いレベルの(　)性を達成することは困難である。

経験ベースのテストには、次の短所がある。 テスト(　)を精密に評価できない。

経験ベースのテストには、次の短所がある。 テストケースがその後の(　)化にあまり適さない。

対処的またはヒューリスティックなアプローチでは、テスト担当者は通常、事前に計画するテストよりも、より対処的な経験ベースのテストを使用する。また、実行と(　)を同時に行う。

経験ベースのテストに対する一部の構造化されたアプローチは、完全に動的であるわけではない。つまり、テスト担当者がテストを実行するときに、すべてのテストを(　)するわけではない。これは、例えば、テストを実行する前に、エラー推測を使用してテスト対象の特定の側面をターゲットにする場合が該当する。

ここで説明する技法に関して、カバレッジについていくつかのアイデアを提示するが、経験ベースのテスト技法には、公式な(　)基準が存在しないことに注意する必要がある。

エラー推測技法を使用する場合、テストアナリストは経験を活かして、(　)の設計および開発時に発生した可能性のある潜在的なエラーを推測する。

エラー推測では、テストアナリストは想定されるエラーを識別したら、そのエラーの結果として生じる(　)を明らかにするために使用する最善の方法を決定する。例えば、テストアナリストが無効なパスワードを入力するとソフトウェアが故障を表示すると想定した場合、エラーが実際に発生し、そのエラーがテストの実行時に故障として認識される欠陥をもたらすかどうかを検証するために、様々に異なる値をパスワード欄に入力するようにテストを実行する。

エラー推測は、テスト技法として使用されるだけでなく、潜在的な故障モードを識別するためのリスク(　)時にも役立つ

エラー推測は、主として、統合テストおよびシステムテスト時に実行するが、(　)のテストレベルで使用できる。

エラー推測は、多くの場合、他の(　)と組み合わせて使用する。

エラー推測は、既存のテスト(　)の範囲を拡大するのに役立つ。

エラー推測は、ソフトウェアを新しくリリースするときに、より厳密な手続き化されたテストを開始する前に、一般的な(　)をテストする場合にも効果的に使用できる。

エラー推測には、次の制限と注意事項が適用される。 カバレッジを評価することは困難であり、テストアナリストの能力と(　)に応じて大きく異なる。

エラー推測には、次の制限と注意事項が適用される。 テスト対象の(　)の種類に共通して埋め込まれる欠陥の種類に精通している経験を積んだテスト担当者が使用する場合に最適である。

エラー推測には、次の制限と注意事項が適用される。 一般的に使用されているが、文書化しないことが多く、他の形式のテストに比べて(　)性が低いことがある

エラー推測には、次の制限と注意事項が適用される。 テストケースは文書化される場合があるが、(　)者だけが理解して再現できる形である。

エラー推測において、欠陥分類法を使用すると、(　)済みの分類アイテムの数を分類アイテムの総数で割ってカバレッジをパーセンテージで表すことで判定できる。

エラー推測において、欠陥分類法を使用しない場合は、テスト担当者の(　)と知識や利用可能な時間によりカバレッジが制限される。

エラー推測で検出できる欠陥の量は、テスト担当者が(　)のある領域を対象にできる能力に依存して異なる。

エラー推測で検出できる典型的な欠陥は、通常、特定の欠陥分類法で定義されているか、テストアナリストが「(　)」する。これらの欠陥は、ブラックボックステストでは検出されないことがある。

チェックリストベースドテスト技法を適用する場合、経験を積んだテストアナリストは、メモ、チェック、または記憶するための項目を(　)レベルで汎用化した一覧や、テスト対象に対して検証を行う一連のルールおよび基準を使用する。

チェックリストベースドテストで使用するチェックリストは、一連の(　)、経験、および他の考慮事項に基づいて構築する。例えば、ユーザーインターフェースの標準チェックリストをアプリケーションをテストするベースとして使用できる。

アジャイルソフトウェア開発では、チェックリストベースドですとのチェックリストはユーザーストーリーの(　)基準から構築できる。

チェックリストベースドテストは、テスト対象のソフトウェア、またはチェックリストによりカバーされる領域に精通している(　)を積んだテストチームがいるプロジェクトで、最も効果的である（例えば、ユーザーインターフェースチェックリストを正しく適用するために、テストアナリストはユーザーインターフェースのテストに精通しているが、テスト対象の特定のソフトウェアには精通していないことがある）。

チェックリストはハイレベルであり、テストケースおよびテスト手順で一般的に見られる詳細な手順が不足している傾向にある。このため、テスト担当者の(　)を使用してギャップを埋めることになる。

詳細な手順が省略されているため、チェックリストは(　)に手間がかからず、複数の類似リリースに適用できる。

チェックリストは、ソフトウェアのリリースおよび(　)が頻繁に行われるプロジェクトに非常に適している。これにより、テスト文書の準備およびメンテナンスの両方の時間を削減するのに役立つ。

ハイレベルのチェックリストという特性は、テスト結果の(　)性に影響を及ぼす可能性がある。

テスト担当者によりチェックリストの解釈が異なり、チェックリストの項目を満たすために異なる確認方法をとる可能性がある。これにより、同じチェックリストを使用しても、(　)テスト結果となる可能性がある。

同じチェックリストを使用しても、異なるテスト結果となる可能性がある。これは、より広い(　)を可能にするが、再現性が犠牲になることがある。

チェックリストを用いると、実際のテストではテスト担当者の判断に依存するため、達成するカバレッジの度合いに関して、(　)をもたらすこともある。

チェックリストは、より詳細なテストケースまたはテストリストから導き出すことができ、時間とともに(　)する傾向にある。

テスト対象のソフトウェアの重要な側面をチェックリストが確実にカバーするように、(　)を行う必要がある。

カバレッジは(　)済みのチェックリストアイテムの数をチェックリストアイテムの総数で割ってカバレッジをパーセンテージで表すことで判定できる。

カバレッジはチェックリストと同様であるが、チェックリストがハイレベルであるという特性により、結果は、チェックリストを実行するテストアナリストによって(　)可能性がある。

チェックリストベースドテストで見つかる典型的な欠陥は、テスト時のデータ、手順の順序、全般的なワーク(　)などが異なることにより、故障をもたらす欠陥である。

探索的テストには、テスト担当者がテスト対象とその欠陥についての学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を(　)に行うという特徴がある。

探索的テストのテスト担当者は、テスト実行時にテストのゴールを動的に調整し、軽量の(　)のみを準備する

優れた探索的テストは、しっかりと(　)されており、対話的で創造的である。

探索的テストは、テスト対象のシステムに関する(　)をほとんど必要としないため、ドキュメントが入手できない、あるいは他のテスト技法では十分ではない状況で使用することが多い。

探索的テストは、他のテスト技法に追加して、追加のテスト(　)を開発するためのベースとして使用することが多い。

探索的テストは、アジャイルソフトウェア開発において、最小限のドキュメントのみで(　)テストを柔軟かつ迅速に行うために頻繁に使用される。さらに、この技法は、シーケンシャル開発モデルを用いたプロジェクトにも適用可能である。

探索的テストのカバレッジはまちまちでまとまりがなく、実行したテストを(　)するのが困難になる可能性がある。

テストセッションでカバーする領域を指定したテスト(　)や、テストで使える時間を決定するタイム(　)は、探索的テストをマネジメントする技術である。

1回のテストセッション終了時、または複数のテストセッション終了時に、テストマネージャーは状況報告の(　)を開催し、テスト結果をとりまとめ、次のテストセッションのテストチャーターを決定することができる。

探索的テストセッションは、テストマネジメントシステムで正確に(　)することも困難である。

探索的テストセッションになるものをテストケースとして、テスト(　)システムで追跡することがある。これにより、探索的テストに割り当てられた時間や計画したカバレッジを別のテスト活動から追跡できる。

探索的テストは再現するのが困難であるため、故障を再現するための(　)を思い出す必要がある場合にも問題を引き起こすことがある。

ある組織は、テスト自動化ツールのキャプチャ/プレイバック機能を使用して、探索的テストの担当者が実施する手順を記録する。この方法は、探索的テストセッション（またはすべての経験ベースのテストセッション）時のすべての活動を完全に記録する。詳細を分析して、故障の実際の原因を見つけることは、単調で時間のかかる作業であるが、少なくとも関与したすべての(　)の記録が残る。

他のツールを使用して探索的テストセッションを記録することは可能であるが、GUI 操作は記録されないので、(　)結果を記録できない。この場合、期待結果を書き取り、必要に応じて欠陥を適切に分析できるようにする必要がある。探索的テストの実行中にも、必要に応じて再現できるように書き取っておくことが、一般的に推奨される。

探索的テストのカバレッジにおいて、テスト(　)は、特定のタスク、目的、および成果物のために設計することができる。その後、それらの基準を達成するために、探索的テストセッションを計画する。

探索的テストのテスト(　)はまた、テスト工数をどこに集中させるか、テストセッションの範囲内および範囲外はどこか、計画したテストを完了するためにどの程度リソースを投入すべきかも識別することもできる。

探索的テストのテスト(　)では、特定の欠陥タイプやその他の潜在的な問題点に焦点を当て、スクリプトテストの形式にとらわれずに対処することができる。

探索的テストで見つかる典型的な欠陥には、スクリプトによる機能適合性テストで見逃された(　)ベースの問題、機能(　)間に存在する問題、およびワーク(　)関連の問題がある。

性能問題や(　)問題が、探索的テストで見つかることもある。

欠陥ベースのテスト技法は、探したい(　)のタイプをテスト設計のベースとして使用する技法であり、すでに知られている(　)のタイプからテストを体系的に導き出す。

テストケースをテストベースから導き出すブラックボックステストと異なり、欠陥ベースのテストでは、欠陥に着目した(　)からテストを導き出す。

欠陥ベースのテストで使用する一覧は一般的に、欠陥の(　)、(　)原因、故障の(　)、および欠陥に関連するその他のデータの一覧に整理できる。

欠陥ベースのテストで使用する標準の一覧は、複数のタイプのソフトウェアに適用され、プロダクトに(　)しない。

この一覧を使用することは、業界(　)の知識を活用して特定のテストケースを導き出すのに役立つ。業界固有の一覧に従うことで、プロジェクト全体、さらには組織全体で、欠陥発生に関する指標を追跡することができる。

欠陥ベースのテスト技法で使用する最もよくある欠陥一覧は、組織や(　)ごとに作成され、特定の専門知識や経験を利用したものである。

欠陥ベースのテストでは、識別したリスクおよびリスクシナリオの一覧を、テストする対象を絞るための(　)として使用することもある。

テストアナリストは、欠陥ベースのテストを使用することにより、特定の欠陥のタイプに(　)を絞ったり、特定のタイプの既知および一般的な欠陥の一覧を通して体系的に作業したりできる。

欠陥ベースのテストでは、特定の欠陥の情報から、テストアナリストは、欠陥が存在する場合にその欠陥を顕在化させるようなテスト(　)とテスト条件を作成する。

欠陥ベースのテストは、すべてのテストレベルに適用できるが、一般的に、(　)テストに適用する。

複数の欠陥分類法が存在し、これらには、使用性など特定の(　)のテストに焦点を当てたものもある。

複数の欠陥分類法に利用可能なものがある場合、テスト対象の(　)に適用できる分類法を選択することが重要である。例えば、先進的なソフトウェアに対しては利用できる分類法が存在しないことがある。

一部の組織は、発生しやすく、頻繁に見られる欠陥の分類法を(　)に作成している。

？使用する分類法に関係なく、テストを開始する前に期待する欠陥を定義することが重要である。

欠陥ベースのテスト技法は、すべての有用なテスト(　)を識別したかどうかを決定するのに使用できるカバレッジ基準を提供する。

？欠陥ベースのテスト技法のカバレッジアイテムは、欠陥一覧に応じて、(　)要素、(　)要素、(　)シナリオ、これらのいずれかの組み合わせである可能性がある

実際問題として、欠陥ベースのテスト技法のカバレッジ基準は、カバレッジのための一般的なルールのみが与えられ、有用なカバレッジの範囲がどの部分までかについての具体的な決定は裁量に任されているという点で、ブラックボックステスト技法に比べてあまり(　)的ではない傾向にある。

他の技法と同じく、欠陥ベースのテスト技法のカバレッジ基準は、すべてのテストセットが完全であることを意味するのではなく、考慮された欠陥からは、この技法に基づいた有用なテスト(　)がこれ以上ないことを意味する。

欠陥ベースのテスト技法で検出できる欠陥の種類は、通常、使用する(　)法により異なる。例えば、ユーザーインターフェースの欠陥一覧を使用すると、検出する欠陥の大半はユーザーインターフェースに関連する。しかし、他の欠陥も特定のテストの副産物として検出できることもある。

ブラックボックステスト技法および経験ベースのテスト技法は、(　)に使用すると最も効果的である。

経験ベースの技法は、ブラックボックステスト技法のあらゆる体系的な(　)に起因するカバレッジのギャップを埋める。

すべての状況に対して完璧である技法は存在しない。テストアナリストは、各技法の長所と短所を理解し、プロジェクトの種類、スケジュール、情報へのアクセス、テスト担当者のスキル、および選択に影響する可能性のある要因を考慮して、特定の状況にとって(　)の技法または複数の技法を選択できることが重要である。

テストアナリストは、主に機能適合性テストに重点を置く。機能適合性テストは、テスト対象が「(　)」に重点を置く。

ISO のソフトウェア品質モデルでは、プロダクト品質は様々なプロダクト(　)特性に分類され、各(　)特性は副特性を持つ。

この節で説明するすべての品質特性および副特性について、典型的な(　)を認識して、適切なテスト戦略を形成および文書化する必要がある。

品質特性のテストでは、SDLC でのタイミング、必要なツール、ソフトウェアとドキュメントの入手可能性、および技術的な専門知識に特に注意を払う必要がある。それぞれの特性と固有のテストニーズに対応する(　)がなければ、テスト担当者は、スケジュールに組み込まれた適切な計画、ランプアップ（立ち上げ期間）、テスト実行の時間を確保できない可能性がある。

品質特性のテストの中には、例えば使用性テストのように、特別な人材の配置、広範な計画、専用のラボ、特定のツール、特定のテストスキル、および、ほとんどの場合、膨大な時間が必要になることがある。状況によっては、使用性またはユーザーエクスペリエンスを専門にする(　)のグループが使用性テストを行うことがある。

テストアナリストは、より技術的な方法を必要とする品質特性のテストに責任を負わないことがあるが、他の特性に留意し、テストで(　)する領域を理解することが重要である。例えば、性能テストに不合格となったテスト対象は、ユーザーが効率的に使用するには時間がかかりすぎる場合、使用性テストにも不合格となる可能性が高い。同じく、一部のコンポーネントで相互運用性の問題を抱えるプロダクトは、より基本的な問題が、環境が変化した場合に不明瞭になる傾向があるので、移植性テストを行うための準備が整っていない可能性があると言える。

機能適合性テストのテストベースは、一般的に、要件、仕様、固有のドメイン知識、または(　)のニーズである。

機能適合性テストは、実施するテストレベルによって様々であり、(　)の影響を受けることもある。例えば、統合テスト時に実施する機能適合性テストでは、単一の定義済み機能を実装するインターフェースコンポーネントの機能適合性をテストする。システムテストレベルでは、機能適合性テストはシステム全体の機能適合性をテストする。システムオブシステムズの場合、機能適合性テストは主に、統合したシステムを通したエンドツーエンドのテストに重点を置く。

機能適合性テストでは、様々なテスト(　)を使用する。

アジャイルソフトウェア開発の機能適合性テストでは、通常、次のテストを含む。 特定のイテレーションでの実装が計画されている特定の機能（ユーザー(　)など）のテスト

アジャイルソフトウェア開発の機能適合性テストでは、通常、次のテストを含む。 変更していないすべての機能に対する(　)テスト

機能適合性テストに加えて、テストアナリストの担当範囲の一部であり、（テスト対象が「どのように動作するのか」に重点を置く）(　)テスト領域と見なすことができる品質特性もある。

機能(　)性に関しては、明示的または暗黙的な要件にアプリケーションが準拠していることを検証する。また、計算の精度もテストすることがある。

機能正確性テストでは、多くのテスト技法を採用し、多くの場合、テスト(　)として仕様または旧システムを使用する。

機能正確性テストは、(　)のテストレベルで実施でき、データや状態の誤った処理を対象にする。