リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す 民事上または刑事上の法的(　)

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

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

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す さらなる作業を行うことができない場合、妥当な(　)策の欠如

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

リスクアセスメントにおいて、ビジネスリスクに影響する要因を次に示す 故障の判明による社会的および潜在的な(　)の悪化

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

リスクアセスメントにおいて、テストアナリストは、利用可能なリスク情報を活用し、 テストマネージャーにより提供されたガイドラインに基づいて、ビジネスリスクの(　)を確立する必要がある。

確立されたビジネスリスクレベルは、使用している順序(　)（数値、または、低、中、高）または信号機の色を用いて分類することがある。

リスクの可能性と影響が割り当てられると、テストマネージャーはこれらの値を使用して各リスクアイテムのリスク(　)を決定する。 次に、そのリスク(　)を使用して、リスク軽減活動の優先度を決定する

リスク軽減に関連して、プロジェクト期間においてテストアナリストは、次のことに努めるべきである。 テストが合格したか不合格したかを一意に示す明確なテスト(　)を設計する。

リスク軽減に関連して、プロジェクト期間においてテストアナリストは、次のことに努めるべきである。 要件、設計、およびユーザードキュメントなどのソフトウェア作業成果物の(　)に参加することにより、プロダクトリスクを軽減する

リスク軽減に関連して、プロジェクト期間においてテストアナリストは、次のことに努めるべきである。 テスト戦略およびテスト計画で識別される適切なリスク(　)活動を実装する （例えば、特別なテスト技法を使用して、特にリスクの高いビジネスプロセスをテストする） 。

リスク軽減に関連して、プロジェクト期間においてテストアナリストは、次のことに努めるべきである。 プロジェクトの進み具合に応じて収集した追加情報に基づいて、既知のリスクを再(　)する。 この際、必要に応じて、リスクの可能性や影響、またはその両方を調整する。

リスク軽減に関連して、プロジェクト期間においてテストアナリストは、次のことに努めるべきである。 テスト期間中に収集された情報から、新しい(　)を識別する。

プロダクトリスクが話題として取り上げられる場合、テストはそのような(　)の軽減に大きく貢献する。

テスト担当者は欠陥を見つけることにより、欠陥が認識されるようにし、 (　)前に欠陥に対処する機会を提供して、リスクを軽減する。

テスト担当者が欠陥をまったく見つけなかった場合、 テストされた特定の条件下でシステムは正しく動作するという証拠を提供することによって、テストがリスクを(　)したことになる。

テストアナリストは、特に、正確なテスト(　)収集のための機会の調査、 現実的なユーザー(　)の作成とテスト、および(　)性調査の実践または監督を行うことで、 リスク軽減の選択肢を決定することを支援する。

リスクのレベルはテストケースの(　)付けにも使用する。 例えば、テストアナリストが、会計システムでトランザクションの正確性の領域に高いリスクを見つけた場合、 テスト担当者は、リスクを軽減するために、他のビジネスドメインの専門家と協力して、 正確性のために処理および検証できる多数のサンプルデータセットを収集するかもしれない。

テストの優先度付けにおいて、テストアナリストは、 必要なテストを必要なタイミングで実施できるようにスケジュールするため、 計画段階の可能な限り(　)にこの優先度付けを考慮しなければならない。

テストの優先度付けにおいて、場合によっては、すべての高リスクのテストケースを、 低リスクのテストケースよりも先に実行したり、厳格なリスク順にテストケースを実行したりする。 これは「(　)探索」（depth-first）と呼ばれる。

テスト優先度付けにおいて、サンプリングアプローチを使用して、 識別したすべてのリスク領域をカバーするテストケースのサンプルを選択する。 これは「(　)探索」（breadth-first）と呼ばれる。 この方法では、リスクレベルに基づいて選択に重みを付け、同時に、すべてのリスクアイテムを少なくとも 1 回はカバーするようにする。

リスクベースドテストを縦型探索と横型探索のどちらで進めても、 すべてのテストを実行しないうちにテストに割り当てた時間を消費してしまう可能性がある。 リスクベースドテストでは、その時点における残りのリスク(　)についてテスト担当者がマネジメントにレポートし、 マネジメントでテストを延長するか、あるいは残りのリスクをユーザー、顧客、 ヘルプデスク／テクニカルサポート、運用スタッフに移転するかを決定できる。

リスクアセスメントは、テスト実装を開始する前に 1 度だけ実行する活動ではなく、(　)するプロセスである。

将来のテストサイクルに向けたテストの調整に関連して、 将来に計画されている各テストサイクルでは、以下に示す要素を考慮するため、新しくリスク分析をすべきである。 新しい、または大幅に変更されたプロダクト(　)

