(　) に当てはまる言葉を答えてね。 テスト分析とテスト設計におけるテストレベルとテスト目的への留意は、 必要な詳細度合いと (　) （例えば、コンポーネントテストレベルでのドライバーおよびスタブ）を決定するのに役立つ。

テスト条件およびテストケースの開発時には、一般的に、テスト作業成果物となるいくつかの(　)を作成する。

テストケースの開発時に文書化するテスト作業成果物の範囲は大幅に異なる。 次の要因が文書化する範囲に影響を及ぼす。 (　)リスク（文書化する必要のあるもの、文書化してはいけないもの）

テストケースの開発時に文書化するテスト作業成果物の範囲は大幅に異なる。 次の要因が文書化する範囲に影響を及ぼす。 ドキュメントがプロジェクトに提供する「(　)価値」

テストケースの開発時に文書化するテスト作業成果物の範囲は大幅に異なる。 次の要因が文書化する範囲に影響を及ぼす。 準拠する必要のある(　)および満たす必要のある(　)

テストケースの開発時に文書化するテスト作業成果物の範囲は大幅に異なる。 次の要因が文書化する範囲に影響を及ぼす。 (　)または使用する(　)（例えば、アジャイルアプローチでは、「必要最小限」の文書化を目標にする）

テストケースの開発時に文書化するテスト作業成果物の範囲は大幅に異なる。 次の要因が文書化する範囲に影響を及ぼす。 テストベースからテスト分析およびテスト設計を通しての(　)の要件

テストの範囲に応じて、テスト分析およびテスト設計は、テスト対象の(　)特性に対応させる。 ISO (　) 標準が、有効な参照情報を提供している。 ハードウェア／ソフトウェアシステムをテストする場合には、その他の特性を適用することがある。

テスト分析およびテスト設計の活動は、 レビューおよび(　)解析とテスト分析およびテスト設計を組み合わせることにより強化できることがある。

テスト分析およびテスト設計を実施する活動の中でテストベースの問題を見つけることがあるため、 実際に、テスト分析およびテスト設計を行うことが(　)テストの一形態となることがしばしばある。

(　)仕様に基づいたテスト分析およびテスト設計を行うことは、 要件レビューミーティングの準備として優れた方法の 1 つである。

要件を読み解き、テストを作成するために要求仕様を使用するには、 要件を理解し、要件の達成度を(　)する方法を決定できることが求められる。

要求仕様に基づいたテスト分析・テスト設計では、 (　)している要件、(　)でない要件、(　)できない要件、または(　)基準が定義されていない要件を明らかにする。

要求仕様に基づいたテスト分析・テスト設計では、 テストケース、リスク分析、テスト計画書などのテスト(　)をレビュー対象にできる。

要求される詳細なテスト(　)の要件は、 実際にはテスト実装まで完成しない可能性があるが、テスト設計時に定義することがある。

テストインフラストラクチャーは、テスト(　)およびテストウェア以外のものも含むことに注意する必要がある。 例えば、テストインフラストラクチャーの要件は、 場所、機器、担当者、ソフトウェア、ツール、周辺機器、通信機器、ユーザー権限、 およびテストを実行するために必要な他のすべてのアイテムを含むことがある。

テスト分析およびテスト設計の終了基準はプロジェクトにより異なるが、 2 つの節で説明したすべての事項を定義することを終了基準に含めるべきである。 重要なのは、終了基準が(　)可能であり、以降の手順に必要なすべての(　)が提供され、 必要なすべての(　)が実施されていることである。

(　)では、テスト分析と設計に基づいてテスト実行に必要なテストウェアの準備をする。

テスト実装では次の活動を含む。 テスト(　)、および、場合によっては自動(　)を作成する

テスト実装では次の活動を含む。 特定のテストランにおいて実行されるテストスイートとして、 テスト(　)と（もし存在する場合）自動(　)を整理する

テスト実装では次の活動を含む。 実行するテストケースとテストスイートの(　)付けについて、テストマネージャーに相談する

テスト実装では次の活動を含む。 テストケースの実行を開始するために必要なテスト実行(　)（リソースの割り当てを含む）を作成する

