受け入れテストとUAT

イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。

潜在的なユーザ、顧客または開発者のサイトではなく、開発組織の外部で独立したテストチームが、シミュレーションや実際のオペレーションにより実行するテスト。市販ソフトウェアでは、内部受け入れテストの一つとして実施することが多い。

間違った結果を生み出す人間の行為。

プログラミング言語の実体。実行の最小単位。

組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。

系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。

テスト活動をプロジェクト中で管理（マネジメント）しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。

実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。

テスト資産を後続のテストで使用できるようにし、テスト環境を十分に満足できる状態に残し、テスト結果を関連するステークホルダに伝える活動。

テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。

テストすべきコンポーネントまたはシステム。

コンポーネントやシステムのテストを実施する熟練した専門家。

テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。

ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。

テスト計画書を策定し、更新すること。

テストケースを適切に生成するために使用する基準、またはテストのサイズを制限するためにテストケースを選択する際に使用する基準。

全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。

1つ以上のテストケースのセット。

個人を特定できる情報または機密情報を保護して、意図せず漏洩しないようにすること。

スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。

コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。

目標を達成するのに役立つ、一般的に認められている経験則。

製品開発環境以外の外部環境で、現在、あるいは、将来のユーザや顧客が実施するテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たし、ビジネスプロセスに適合するかを判定する。マーケットからのフィードバックを得るため、市販ソフトウェアの外部受け入れテストの一形式として用いることが多い。

真または偽として評価することのできる論理的表現。たとえば、A>B。

測定尺度、および、測定手法。

モデルに基づく、またはモデルを活用するテスト。

システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。

ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。

高位のユーザ要件またはビジネス要件。主に、アジャイルソフトウェア開発で用いられる。ユーザが要求する機能とその背景にある理由、およびあらゆる非機能を獲得し、日常言語またはビジネス言語で表現される一つの文で構成する。また、受け入れ基準も含む。

ユーザーのニーズ、要件、およびビジネスプロセスに重点を置いて、実際のまたはシミュレートされた運用環境で、対象となるユーザーが実行する受け入れテスト。

将来、否定的な結果を生む要素。

コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。

ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。

あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。

システムを受け入れる判断に焦点を当てたテストレベル

ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。

テストアイテム(機能)やフィーチャーが、テストに合格したか失敗したかを判定するための判定規則。

品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。

コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。

受け入れテストの種類の1つ。システムが契約上の要件を満たしていることを確認する。

検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。

一般市場の多数の顧客向けに同一の規格で開発されたプロダクトの一種。

ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。

リソースにアクセスすることを可能にする、人、またはプロセスに付与される権限。

入力値や事前条件のセットに対する、コンポーネントやシステムの反応。

客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用

公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)

測定することによって、ある実体の特性に付加した数字や種別。

重要な懸念、問題、または機会を特定する評価の結果。

ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。

テスト担当者の経験・知識・直感をベースに行なうテスト。

受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。

コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。

受け入れテストの種類の1つ。関連する法律、ポリシー、および規制にシステムが準拠していることを確認する。

人またはプロセスが、実際に、それが名乗っている人またはプロセスであることを確認する手順。