将来のテストサイクルに向けたテストの調整に関連して、 将来に計画されている各テストサイクルでは、以下に示す要素を考慮するため、新しくリスク分析をすべきである。 テスト時に発見された不安定または故障の(　)領域

将来のテストサイクルに向けたテストの調整に関連して、 将来に計画されている各テストサイクルでは、以下に示す要素を考慮するため、新しくリスク分析をすべきである。 修正された(　)からのリスク

将来のテストサイクルに向けたテストの調整に関連して、 将来に計画されている各テストサイクルでは、以下に示す要素を考慮するため、新しくリスク分析をすべきである。 テスト時に発見された典型的な(　)

将来のテストサイクルに向けたテストの調整に関連して、 将来に計画されている各テストサイクルでは、以下に示す要素を考慮するため、新しくリスク分析をすべきである。 テストが不十分な（要件(　)の低い）領域

ブラックボックステスト技法に共通する特徴としては以下のものがある。 状態遷移図やデシジョンテーブルなどのモデルは、テスト技法に従ってテスト(　)時に作成する

ブラックボックステスト技法に共通する特徴としては以下のものがある。 (　)条件は、状態遷移図やデシジョンテーブルなどのモデルから体系的に導き出す

テスト技法は、一般的に、テスト設計およびテスト実行の活動を測定するために使用できる(　)基準を提供する。

カバレッジ基準を十分に満たすことは、すべてのテストケースのセットを完了することを意味するのではなく、 その技法に基づいて(　)を高めるために追加するテストケースがモデルにはこれ以上ないことを意味する。

ブラックボックステストは、通常、システム要件仕様やユーザーストーリーといった、何かしらの仕様(　)に基づく

ブラックボックステストで使用する仕様ドキュメントには、特に(　)適合性に関するシステムの振る舞いが記述してあるべきである。 そのため、要件からテストケースを導き出すことは、システムの振る舞いに対するテストの一部となることが多い。

ブラックボックステストにおいて、場合によっては、仕様ドキュメントが存在しないことがあるが、 旧システムからの機能適合性の置き換えといった(　)的な要件は存在する。

同値分割法（EP）は、入力、出力、内部値、および時間関連の値の処理を効果的にテストする場合に 必要なテストケースの数を(　)するために使用する技法である。

同値分割法は、同じように処理される必要のある値のセットとして作成される同値(　)（同値クラスとも呼ばれる）を作成するために分割法を使用する。

同値分割法は、パーティションから 1 つの代表値を選択することにより、同じパーティション内のすべてのアイテムに対する(　)と見なす。

同値分割法では通常、複数の(　)がテスト対象の振る舞いを決定する。 異なるパラメーターの同値パーティションをテストケースにまとめる際には、様々な手法が適用できる。

同値分割法は、(　)のテストレベルで適用できる

同値分割法は、テストすべき値セットのすべての要素が(　)方法で処理されることが期待され、 アプリケーションにより使用される値セット同士が相互作用しない場合に適している。

同値分割法の同値パーティションは、順序あり、順序なし、離散、連続、無限、有限、さらには 1 つだけといった何かしらの値の(　)となる。

同値分割法の値のセットの選択は、有効(　)および無効(　)（つまり、テスト対象のソフトウェアに対して無効であると見なされるべき値を含むパーティション）に適用できる。

同値分割法は、テストする値の範囲をパーティションの境界まで広げる(　)分析と組み合わせて使用すると最も強力になる。

有効なパーティションからの値を使用することで、同値分割法は基本的な機能が動作していることを素早く判断できるので、一般的に、新しいビルドまたはリリースを(　)テストする場合に使用する。

同値分割法は、(　)が正しくなく、パーティション内の値が正確に同じ方法で処理されない場合、欠陥を見逃す可能性がある。

同値分割法では、(　)を注意深く選択することも重要である。 例えば、正の数と負の数を受け入れる入力欄は処理方法が異なる可能性があるので、正の数と負の数の 2 つの有効パーティションとしてテストする方がよい。ゼロを許容するかどうかによって、パーティションが追加される場合もある（ゼロは正でも負でもない）。

テストアナリストは、最適なパーティションを決定するために、裏にある処理を理解することが重要である。 このためには、(　)設計を理解するための支援が求められる場合がある。

同値分割法においてテストアナリストは、異なるパラメーターの同値パーティション間で起こりうる(　)関係も考慮すべきである。 例えば、フライト予約システムでは、パラメーター「大人の同伴」は、年齢クラス「子ども」との組み合わせでのみ使用することがある。

同値分割のカバレッジは、(　)されたパーティションの数を、識別されたパーティションの数で除算することにより決定し、パーセンテージで表される。