テスト実装では次の活動を含む。 テスト(　)およびテスト(　)の準備を完了する

テスト実装では次の活動を含む。 テストベースと、テスト条件、テストケース、テスト手順、テストスクリプト、テストスイートなどの テストウェアとの間の(　)を更新する

テストアナリストはテスト実装時に、テストケースの効率的な実行(　)を特定し、テスト手順を作成する。

テスト実装でテスト手順を定義する際には、 テスト実行の(　)に影響を与える可能性のある制約や依存関係を入念に識別することが求められる。

テスト手順では、すべての初期(　)（データリポジトリからのテストデータのロードなど） およびすべての(　)活動（システムステータスのリセットなど）を記述する。

テストアナリストは、グループ化できるテスト手順と自動テストスクリプトを特定し （例えば、それらはすべて特定のハイレベルなビジネスプロセスのテストに関連する）、それらをテスト(　)に整理する。 これにより、関連するテストケースを一緒に実行できる。

テストアナリストは、効率的なテスト実行が実現できるように、テスト実行スケジュールにテスト(　)を配置する。

リスクベースドテスト戦略を使用する場合、 リスク(　)は、テストケースの実行順序を決定する際に最も優先的に考慮すべき事柄になる。

テスト実装において、適切な担当者、機器、データ、テスト対象の機能などの可用性のように、 他の要因がテスト(　)の実行順序を決定することもある。

コードが部分ごとにリリースされることは珍しくないので、 ソフトウェアがテスト可能になる順序に合わせてテスト(　)配分を調整しなければならない。

イテレーティブおよびインクリメンタル開発モデルで特に重要なのは、 ソフトウェアがテスト可能な順序でテスト用にリリースされるように、テストアナリストが(　)と調整することである。

テスト実装時に行う作業の(　)度合いとそれに関する複雑度は、テスト条件やテストケースの詳細度に影響される場合がある。

テスト実装時の作業の詳細度合いは、場合によっては、(　)の適用が求められ、 適用する標準（例えば、米国標準 DO-178C（欧州の ED-12C））への準拠の証跡をテスト作業成果物で示すべきである

テスト実装において、前述しているように、大抵の場合、テストではテストデータが必要であり、 場合によってはデータセットが非常に(　)なることがある。

テストアナリストは実装時に、データベースや他のリポジトリなどにロードするために入力(　)と環境(　)を作成する。

テスト実装時に用意した入力データや環境データは、欠陥の検出を可能にするために、 「(　)にかなって」いなければならない。

テストアナリストは、手動テストで使用するデータの他に、 データ(　)型およびキーワード(　)型のテストで使用するデータを作成することもある。

テスト実装では、テスト(　)についても考慮する。 この段階で、テストを実行する前に(　)をすべて設定し、検証しておくべきである。

テスト実装において、「(　)にかなった」テスト環境は必要不可欠である。

テスト実装で用意するテスト環境は、テストでコントロールしている間に残っている(　)を洗い出し、 故障が発生しない場合は適切に動作し、より高いテストレベル向けの(　)環境またはエンドユーザー環境を 必要に応じて適切に再現できなければならない。

予期しない仕様変更、テスト結果、または他の考慮事項に応じて、テスト環境をテスト実行時に変更する必要がある。 テスト実行時にテスト環境を変更する場合、(　)済みのテストケースに対して変更が与える影響を評価することが重要となる。

テストアナリストは、テスト実装時に、テスト環境の作成およびメンテナンスの担当者の(　)を得ることができ、 かつすべてのテストウェアやテストサポートツールおよび関連するプロセスが(　)できる状態にあることを確認すべきである。

テスト実装において、テスト環境作成のサポートをメンテナンス担当者から得て、 すべてのテストサポートツールが使用できる状態であることを確認するべきである。 これらのプロセスは、(　)管理、(　)マネジメント、および(　)結果の記録やマネジメントを含む。

テスト実装において、テストアナリストは、 終了基準に対する現在のステータスの評価およびテスト結果のレポート作成のための(　)を収集する手順を検証しなければならない。

