機能(　)性テストでは、その意図および指定された任務に対する一連の機能が適切であることを評価および妥当性確認する。

機能適切性テストトは、(　)設計（ユースケース、ユーザーストーリーなど）に基づくことができる。

機能適切性テストは、通常、(　)テスト時に実施するが、(　)テストの後半段階でも実施することがある。

機能適切性テストで見つかる欠陥は、許容できると考えられる方法であってもシステムがユーザーの(　)を満たすことができないことを示している。

機能(　)性テストは、実装した機能の指定された任務およびユーザー目的に対するカバレッジを判定するために実行する。

仕様アイテム（要件、ユーザーストーリー、ユースケースなど）と実装された機能性（機能、コンポーネント、ワークフローなど）の間の(　)は、必要となる機能完全性を判定するために不可欠である。

機能完全性を測定する方法は、特定のテスト(　)そして/または使用する SDLC によって異なる。例えば、アジャイルソフトウェア開発の機能完全性は、実装されたユーザーストーリーおよびフィーチャーに基づくことがある。

システム統合テストでの機能完全性は、ハイレベルなビジネスプロセスの(　)に重点を置くことがある。

機能完全性の判定作業は一般的に、テスト(　)ツールを使用して行うことができるが、その場合、テストアナリストはテストケースと機能仕様アイテムの間のトレーサビリティを維持する必要がある。

期待される度合いの機能完全性を達成できない場合、システムの(　)が不完全であることが示唆される。

相互(　)性テストは、2 つ以上のシステムまたはコンポーネントが情報を交換できることを検証する。

相互運用性テストのテストケースは、(　)を交換し、その後交換した(　)を使用できる能力に重点を置く。

相互運用性テストでは、データ交換が適切に機能することを確認するために、ハードウェア、ソフトウェア、ミドルウェア、オペレーティングシステムなどのバリエーションを含む、すべての意図した対象(　)をカバーする必要がある。

現実的には、すべての意図した対象環境をカバーするのは、比較的少数の環境に限られるかもしれない。このため、相互運用性テストを行うのは、選択した代表的な環境(　)に限定することがある。

相互運用性向けにテストケースを仕様化するには、意図した対象(　)の組み合わせを識別し、構成し、テストチームが利用できるようにする必要がある。その後、機能適合性のテストケースから、環境内に存在する様々なデータ交換箇所を動作させるテストケースを選択し、これらの環境をテストする。

相互運用性とは、様々なコンポーネントとソフトウェアシステムが互いにどのように(　)作用するかということである。

優れた相互運用性を備えたソフトウェアは、大きな変更や非機能的な振る舞いへの重大な影響を必要とせずに、他の多くのシステムと(　)できる。

変更回数と、それらの変更を実装してテストするために必要な(　)を相互運用性の尺度として使用できる。

ソフトウェアの相互運用性をテストするには、例えば、次の設計上の特徴に重点を置くことができる。 XML など業界標準の(　)規格の使用

ソフトウェアの相互運用性をテストするには、例えば、次の設計上の特徴に重点を置くことができる。 相互作用するシステムが通信上必要なものを自動的に検出し、それに従って(　)する能力

相互運用性テストは、次に対して特に重要なことが多い。 市販の(　)ソフトウェアプロダクトやツール

相互運用性テストは、次に対して特に重要なことが多い。 (　)に基づくアプリケーション

相互運用性テストは、次に対して特に重要なことが多い。 モノのインターネット（Internet of Things（　））に基づくシステム

相互運用性テストは、次に対して特に重要なことが多い。 他のシステムとの(　)を有する Web サービス

相互運用性テストは、(　)統合テスト時および(　)統合テスト時に行う。

システム統合レベルでは、相互運用性テストは、開発完了したシステムが他のシステムとどの程度上手く(　)作用するかを判定するために実施する。

システムは、複数のレベルで相互運用を行う可能性があるので、テストアナリストはこれらの相互作用を理解し、様々な相互作用を動作させる(　)を作成できなければならない。例えば、2 つのシステムがデータを交換する場合、テストアナリストはデータ交換を動かすために必要なデータとトランザクションを作成できなければならない。

すべての相互作用が要件ドキュメントで明確に記述されているとは限らないことを覚えておくことが重要である。むしろ、これらの相互作用の多くは、システムアーキテクチャーおよび設計(　)でのみ定義している。

相互運用性テストでテストアナリストは設計ドキュメントを調査して、システム間およびシステムとその環境との間の(　)交換をしている箇所を特定し、すべてのテストを確実に行うことができるように準備しなければならない。