同値分割のカバレッジは、(　)のパーティションに含まれる複数の値をテストしても、カバレッジの割合を増やすことにはならない。

同値分割のカバレッジにおいて、テスト対象の振る舞いが(　)のパラメーターに依存する場合、各同値パーティションが有効、無効であるかに関わらず、少なくとも一度はカバーすべきである。

複数のパラメーターがある場合、テストアナリストは、(　)に応じて、カバレッジタイプをシンプル、または組み合わせのどちらかを選択すべきである。そのため、有効なパーティションのみを含む組み合わせと、1 つ以上の無効なパーティションを含む組み合わせを区別することが重要になる。

有効な同値パーティションのみが含まれる組み合わせについては、すべてのパラメーターについて、すべての有効なパーティションのシンプルなカバレッジが最低条件である。このようなテストスイートに必要なテストケースの最小数は、パラメーターが互いに独立していると仮定した場合、パラメーターの有効なパーティションの(　)数に等しい。

同値分割のカバレッジについて、組み合わせ技法に関するより十分なカバレッジタイプには、(　)カバレッジや、有効なパーティションの任意の組み合わせに対する(　)カバレッジがある。

(　)をマスクしてしまうことを避けるために、少なくとも無効な同値パーティションは個別に、つまり他のパラメーターは有効なパーティションにした組み合わせでテストすべきである。そのため、シンプルなカバレッジのためのテストスイートでは、各無効パーティションに 対して 1 つずつのテストケースとなる。

(　)が高い場合には、無効なパーティションのみの組み合わせ、あるいは無効なパーティションのペアなど、さらなる組み合わせをテストスイートに追加することがある

テストアナリストは同値分割法を使用して、様々な(　)の処理に関する欠陥を検出できる。

境界値分析（BVA）は、順序付けられた同値パーティションの(　)上に存在する値を適切に処理していることをテストするために使用する。

境界値分析には、一般的に 2 つの値を用いる方法と 3 つの値を用いる方法の 2 つの方法がある。 2 つの値を用いる境界のテストでは、境界値（境界上）と境界を少し(　)た値（必要な精度に基づいた可能な限り最小の増加分）を使用する。

2 つの値を用いる境界値分析テストの境界は、定義された(　)パーティションの最大値と最小値によって定義される。

3 つの値を用いる境界のテストでは、境界上、および境界の(　)の値を使用する。

境界値分析において2 つの値、または 3 つの値を用いるテストのどちらを使用するかの判断は、テスト対象のアイテムに関連する(　)に基づくべきである。(　)の高いアイテムに対しては 3 つの値を用いる方法を使用する。

境界値分析は、(　)のテストレベルで適用でき、順序付けられた同値パーティションが存在するときに適している。この理由により、BVA 技法は EP 技法と一緒に使用することが多い。

境界値分析は、境界上および境界外の概念を考慮するために、順序付けられた(　)パーティションが必要である。

境界値分析の正確性は、境界を正しく識別するために同値パーティションの正確な識別に依存するので、(　)法と同じ制限と注意事項の対象となる。

境界値分析においてテストアナリストは、テスト対象の値を正確に決定できるようにするために、有効値および無効値の(　)に注意する必要がある。

境界値分析では順序付けられたパーティションのみを使用できるが、(　)な入力の範囲に制限されるものではない。例えば、スプレッドシートでサポートされるセルの数をテストする場合、許容される最大数（境界）を含むそれまでのすべてのセルで構成されるパーティションと、最大数を 1 つ超えたセルで始まるパーティション（境界外）が存在する。

カバレッジは、テスト済みの境界条件の数を、（2 つの値を用いる方法または 3 つの値を用いる方法のいずれかで）(　)された境界条件の数で除算することにより決定し、パーセンテージで表される。

境界値分析は、(　)のずれ、または欠落を高い信頼性で発見する。

境界値分析は、(　)な境界を見つけることもある。

境界値分析は、特に「より小さい」および「より大きい」のロジックのエラー（ずれ）など、境界値の(　)に関連する欠陥を発見するために使用する。

例えば、システムは 10,000 人の同時ユーザーをサポートするが 10,001 人の同時ユーザーはサポートしないなどの(　)欠陥を発見するためにも境界値分析を使用する。

デシジョンテーブルは、条件のセットとそれに関連するアクションを表形式で示しており、どの条件値のセットに対してどの(　)が発生するかを示すルールを表現している

テストアナリストは、デシジョンテーブルを使用して、テスト対象のソフトウェアに適用される(　)を分析し、その(　)をカバーするテストを設計することができる。