テスト実装では、テスト(　)で決定したバランスのとれたアプローチを使用することを推奨する。 例えば、分析的なリスクベースドテスト戦略に対処的テスト戦略を混ぜることがよくある。 この場合、テスト実装作業の一部を、事前に決定したスクリプトに従わないテスト（スクリプトがないテスト）に割り当てる。

対処的テスト戦略などの、スクリプトがないテストを行うと、期間とカバレッジの予測が困難になることがあり、 欠陥の検出率が低下することがあるので、ランダムまたは(　)がないものにするべきではない。

スクリプトがないテストは、(　)ボックスにしたセッションとして行うべきであり、 それぞれのセッションでは、テストチャーターが最初の方向性を与えるべきであるが、 セッションの中でより生産性の高いテストを行う機会が見つかった場合には、 チャーターが与えた方向性から自由に離れてよい。

対処的テスト戦略について、テスト担当者は長い年月をかけて、攻撃、エラー推測、探索的テストなど、 様々な(　)ベースのテスト技法を開発してきた。 これらは、テスト分析、テスト設計、およびテスト実装は引き続き行われるが、主にテスト実行期間に行われることになる。

対処的テスト戦略の場合、各テストの(　)は、以降のテストの分析、設計、および実装に影響を及ぼす。

対処的テスト戦略は軽量であり、多くの場合、欠陥を見つけるのに有効であるが、以下に示す短所もある。 テストアナリストに(　)知識を要求する

対処的テスト戦略は軽量であり、多くの場合、欠陥を見つけるのに有効であるが、以下に示す短所もある。 期間の(　)が困難

対処的テスト戦略は軽量であり、多くの場合、欠陥を見つけるのに有効であるが、以下に示す短所もある。 カバレッジの(　)が困難

対処的テスト戦略は軽量であり、多くの場合、欠陥を見つけるのに有効であるが、以下に示す短所もある。 テストの(　)性を維持するために優れたドキュメントやツールのサポートが必要

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む 手動(　)（探索的テストを含む）を実行する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む 自動(　)を実行する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む 実行結果と期待結果を(　)する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む 不正を分析して、可能性のある(　)を特定する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む 故障を観察し、観察に基づいて(　)を報告する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む テスト実行の実際の結果を(　)する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む テスト結果を検討するためテストベースとテストウェアの間で(　)を更新する

テスト実行はテスト実行スケジュールに従って行い、次のタスクを含む (　)テストを実行する

テスト実行タスクは、テスト(　)またはテスト(　)が行う。 ・手動テスト（探索的テストを含む）を実行する ・自動テストを実行する ・実行結果と期待結果を比較する ・不正を分析して、可能性のある原因を特定する ・故障を観察し、観察に基づいて欠陥を報告する ・テスト実行の実際の結果を記録する ・テスト結果を検討するためテストベースとテストウェアの間でトレーサビリティを更新する ・リグレッションテストを実行する

次に示すタスクは、テスト実行においてテストアナリストが追加で行う可能性がある典型的なタスクである。 (　)が集中しており、さらなるテストが必要になりうるテスト対象の一部を特定する

次に示すタスクは、テスト実行においてテストアナリストが追加で行う可能性がある典型的なタスクである。 探索的テストからの発見事項に基づいて、(　)の探索的テストに対する提案を作成する

次に示すタスクは、テスト実行においてテストアナリストが追加で行う可能性がある典型的なタスクである。 テスト実行タスクを行う際に取得した情報から新しい(　)を識別する

次に示すタスクは、テスト実行においてテストアナリストが追加で行う可能性がある典型的なタスクである。 テスト実装活動からのあらゆる作業成果物を(　)するための提案を作成する（テスト手順に対する改善など）

(　)は、多くの場合、リスクベースドテスト戦略の確立とマネジメントに全体的な責任を持つ。

テストマネージャーは、通常、リスクベースドアプローチが適切に実装されるようにするために、(　)の関与を要求する。

テストアナリストは、次のリスクベースドテストのタスクに積極的に関わるべきである。 ・リスク(　) ・リスク(　) ・リスク(　)