同値分割法、境界値分析、デシジョンテーブル、状態遷移図、ユースケース、およびペアワイズテストなどの(　)はすべて、相互運用性テストに適用できる。

相互運用性テストで典型的に見つかる欠陥には、相互作用する(　)間の不適切なデータ交換がある。

テストアナリストは、使用性の(　)作業を調整および支援する立場にいることが多い。

テストアナリストの使用性評価には、使用性のテスト(　)を仕様化するか、ユーザーと一緒にテストケースを実施するモデレーターとしての役割が含まれる。。テストアナリストはこれを効果的に行うために、これらの種類のテストに関連する主要な側面、ゴール、および手法を理解する必要がある。

使用性評価には、ユーザーがシステムを使いにくいと感じる、または（エンターテイメントのためにソフトウェアを使用する場合など）好ましいユーザーエクスペリエンス（UX）を得られていない(　)を理解することが重要である。

ユーザーがシステムを使いにくいと感じる理由を理解するには、まず、「ユーザー」という用語が、IT の専門家から子ども、障害を持つ人に至るまで、広い範囲の様々な種類の(　)を表すことを認識する必要がある。

使用性テストでは、ユーザーインターフェースを介して任務をこなすユーザーの(　)のしやすさに影響を与えるソフトウェア欠陥を対象としている。

ユーザーの操作のしやすさに影響を与える欠陥が存在すると、ユーザーは効果的に、効率的に、または満足感を持って意図した(　)に到達できない可能性がある。

使用性の問題は、ユーザー側の混乱、エラー、遅延、またはユーザー側の任務が(　)できないことにつながる。

使用性の副特性である「適切度認識性(理解性)」とは、コンポーネントやシステムが(　)に適切であるかどうかを利用者が認識できる度合いのこと。

使用性の副特性である「習得性」とは、特定のユーザーが特定の状況でコンポーネントやシステムをリスクなく満足して、特定の(　)目標を達成できる度合いのこと。

使用性の副特性である「運用性」とは、コンポーネントやシステムを運用、および(　)しやすくする属性を持っている度合い。

使用性の副特性である「ユーザーエラー防止性」とは、コンポーネントやシステムがユーザーの(　)を防ぐ度合い。

ユーザーエクスペリエンス評価が対象にするのは、直接操作だけでなく、テスト対象のユーザーエクスペリエンス(　)である。

ユーザーエクスペリエンス評価は、テスト対象を使用することで楽しみや満足感を得られるなどの要因が(　)の成功にとって必須である場合などに特に重要である。

ユーザーエクスペリエンスに影響する典型的な要因を次に示す。 ブランド(　)（つまり、製造元に対するユーザーの信頼）

ユーザーエクスペリエンスに影響する典型的な要因を次に示す。 相互に作用する(　)

ユーザーエクスペリエンスに影響する典型的な要因を次に示す。 テスト対象の(　)（ヘルプシステム、サポート、およびトレーニングを含む）

ソフトウェアを使用する際に、特定のニーズまたは(　)を持つユーザーのために、ソフトウェアへのアクセシビリティを考慮することが重要である。これらのユーザーには、障害を持つ人が含まれる。

アクセシビリティテストでは、ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）などの関連する標準、および障害者差別禁止法（北アイルランド、オーストラリア）、2010 年平等法（イングランド、スコットランド、ウェールズ）、第 508 条（米国）などの(　)を考慮する必要がある。

アクセシビリティは、使用性と同じように、(　)活動時に考慮しなければならない。

アクセシビリティテストは、多くの場合、(　)テストレベルで行い始めて、(　)テストおよび(　)テストのテストレベルまで継続する。

アクセシビリティを欠陥として判断するのは、通常、指定した規制またはソフトウェアに対して定義した(　)をソフトウェアが満たさない場合である。

アクセシビリティを向上させるための典型的な手段は、障害を持つユーザーがアプリケーションを操作できるようにするために提供されている機会に焦点を当てる。これらには、次のようなものがある。 (　)認識による入力

アクセシビリティを向上させるための典型的な手段は、障害を持つユーザーがアプリケーションを操作できるようにするために提供されている機会に焦点を当てる。これらには、次のようなものがある。 ユーザーに提示されるテキスト以外のコンテンツに、同等の(　)テキストがあることを保証すること

アクセシビリティを向上させるための典型的な手段は、障害を持つユーザーがアプリケーションを操作できるようにするために提供されている機会に焦点を当てる。これらには、次のようなものがある。 コンテンツや機能を損なうことなく、テキストの(　)を変更可能にすること

アクセシビリティ(　)は、テストで使用できる情報やチェックリストを提供しており、テストアナリストの活動に役立つ