条件が「真」と「偽」というシンプルな値を持つブール型のデシジョンテーブルは、(　)指定デシジョンテーブルと呼ばれる。条件の例としては、「ユーザーの収入 < 1000」がある。

(　)指定デシジョンテーブルでは、条件が個別の要素または要素のセットを表す複数の値を持つことを許容する。例えば、「ユーザーの収入」という条件は、「1000 未満」、「1000 から 2000の間」、「2000 を超える」という 3 つの値のいずれかをとることができる。

デシジョンテーブルでは、シンプルなアクションはブール値「(　)」と「(　)」をとる（例えば、アクション「値引き許容 = 20%」は、アクションが発生すべき「真」の場合は「X」で示され、発生しない「偽」の場合は「-」で示される）。

デシジョンテーブルでは、条件と同様に、(　)も他の領域の値をとることがある。例えば、「値引き許容」という(　)は、0%, 10%, 20%, 35%, 50% の 5 つ値のうちの 1 つをとることができる。

デシジョンテーブルテストは、(　)書に基づいてデシジョンテーブルを設計することから始まる。

デシジョンテーブルテストの設計で、条件値の実現(　)な組み合わせを含むルールは除外するか、「実現不可能」とマークする。

デシジョンテーブルテストの設計が完了したあとは、テストアナリストは、他のステークホルダーとデシジョンテーブルを(　)する。

デシジョンテーブルのレビューでテストアナリストは、デシジョンテーブル内の(　)が一貫していること（ルールが重複していないこと）を確認する。

デシジョンテーブルのレビューでテストアナリストは、完全であること（実現(　)な条件値の組み合わせごとにルールが含まれていること）を確認する。

デシジョンテーブルのレビューでテストアナリストは、正しいこと（(　)した振る舞いをモデル化していること）確認する。

デシジョンテーブルテストの基本原則は、(　)がテスト条件になるということである。

与えられたルールをカバーするテストケースを設計する際、テストアナリストは、テストケースの(　)値がデシジョンテーブルの条件値と異なる可能性があることを認識すべきである。例えば、条件「年収 > 100,000（ドル） 」の 「真」となる 値は、直接適用できないかもしれず、テスト担当者の作業として、特定の会計年度に 100,000 を超える入金がある顧客の預金口座を定義することが必要となることがある。

与えられたルールをカバーするテストケースを設計する際、テストケースの期待結果は、デシジョンテーブルの(　)とは異なる場合がある。

デシジョンテーブルの準備ができたら、条件とアクションを満たすテスト入力値（および期待結果）を選択して、ルールを(　)として実装する必要がある。

条件に応じて可能なすべての入力の組み合わせをテストしようとすると、デシジョンテーブルは非常に大きくなる。n個の条件を持つ完全な制限指定デシジョンテーブルは、2の(　)個のルールを持つ。

組み合わせの数を体系的に減らす技法は、(　)化したデシジョンテーブルテストと呼ばれる。

デシジョンテーブルの簡単化を行うと、同じアクションのセットを持つルールのグループは、いくつかの条件の差異がこのグループ内のアクションに影響を与えず、かつ他のすべての条件が(　)ない場合にこのグループを 1 つのルールに縮小（簡単化）できる。

デシジョンテーブルの簡単化では、(　)性のない条件の値は「関係なし」と表記され、通常はダッシュ「-」を付ける。「関係なし」の値を持つ条件については、テストアナリストは、テスト実装のために任意の有効な値を指定することができる。

デシジョンテーブルを簡単化できるルールのもう 1 つの例は、ある条件値が他の条件値との組み合わせでは適用できない場合や、2 つ以上の条件が(　)する値を持つ場合である。例えば、カード決済のデシジョンテーブルでは、「カードが有効」という条件が偽の場合、「PIN コードが正しい」という条件は適用できない。

簡単化したデシジョンテーブルは、完全なデシジョンテーブルに比べてルールの数がはるかに少ない場合があり、結果的にテストケースの(　)が少なくなり工数が軽減できる。

もし、あるルールに「関係なし」という項目があり、そのルールをカバーするテストケースが 1 つしかない場合、そのルールでは、条件の中でテストできる値のうち 1 つしかテストされないため、他の値に含まれる欠陥が検出できないかもしれない。そのため、(　)レベルが高い場合には、テストアナリストはテストマネージャーと連携して、デシジョンテーブルを簡単化するのではなく、単一の条件値の実行可能な組み合わせごとにルールを分けて定義すべきである。

デシジョンテーブルテストは、通常、(　)テスト、(　)テスト、および(　)テストで適用する。

デシジョンテーブルテストは、コンポーネントに判定ロジックのセットに対する責務がある場合には、(　)テストにも適用できる。