要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 要件の(　)（人、部署など）

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 各要件の(　)性

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 各要件の(　)順位

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 各要件の(　)基準

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 ユースケースの呼び出し構造の(　)性（該当する場合）

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 各要件／ユースケース／ユーザーストーリーの一意な(　)子

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 各要件／ユースケース／ユーザーストーリーの(　)設定

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 ビジネス／マーケティング要件から各要件への(　)

要件レビューにおいて、要件指向のチェックリストが含むアイテムの例を以下に示す。 一貫性のある(　)の使用（例えば、(　)集の使用など）

要件がテストできない場合、つまりテストアナリストがどうテストをするか決められないように要件定義をしている場合、その要件には(　)があると認識することが重要である。例えば、「ソフトウェアは非常にユーザーフレンドリーであるべきだ」と記述されている要件はテストできない。

どのようにしたら、テストアナリストは、ソフトウェアがユーザーフレンドリーであるか、または非常にユーザーフレンドリーなのかを判断できるだろうか？ 代わりに、要件が「ソフトウェアは、使用性の標準ドキュメント、バージョン xxx で規定されている使用性の標準に適合していなければならない」と記述されており、使用性の標準ドキュメントが存在する場合、これは、(　)が可能な要件である。

要件が「ソフトウェアは、使用性の標準ドキュメント、バージョン xxx で規定されている使用性の標準に適合していなければならない」と記述されており、使用性の標準ドキュメントが存在する場合、これは、テストが可能な要件である。この 1 つの要件はインターフェースのすべての項目に適用するので、(　)的な要件でもある。

代わりに、要件が「ソフトウェアは、使用性の標準ドキュメント、バージョン xxx で規定されている使用性の標準に適合していなければならない」と記述されており、使用性の標準ドキュメントが存在する場合、これは、テストが可能な要件である。この 1 つの要件はインターフェースのすべての項目に適用するので、包括的な要件でもある。この場合、この 1 つの要件で、重要なアプリケーションの個別のテスト(　)を容易に多数作り出せることもある。

要件レビューにおいて、この要件、または使用性の標準ドキュメントからテストケースまでの(　)も重要である。なぜなら、参照する使用性の仕様の変更が発生した場合、すべてのテストケースをレビューして、必要に応じて更新する必要があるからである。

テスト担当者がテストの合格／不合格を(　)できない場合、または合格／不合格にするテストを構築できない場合も、その要件はテストできない。例えば、「システムは時間の 100%、つまり、1 日 24 時間、週 7 日、年 365 日（または 366 日）の可用性を提供しなければならない」という要件はテストできない。

ユースケースレビューの単純なチェックリスト1は、次の質問を含む場合がある。 メインの(　)（パス）は明確に定義されているか？

ユースケースレビューの単純なチェックリスト1は、次の質問を含む場合がある。 すべての(　)の振る舞い（パス）は識別されており、エラー処理は完全に備わっているか？

ユースケースレビューの単純なチェックリスト1は、次の質問を含む場合がある。 ユーザーインターフェース(　)は定義されているか？

ユースケースレビューの単純なチェックリスト1は、次の質問を含む場合がある。 (　)の振る舞いは 1 つだけか （1 つであるべきであり、そうでない場合、複数のユースケースとなる）？

ユースケースレビューの単純なチェックリストは、次の質問を含む場合がある。 それぞれの振る舞いは(　)可能か？

アジャイルソフトウェア開発では、一般的に、要件をユーザーストーリーの形式で表す。これらのストーリーは、(　)可能な機能の小さな単位を表す。

ユースケースは、機能の複数の領域を横断するユーザートランザクションであるが、ユーザーストーリーはより独立した(　)であり、一般的に開発にかかる時間によりその範囲が決まる。

ユーザーストーリー向けのチェックリストは次に示す質問を含めることができる。 ストーリーは対象の(　)／スプリントにとって適切か？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 ストーリーは(　)者の観点で記述されているか？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 (　)基準は定義されており、テスト可能か？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 (　)は明確に定義されており、他と区別できるか？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 ストーリーは他のいずれの(　)から独立しているか？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 ストーリーに(　)が割り当てられているか？

ユーザーストーリー向けのチェックリスト 1は次に示す質問を含めることができる。 ストーリーは一般的に使用される形式に従っているか？ （<ユーザーの種類>として、<ある(　)>をしたい、なぜなら<ある理由>だから

ストーリーが新しいインターフェースを定義する場合は、前述のような汎用的なストーリー(　)および詳細なユーザーインターフェース(　)を使用することが適切である。