さらに、Web ページで色覚異常者に対するガイドラインに違反する不適切な色の選択などのアクセシビリティの問題を、テスト担当者が識別するのに役立つ(　)やブラウザープラグインも利用できる。

使用性、ユーザーエクスペリエンス、およびアクセシビリティは、以下の手法の 1 つ以上を使用することによってテストできる場合がある。 (　)性テスト

使用性、ユーザーエクスペリエンス、およびアクセシビリティは、以下の手法の 1 つ以上を使用することによってテストできる場合がある。 (　)性レビュー

使用性、ユーザーエクスペリエンス、およびアクセシビリティは、以下の手法の 1 つ以上を使用することによってテストできる場合がある。 使用性の(　)およびアンケート

使用性テストは、ユーザーがシステムを使用して、または使用する方法を習得して、特定の状況で特定の(　)に到達できるという、使いやすさをテストする。

使用性テストでは、次の項目を測定することに注力する。 (　)性 - 利用者が指定された利用の状況で、正確かつ安全に、指定されたゴールを達成できるテスト対象の能力

使用性テストでは、次の項目を測定することに注力する。 (　)性 - 特定の使用条件下で、有効性を達成することに関連し、ユーザーに適切な度合いの資源を使用させるテスト対象の能力

使用性テストでは、次の項目を測定することに注力する。 (　)性 - 指定された利用の状況で、利用者を満足させるテスト対象の能力

使用性テストの設計と仕様化の作業は、テストアナリストが、使用性テストの専門スキルを持つテスト担当者、および人間中心の設計プロセスを理解している使用性設計エンジニアと(　)して行うことが多い点に気を付けることが重要である。

使用性レビューについて、ユーザーの利用度合いを増加させるのに役立つ使用性の観点から実施するテストの種類としては、(　)とレビューが挙げられる。

使用性レビューにおけるインスペクションとレビューは、使用性の問題を SDLC の(　)に要件仕様および設計で見つけることで、費用対効果を高める可能性がある。

使用性レビューのヒューリスティック評価（使用性に関するユーザーインターフェース設計の体系的なインスペクション）は、(　)における使用性の問題を発見するために使用でき、イテレーティブな設計プロセスの一部として取り組むことができる。

使用性レビューのヒューリスティック評価では、少数の評価者によりインターフェースを検証し、認識済みの(　)性原則（「ヒューリスティック」）に適合していることを判断する。

使用性レビュー において、ユーザーインターフェースがより視覚的である場合は、(　)がより有効である。例えば、スクリーンショットのサンプルの方が、特定の画面で提供される機能の説明よりも、通常、理解および解釈しやすい。ドキュメントの使用性を適切にレビューするために視覚化が重要である。

使用性の調査およびアンケートの技法は、システムを操作するときのユーザーの(　)に関する所見やフィードバックを収集するために適用する場合がある。

使用性の調査およびアンケートは、SUMI（ソフトウェア使用性測定一覧表）や WAMMI（Web サイト解析と測定一覧表）など、公開されている標準的な調査方法を使用することにより、過去に行われた使用性測定のデータベースと比較して(　)を実施できる。

使用性の調査およびアンケートにおいて、SUMI は使用性に関する明確な測定値を提供するので、これらの測定値は、一連の完了基準／(　)基準を提供することができる。

(　)性テストは、ソフトウェアコンポーネントまたはシステムを新規インストールとして、もしくは既存環境から意図した環境へ移植できる度合いに関連する。

プロダクト品質特性の分類である ISO 25010 は、移植性に関する次の副特性を定義している。 (　)性 (　)適応性 (　)性

移植性の特性に関してリスクを識別しテストケースを設計するタスクは、(　)とテクニカルテストアナリストが協力して作業する

設置性テストは、対象とする環境にソフトウェアを(　)およびアンインストールするために使用するソフトウェアと、文書化された手順に対して行う。

設置性テストにおいて、テストアナリストが焦点を当てる典型的なテスト目的を以下に示す。 ソフトウェアを様々な構成で正常に(　)できることを確認する。 構成可能なパラメーターが大量に存在する場合、テストアナリストはペアワイズ技法を使用してテストを設計し、 テストするパラメーターの組み合わせの数を削減して、関心のある特定の構成（頻繁に使用する組み合わせなど）に重点を置く。

設置性テストにおいて、テストアナリストが焦点を当てる典型的なテスト目的を以下に示す。 インストールおよびアンインストールの(　)の機能正確性をテストする。

設置性テストにおいて、テストアナリストが焦点を当てる典型的なテスト目的を以下に示す。 インストールまたはアンインストールの手順の後に(　)性テストを実行し、 それらの手順で発生したあらゆる欠陥（正確ではない構成、機能が利用不能など）を検出する。