リスクベースドテストでは、(　)の新たな発生および優先度の変更に対処する。 定期的にリスクのステータスを評価および共有するために、これらのタスクを SDLC 全体を通して反復的に実行する

アジャイルソフトウェア開発では、リスクベースドテストのリスク対処・リスクの優先度変更・それらの反復的な実行は、 イテレーションまたはリリースのいずれかに焦点を置いた、いわゆるリスク(　)に組み入れられる。

テストアナリストは、テストマネージャーがプロジェクトのために確立したリスクベースドテスト(　)内で作業すべきである。

リスクベースドテストにおいて、 機能安全、ビジネスおよび経済上の懸念、政治的な要因に関連するリスクなど、 プロジェクトに内在するビジネスドメインのリスクに関するテストアナリスト自身の(　)を提供すべきである。

リスクベースドテストのリスク識別プロセスでは、 可能な限り幅広い(　)を召集することにより、重要なリスクを数多く検出することが可能になる。

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している そのドメインの専門家やユーザーとともに行う専門家への(　)の実施

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している 独立した(　)の実施

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している リスク(　)の使用

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している リスク(　)への参加

テストアナリストは多くの場合、テスト対象システムの特定のビジネスドメインに関する特有の 知識を保有するので、次のタスクに非常に適している。 潜在的ユーザーや現在のユーザーとの(　)セッションへの参加

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している テスト用(　)リストの定義

リスクベースドテストにおいて、テストアナリストは多くの場合、 テスト対象システムの特定のビジネスドメインに関する特有の知識を保有するので、次のタスクに非常に適している 類似のシステムまたはプロジェクトにおける過去の(　)の活用

リスクベースドテストにおいて、特にテストアナリストは、 ユーザーおよび他のドメインの(　)（要件エンジニア、ビジネスアナリストなど）と緊密に連携して、 テスト中に対応すべきビジネスリスクの領域を決定するべきである。

リスクベースドテストについて、アジャイルソフトウェア開発では、(　)と緊密に連携することにより、 イテレーション計画ミーティングなどの定期的なイベントでリスク識別を実施することが可能になる。

リスクベースドテストにおいて、プロジェクトで識別される可能性のあるリスクの例は次の通り。 機能の(　)性の問題（例えば、誤った計算）

リスクベースドテストにおいて、プロジェクトで識別される可能性のあるリスクの例は次の通り。 (　)性の問題（例えば、キーボードショートカットの不足）

リスクベースドテストにおいて、プロジェクトで識別される可能性のあるリスクの例は次の通り。 (　)性の問題（例えば、アプリケーションを特定のプラットフォームにインストールできない）

リスクベースドテストにおけるリスク(　)は、可能な限り多くのリスクを識別することを意味する。

リスクベースドテストにおけるリスク(　)は、リスク識別で識別されたリスクを調査することを意味する。

リスクベーステストにおけるリスクアセスメントでは、それぞれのリスクを分類して、そのリスク(　)を判定する

リスクベースドテストにおいて、(　)レベルを決定する場合、通常はリスクアイテムごとに、リスクの可能性および影響を評価する。

リスクの可能性は、潜在的な問題がテスト対象のシステムに存在し、システムが(　)環境に移行した後に観察される可能性と考えることができる。

テクニカルテストアナリストは、各リスクアイテムの検出とそれぞれの潜在的な可能性の理解に貢献しなければならないが、 テストアナリストは問題が発生した場合に(　)に対して起こりうる影響の把握に貢献する （アジャイルソフトウェア開発では、この役割ベースの区別は曖昧なことが多い）。

リスクアセスメントにおいて、リスクの影響は多くの場合、ユーザー、顧客、またはその他のステークホルダーに対する影響の(　)度と考えることができる。ビジネスリスクに起因するリスク発生の影響とも言える

リスクアセスメントにおいて、テストアナリストは、各リスクアイテムがビジネスドメインやユーザーに及ぼす潜在的な(　)を識別および評価する必要がある。

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す 影響を受けるフィーチャーの(　)頻度

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す ビジネス(　)

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す 金銭的(　)

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す 環境保護的または社会的損失、または(　)の可能性