チェックリストは、次の項目に基づいて調整できる (　)（例：企業ポリシー、標準、慣習、および法的制約の考慮）

チェックリストは、次の項目に基づいて調整できる (　)／開発の取り組み（例：重点項目、技術的標準、リスク）

チェックリストは、次の項目に基づいて調整できる レビュー対象の(　)物の種類（例：コードレビューは特定のプログラム言語向けに調整することがある）

チェックリストは、次の項目に基づいて調整できる レビュー対象の(　)物のリスクレベル

チェックリストは、次の項目に基づいて調整できる 使用するテスト(　)

優れたチェックリストは、問題を発見しやすくし、チェックリストで特別に(　)されていない可能性のある他のアイテムに関する議論を開始するのに役立つ。

チェックリストを(　)て使用すると、レビューを通して作業成果物の品質を最も高くすることができる。

標準チェックリストとともにチェックリストベースドレビューを使用し、前述のような(　)固有のチェックリストを開発すると、テストアナリストは効果的にレビューを実行できる。

テストアナリストは、開発者、テスト自動化エンジニア、およびテクニカルテストアナリストと連携してテスト(　)化ソリューションを構築する点に気を付けるべきである。

(　)自動化では特に、テストアナリストの貢献度が高く、ビジネスおよびシステム機能性に関する経験が活かされる。

(　)テストは、主要なテスト自動化手法の 1 つで、テストアナリストは主となる入力であるキーワードとデータを提供する。

キーワード（アクションワードとも呼ばれる）は、例外はあるが、ほとんどの場合、(　)とシステムのハイレベルな相互作用（例えば、注文の取り消し）を表すために使用する。

キーワード駆動テストの各キーワードは、一般的に、(　)とテスト対象のシステムとの間にあるいくつかの詳細な相互作用を表すために使用する。

テスト自動化では、(　)を 1 つ以上の実行可能テストスクリプトとして実装する。

(　)はキーワードの配列として記述したテストケースを読み込む。

キーワードの列は、キーワードの機能を実装する適切なテスト(　)を呼び出す。

スクリプトは特定のキーワードに容易にマッピングできるように、高度に(　)化して実装する。これらの(　)化したスクリプトを実装するには、プログラミングスキルが必要になる。

キーワード駆動テストの主な利点を次に示す。 特定のアプリケーションまたはビジネスドメインに関連するキーワードは、ドメインの(　)が定義できる。 これにより、テストケース仕様作成のタスクがより効率的になる。

キーワード駆動テストの主な利点を次に示す。 主要なドメインの専門知識を持つ人が、基になる自動化スクリプトの(　)を理解する必要なく、 自動化テストケース実行の利点を受けられる（キーワードをスクリプトとして実装した場合）。

キーワード駆動テストの主な利点を次に示す。 (　)型記述技法を使用すると、テスト対象のソフトウェアの機能およびインターフェースに対する変更が発生した場合に、 テスト自動化エンジニアはテストケースを効率的にメンテナンスできる

キーワード駆動テストの主な利点を次に示す。 テストケース仕様は、その実装から(　)している。

キーワード駆動テストにおいて、テストアナリストは通常、キーワード/アクションワードデータを作成および(　)する。

キーワード駆動テストにおいてテストアナリストは、キーワードを実装するために、(　)開発のタスクが引き続き必要であることを認識すべきである。

キーワード駆動テストにおいて、テストアナリストが使用するキーワードとデータを定義した後は、テスト自動化担当者（テクニカルテストアナリストまたはテスト自動化エンジニアなど）が、ビジネスプロセスのキーワードとローレベルのアクションを自動化テスト(　)に変換する。

キーワード駆動テストは、一般的に、システムテストで実行するが、(　)のコード開発はテスト設計のできる限り早い時期に始まることがある。

イテレーティブ環境では、特に継続的インテグレーション/継続的デプロイを使用する場合、テスト自動化開発は(　)して行うプロセスである。

入力キーワードおよびデータの作成が完了したら、テストアナリストは、キーワード駆動テストケースを実行し、故障が発生した場合にはその(　)を行う責任を担う。

不正を検出したら、テストアナリストは故障の原因の調査をすることで、欠陥がキーワード、入力データ、テスト自動化スクリプト自体にあるのか、またはテスト対象のアプリケーションにあるのかを判断する(　)をすべきである。

キーワード駆動テストで不正を検出したとき、通常、トラブルシューティングの最初の手順では、(　)データを使用して(　)テストケースを手動で実行し、故障がアプリケーション自体に存在するかどうかを確認する。