設置性テストにおいて、テストアナリストが焦点を当てる典型的なテスト目的を以下に示す。 インストールおよびアンインストールの手順における(　)性の問題を識別する （分かりやすい手順説明やフィードバック/エラーメッセージが、手順の実行時にユーザーに提供されることを検証するなど）。

(　)性テストでは、意図したすべての対象となる環境（ハードウェア、ソフトウェア、ミドルウェア、オペレーティングシステム、クラウドなど）で所定のアプリケーションが正しく機能するように、効果的、かつ効率的に適応ができているかどうかを確認する。

環境適応性テストでは、テストアナリストは、意図する対象の環境（様々なモバイルオペレーティングシステムのサポート対象バージョン、使用可能な様々なブラウザーの様々なバージョンなど）を識別し、これらの環境の(　)をカバーするテストを設計することで環境適応性テストをサポートする。

環境適応性テストでテストアナリストは、環境の組み合わせをカバーするテストを設計した後、環境内に存在する様々なコンポーネントを動かす(　)性のテストケースを選択して、対象となる環境をテストする。

(　)性テストは、システム内のソフトウェアのコンポーネントまたはバージョンを他のものに置換できる能力に焦点を当てている。

置換性テストは、様々なハードウェアデバイスそして/またはソフトウェアのインストール環境の置換が頻繁に発生する、モノのインターネット（Internet ofThings（　））に基づくシステムアーキテクチャーに特に関係してくる可能性がある。例えば、倉庫で在庫量を登録および管理するために使用しているハードウェアデバイスを、（改良版のスキャナーを搭載しているなどの）最新のハードウェアデバイスに置き換えることがある。また、在庫交換の注文を供給元のシステムに自動発行する新しいバージョンにインストール済みのソフトウェアをアップグレードすることもある。

置換性テストは、完成システムに統合するための複数の(　)コンポーネントを使用できる場合、機能統合テストと並行してテストアナリストが実行することができる。

テストアナリストは、(　)プロセスに積極的に参加して特有の見解を提供しなければならない。

テストアナリストがレビュープロセスに参加しそれが適切に行われれば、全体的な納品時の(　)に最大限寄与する最も費用対効果の高い手段となることができる。

チェックリストベースドレビューは、テストアナリストがテストベースをレビューする際に最もよく使用する技法である。レビューでチェックリストを使用することにより、参加者はレビュー時に検証する具体的な(　)を認識できる。

チェックリストベースドレビューのチェックリストは、(　)的なレビューを避けるのにも役立つ（例えば、「このチェックリストはすべてのレビューで使用しているものと同じなので、あなたの作業成果物のみを対象としているのではない」と示すことができる）。

チェックリストベースドレビューは、汎用化してすべてのレビューで使用することも、または(　)の品質特性、分野、ドキュメントの種類に焦点を絞ることもできる。例えば、汎用チェックリストは、一意の識別子を持つこと、「未定」と記されている参照がないこと、適切な書式であること、および同様の適合項目であることなど、一般的なドキュメントの特性を検証することがある。

チェックリストベースドレビューの(　)ドキュメント向けの特定のチェックリストは、「必須(shall)」と「推奨(should)」が適切に使われていることの確認、記述されている要件の試験性の確認などを含んでいることがある。

チェックリストベースドレビューにおいて、要件の(　)によっても使用するチェックリストの種類が異なることもある。文章で記述されている要件ドキュメントには、図に基づくドキュメントとは異なるレビュー基準が存在する。

チェックリストベースドレビューにおけるチェックリストは、次のような特定の側面を対象にすることもある。 プログラマー／アーキテクトのスキルセットまたはテスト担当者のスキルセット - テストアナリストの場合、(　)担当者のスキルセットに対するチェックリストが最も適している

チェックリストベースドレビューにおけるチェックリストは、次のような特定の側面を対象にすることもある。 特定の(　)レベル（セーフティクリティカルシステムの場合など） - チェックリストはその(　)レベルで必要な固有の情報を含むことが多い

チェックリストベースドレビューにおけるチェックリストは、次のような特定の側面を対象にすることもある。 特定の(　)アイテム（要件、ユースケース、ユーザーストーリーなど） - コードまたはアーキテクチャーのレビュー向けにテクニカルテストアナリストが使用するものとは、異なる側面に重点を置くことが多い。

チェックリストベースドレビューにおけるチェックリストは、次のような特定の側面を対象にすることもある。 特定のテスト(　) - チェックリストは特定の(　)で必要な情報に重点を置く（デシジョンテーブルで提示される規則など）