キーワード駆動テストで不正を検出して、最初のトラブルシューティングで故障が発生しない場合、テストアナリストは、故障につながるテストケースの(　)をレビューし、問題は先行する手順で発生している（正しくない入力データが投入されているかもしれない）が、後続の処理まで表面化しないのかどうかを判定する。

テストアナリストがキーワード駆動テストでの故障の原因を判定できない場合、さらなる分析を行うために、トラブルシューティング情報をテクニカルテストアナリストまたは(　)に渡すべきである。

多くのテストアナリストが担当する作業では、ツールを有効に使用する必要がある。 この際、以下によってツールの有効性を高めることができる。 使用すべき(　)を知っている

多くのテストアナリストが担当する作業では、ツールを有効に使用する必要がある。 この際、以下によってツールの有効性を高めることができる。 ツールがテスト作業の(　)を高められる（例えば、許容される時間内によりよいカバレッジを提供する一助になることによる）ことを知っている

テスト(　)ツールは、テストに適用するテストケースおよびテストデータの作成を支援するために使用する。

テスト(　)ツールは、特定の要件ドキュメント形式、モデル（UML など）、またはテストアナリストが提供する入力に基づいて動作する。

テスト(　)ツールは、多くの場合、特定の形式および特定のツール（特定の要件マネジメントツールなど）と連携して動作するように設計および構築する。

テスト設計ツールは、特定の狙ったレベルのカバレッジ、システムへの確証、またはプロダクトリスク軽減アクションを達成するために必要なテストケースの種類を決定するための(　)をテストアナリストに提供する。例えば、クラシフィケーションツリーツールは、選択したカバレッジ基準に基づくカバレッジを完全に達成するために必要な組み合わせセットを生成（および表示）する。

テスト設計ツールは、特定の狙ったレベルのカバレッジ、システムへの確証、またはプロダクトリスク軽減アクションを達成するために必要なテストケースの種類を決定するための情報をテストアナリストに提供する。テストアナリストはこの情報を使用して、実行する必要のあるテスト(　)を決定できる。

テストデータ準備ツールには、次の利点がある。 要件ドキュメント、さらにはソースコードなどのドキュメントも分析して、カバレッジのレベルを達成するためにテストする中で必要な(　)を決定する。

テストデータ準備ツールには、次の利点がある。 データセットを本番システムから取得し、データの内部的な整合性を維持しながら、「選別(scrub)」または匿名化を実行して(　)を削除できる。 選別したデータは、(　)の漏えい、または誤用のリスクを発生させることなく、テストに使用できる。 この機能は、現実的なデータを大量に必要とする場合、およびセキュリティとデータプライバシーのリスクが危惧される場合に、特に重要となる。

テストデータ準備ツールには、次の利点がある。 特定の入力パラメーターの(　)から合成テストデータを生成できる（例えば、ランダムテスト用）。 これらのツールのいくつかは、データベース構造を分析して、テストアナリストから要求される入力が何かを判断する。

テスト(　)ツールは、自動化したテストを実行し、実際の結果を確認するためにすべてのテストレベルでテストアナリストが使用する。

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。 (　)削減のため（工数、および／または時間の観点から）

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。 より多くのテスト(　)を実行するため

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。 同じテストケースを多くの(　)で実行するため

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。 テスト実行の(　)性を向上するため

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。 (　)で実行できないテストケースを実行するため（例：大規模なデータ妥当性確認テスト）

テスト実行ツールを使用する目的は、通常、次の 1つまたは複数の項目に該当する。これらの目的は、多くの場合、コスト削減しながら(　)を上げるという主要な目的と重なる。

テスト実行ツールの投資効果は、通常(　)テストを自動化したときに最高となる。これは、少ないメンテナンス工数が期待され、かつテストを繰り返し実行するためである。

(　)テストの自動化でも、頻繁なテストケースの利用、迅速なテスト結果の取得、および継続的インテグレーション環境で新しいビルドを評価するための自動化ができることにより、自動化ツールを有効に使用できる。

スモークテストの自動化でも、頻繁なテストケースの利用、迅速なテスト結果の取得、および継続的インテグレーション環境で新しいビルドを評価するための自動化ができることにより、自動化ツールを有効に使用できる。ただし、継続的インテグレーション環境で新しいビルドを評価するための自動化は、メンテナンスコストが(　)なることもある。

テスト実行ツールは、一般的に(　)テストおよび(　)テストで使用する。特に API テストツールなどの一部のツールは、コンポーネントテストでも使用することがある。最も適した状況でツールを活用することにより、投資効果が向上する。