テスト見積り方法の一つ。見積り対象案件の「楽観値」、「悲観値」、および「最頻値」の見積りを使用して、結果となる見積りの確実度合を定義する。
アプリケーションのプログラミングインターフェースを直接使用し、テスト対象のソフトウェアにコマンドを発行して行うテスト。
コンポーネントまたはシステムに含まれる、定義された形式の構造で情報を交換するインターフェースの1つ。Application Programming Interface の頭字語。
ISO 26262のアイテムまたは要素の必要要件と、不合理な残余リスクを回避するための安全方策を、4つのレベルで指定する。
自動車業界のプロセス用のプロセス参照モデルおよび関連するプロセスアセスメントモデル。ISO/IEC 33002：2015の要件に準拠する。
テストアイテムの、または同じテストアイテムのシミュレーションモデルの2つ以上のバリアントを比較するテスト。すべてのバリアントに対して同じテストケースを実行し、結果を比較する。
Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
Computer Aided Software Testing（コンピュータ支援ソフトウェアテスト）の頭字語。test automationも参照のこと。
テストスイートが遂行したN+1遷移のシーケンスのパーセンテージ。
専用のコマンドラインインターフェースを使用してテスト対象のソフトウェアにコマンドを発行して行うテスト。
制御アクションまたは入力が、出力または出力の変化に依存するシステム。
組織の品質マネジメントシステムのための規範に縛られない（non-perspective）フレームワークであり、EFQM(ヨーロッパ品質マネジメント財団: European Foundation for Quality Management)によって定義され、所有している。優れた品質マネジメントシステム実現に向けた、五つの実現可能にするための基準（組織がすべきことを網羅）と四つの結果に関する基準（組織が達成すべきことを網羅）がある。JSTQB訳注）http://www.efqm.org/ 参照。
リアルタイムシミュレーションにおいて、コンポーネントまたは他のコンポーネントを含むシステム、車両プロセス、環境条件をシミュレーションするための実環境を抽象化したもの。
電気/電子（E/E）システムの誤動作によって危険な状況が引き起こされるという不合理なリスクが存在しないこと。
GUIを使用してテスト対象のソフトウェアを操作するテスト。
グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。
統合されたソフトウェアと実際のハードウェアを使用して、シミュレーションされた環境で実施する動的テスト。
開始、計画、および改善のアクションを実装するためのロードマップとして機能する組織的な改善モデル。IDEALモデルは、開始、診断、確立、行動、および学習の五つのフェーズにちなんで名付けられた。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
自動車用安全度水準（ASIL）およびテスト対象の状況に応じて必要とされるさまざまなテストアプローチ、テスト技法、およびテストタイプを記載するテーブル。
システムのシミュレーションモデルを使用して、シミュレーション環境で実施する動的テスト。
テストスイートが遂行したN+1遷移のシーケンスのパーセンテージ。
制御アクションまたは入力が、出力または出力の変化に依存しないシステム。
リスクベースドテストの体系的なアプローチ。プロダクトリスクの識別と分析を行ない、発生可能性および影響に基づくプロダクトリスクマトリクスを作成する。この用語はProduct RISk MAnagement（プロダクトリスクマネジメント）の略語である。
目標を、汎用的ではなく、非常に具体的に定義する方法論。SMARTは、定義される目標の属性を表すSpecific（具体的な）、Measurable（測定可能な）、Attainable（達成可能な）、Relevant（妥当な）、およびTimely （タイムリーな）からの頭字語である。
シミュレーションされた環境で、または実験的なハードウェアと統合して、実際のソフトウェアを使用して実施する動的テスト。
完成済みの統合されたソフトウェアで実施するテスト。ソフトウェア要件に準拠していることの証拠を提供する。
セキュリティ攻撃方法の一つ。悪意のあるSQLステートメントを入力フィールドに挿入して実行する。
ソフトウェアコンポーネント、ハードウェアコンポーネント、およびメカニクスから成る完成済みの統合されたシステムで実施するテスト。システム要件に準拠しており、完成済みシステムをデリバリーする準備が整っていることの証拠を提供する。
テストプロセスを改善するための、継続するビジネス駆動のフレームワーク。効果的で効率的なテストプロセスの主要な要素を定義する。
要求仕様から保守までのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。
さまざまな仮想テスト環境の動的テストに対する総称。
プロジェクトとは異なる場所で、従業員ではない人々により実行されるテスト。
セキュリティ攻撃に使用することを目的として、ユーザアカウント情報をトライ＆エラーで繰り返し試みて取得するプロセス。
身体的な制約を持つ人を含むユーザが、どの程度容易にコンポーネントやシステムを利用できるか判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。
特定の方法でテスト対象とやりとりするユーザーまたは他の人、あるいはシステム。
イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。
エクストリームプログラミング（XP）のような技法や手法が取り込まれているアジャイルソフトウェア開発方法論を用いたり、開発をテストの一部とみなしたり、テストファースト設計パラダイムを重視するプロジェクトで実施するテスト。
アジャイルソフトウェア開発を支援する価値に関する宣言。ここでいう価値とは、以下のようなものである。・プロセスやツールよりも個人との対話を重視する・網羅的なドキュメントよりも動作するソフトウェアを重視する・契約交渉よりも顧客との協調を重視する・計画に従うことよりも変化に対応することを重視する
アセスメント結果、たとえば結論、提案、所見などをまとめたドキュメント。
アセスメントを実行する人。アセスメントチームのメンバー。
任意のレビューアが非公式に、体系的なプロセスを使用することなく行うレビュー技法。
潜在的なユーザ、顧客または開発者のサイトではなく、開発組織の外部で独立したテストチームが、シミュレーションや実際のオペレーションにより実行するテスト。市販ソフトウェアでは、内部受け入れテストの一つとして実施することが多い。
最初は有益で一般的に使用できるように思われるが、実際には効果がない、または逆効果である反復的な活動、プロセス、構造、または再利用可能なソリューション。
マルウェアを検出し阻止するソフトウェア。malwareも参照のこと。
プロジェクトをいくつかの（通常は、多数の）反復部分に分割して開発するライフサイクルの一種。一つの反復部分は、実行可能なプロダクトを（内部、あるいは、外部へ）リリースするという結果をもたらす、完全な開発ループである。
開発ライフサイクルの一つ。プロジェクトで開発する要件全体を部分的な機能に分割し、サブプロジェクトにおいて、部分機能を積み上げながら連続して開発する方式。各要件に優先順位を付け、優先度の高い順に適切な大きさの機能をリリースする。このライフサイクルモデルには、各サブプロジェクトが、設計、コーディング、テストというミニV字モデルで進むものもある。
セキュリティ脅威の一つ。多くの場合、組織内の認可されているシステムユーザが実行する。
インシデントの記録や、状態追跡を支援するツール。ワークフロー志向の機能を持っていることが多く、インシデントの場所特定、修正、再テストをトレース・コントロールしたり、レポートを出力したりすることができる。
インシデントを認識、調査、対策、解明するプロセス。インシデントの記録、分類、影響度の識別が必要。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
インストールプロセス中、インストールを誘導するソフトウェア。いろいろな形態の媒体で提供される。インストールを実行し、インストール実施結果情報を出力し、オプション機能のガイダンスを表示するものが多い。
インストールプロセス中、インストールをガイドする説明書で最適の媒体で提供される。マニュアルガイド、段階的な処理手順、インストールウィザード、その他類似の手順記述などの形式をとる。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
同じ組織ではない人が、プロジェクトチームと同じ場所で行なうテスト。
統合テストの一種。コンポーネントやシステムのインターフェーステストを実施する。
コンポーネントやシステムが拒否する入力値を使うテスト。
一連のウェブアクセシビリティガイドラインの一部分。インターネットに関する主要な標準組織であるWorld Wide Web Consortium（W3C）のWeb Accessibility Initiative（WAI）が発行している。特に身体的な制約を持つ人がコンテンツを利用できるようにするための一連のガイドラインを含む。
ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。
アジャイルソフトウェア開発の中で使用されるソフトウェアエンジニアリング方法論。中心となるプラクティスは、ペアプログラミング、徹底したコードレビュー、全てのコードの単体テスト、単純明快なコードなどである。
大きなユーザーストーリーのひとつ。1回のイテレーションではデリバリーできない、または更に小さなユーザーストーリーに分割できる程度の大きさのもの。
ある特定のシステムと同じ入力を受け入れ、同じ出力を作り出す装置、コンピュータプログラム、またはシステム。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
テスト設計技法の一つ。テスト担当者の経験を駆使し、エラーが起きた場合にどのような欠陥がテスト対象のコンポーネントやシステムの中に存在するかを予想して、その欠陥を検出するテストケースを設計すること。
誤ったデータを入力しても、通常運用を続けられるコンポーネントやシステムの能力。
（モデルから）生成したテストケースを以降のテスト実行のために保存するモデルベースドテストのアプローチ。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
（モデルから）生成したテストケースを生成と同時に実行するモデルベースドテストのアプローチ。
（モデルから）生成したテストケースを生成と同時に実行するモデルベースドテストのアプローチ。
ソフトウェアツールの一つの種類。全ての潜在的なユーザに、通常はインターネットを介して、ソースコードの形式で提供される。一般的に、ユーザはライセンスの下で許可が与えられ、調査、変更、機能強化、場合によってはソフトウェア配布を行なうために使用する。
特定ユーザや特定顧客専用に開発したソフトウェア。反対語はoff-the-shelf software（既製ソフトウェア）。
特定のユーザまたは顧客へ特別に開発されたソフトウェアツール。
テストカバレッジの基礎となる実体や属性。たとえば、同値分割やステートメント。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
ブラックボックステスト技法のひとつ。クラシフィケーションツリーを使用してテストケースを設計する。
ブラックボックステスト設計技法の一つ。クラシフィケーションツリーを使って入力ドメインや出力ドメインの代表値の組み合わせを設計し、テストケースを記述する。
階層的な順番で同値分割を示したツリーであり、クラシフィケーションツリー法でテストケースを作成するときに使う。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
12の重要なプロセスから構成されるテストプロセス改善のためのコンテンツベースドモデル。企業の利益や評価に影響を与えるようなミッションクリティカルなプロセスやコンピタンスの状況を同僚や経営陣が判断できるよう高度に可視化したプロセスを含む。
脆弱性の一つ。悪意のあるコードを安全なWebサイトへ感染させるために攻撃者が悪用することを可能にする。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
テスト戦略の一つ。テストチームは一人以上の主要なステークホルダからの意見を戦略の詳細に反映する。
優れたエンジニアリングプラクティス(たとえば、テストプラクティス)に関する詳細な説明を提供するプロセスモデル。
優れたエンジニアリングプラクティス(たとえば、テストプラクティス)に関する詳細な説明を提供するプロセスモデル。
高度な命令語で表現されたプログラムを、等価の機械語に翻訳するソフトウェアツール。
セキュリティ攻撃の成功度合を判定し、発生した被害を評価する作業。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
テストスイートが、ソフトウェアのどの部分を実行（網羅）し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
企業業績の状況に関するダッシュボードスタイルの表現。
プログラムにおけるサブルーチン間の呼び出し関係の抽象的表現。
三つのレベル、すなわち、概念的なレベル（ゴール）、運用上のレベル（クエスチョン）、定量的なレベル（メトリック）のモデルを用いたソフトウェア測定のアプローチ。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
物理的な接続がなく、デプロイやアクセス、マネジメントされるサービスの仮想的なデリバリーを可能にする技術。
セキュリティ攻撃方法の一つ。サービスできない正当なリクエストなどを大量に送りつけてシステムを過負荷状態にする。
相互接続したドメインと複数レベルのネットワークに組み込まれた複数の分散システムや異機種環境のこと。通常、共通的な管理構造を持たずに、広範囲に専門領域間をまたがる共通の問題や目的に対処する。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
セキュリティポリシーおよび異なる複数のレイヤーを適用して、システムのセキュリティの脆弱性を削減する段階的なプロセス。
単純な10項目の質問から得られる態度尺度。使用性に関わる主観的な評価をまとめた全体的な意見を提供する。
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース（たとえば、電子データ交換やインターネット）をテストすること。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
ブラックボックステスト設計技法の一つ。ユースケースのシナリオを実行するテストケースを設計する。
レビュー技法の1つ。レビューでは、作業成果物がシナリオに対処できるかどうかを判定する。
物理的なシステム、あるいは、抽象的なシステムの代表的な動作特性を他のシステムで模倣すること。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
統計に基づくプロセス管理ツール。プロセスを監視し、統計的に管理されているかどうかを確認する。プロセスの平均値と、上方管理限界および下方管理限界（最大値および最小値）を図示する。
開発ライフサイクルモデルの種類の1つ。いくつかの独立および連続するフェーズを順番に実行してシステムを完成させる。各フェーズ間に重複は存在しない。
アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。
自身ではなく他のハッカーが作成したセキュリティ攻撃を実行する人。
すでに記述されているテスト順序通りに実行するテスト方法。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
テストスイートによって遂行されたステートメントのパーセンテージ。
ホワイトボックステスト設計技法の一つ。ステートメントを実行するテストケースを設計する。
予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
セキュリティ攻撃を成功させる可能性があるシステムの弱点。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
セキュリティポリシーを実装するために必要な手順と、セキュリティインシデントに対処する際に実行する手順のセット。
システムまたはコンポーネント、リソース、情報への不正なアクセスを成功させようとする試み。またはシステムの完全性を侵害しようとする試み。
組織にとってのセキュリティに関わるプロセスとインフラストラクチャを評価する監査。
許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
セッションベースドテストの測定と管理の手法。たとえば、探索的テスト。
テスト活動をテストセッションとして計画するアプローチ
故障や誤動作が人命や人々への深刻な損害、若しくは機器へのダメージや環境被害となる可能性のあるシステム。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
組織のソフトウェアプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。
ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに廃棄フェーズを含むこともある。注）これらのフェーズは重複することもあるし、反復することもある。
フォールト（欠陥）の原因分析で使用する方法。特定の顕在化したフォールトと結びつく、故障やヒューマンエラーおよび外部イベントの関係を論理的に視覚化したモデルにする技法。
リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。
ステークホルダが選択したソフトウェアやソフトウェアベースのシステム特性にソフトウェアが準拠する、または準拠する必要のある度合。一連のシステム特性は、たとえば、ソフトウェアの複雑性、リスクアセスメント、安全レベル、セキュリティレベル、期待される性能、信頼性、またはコストで構成され、ステークホルダにとってのソフトウェアの重要度を反映するように定義される。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
暗号化技法の一つ。ユーザデータに任意のデータ（ソルト）を追加してから、ハッシュ処理を行う。
システムまたはネットワークを攻撃するために使用できる情報（パスワードなど）を詐取する試み。
組織や活動の業務成績の動的な測定結果を、メタファによって表されたメトリクスを用いて表現したもの。ここでいうメタファとは、自動車のダッシュボードに似せた、目にみえるダイヤルやカウンターなどである。これによって、出来事や活動の結果が容易に把握でき、業務上の目標と関連付けることができる。
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
経験ベースのテスト設計技法であり、経験を積んだテスト担当者が、気づき、チェックし、あるいは記憶すべき項目の高位レベルのリストやルール集、検証すべき基準を使用して実施する。
質問または確認項目のリストを使用して行うレビュー技法。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。
どのような技術的アプローチをとるかで意見を一致させることを目的とした、ピアグループによるディスカッション。
責任を分離すること。これにより、客観的なテストを促進できる。
テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
（1）テスト組織に対して、テスト組織と他の分野との関連について、ガイダンスと戦略的指針を提供する人。（2）特定のシステム用にテストを構造化する方法を定義する人。テストツールやテストデータのマネジメントなどのトピックも定義する。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
特定のテスト設計技法を使用している際に、テストベースのサイズが大きくなるにつれて、テストケースの数が過度に増加すること。テストケースの爆発的増加は、テスト設計技法を初めて体系的に適用した際に発生することもある。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
一つ以上のテストケースをセットにしたドキュメント。
テストアイテム用のテストケースのセット（目的、入力値、テスト実行、期待結果、実行事前条件）を規定するドキュメント。
テストケースを作成したり選択したりするための技法。
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
監視中に計画から逸脱していることを検出した場合に、テストプロジェクトを軌道修正するための対策を考えたり適用したりするテストマネジメントタスクの1つ。
識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。
テスト活動と結果を要約したドキュメント。テストアイテムがテスト終了基準を満足しているかどうかの評価も含む。
テストアイテムの終了基準に対応する評価を提供するテストレポート。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。
活動、タスク、またはテストプロセスのイベントに関して、開始/終了日、時間、依存関係を識別できるリスト。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
テスト対象のコンポーネントまたはシステムのためのいくつかのテストケースのセット。一つのテストの事後条件は、次のテストの事前条件としてよく利用される。
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。
セッションベースの探索的テストにおけるテスト活動のドキュメント。
テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
テストマネージャをマネジメントする上級マネージャ。
テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。
テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
テスト実行に必要なスタブやドライバからなるテスト環境。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
テスト活動をプロジェクト中で管理（マネジメント）しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。
カスタマイズしたソフトウェアインターフェース。テスト対象のテスト自動化を可能にする。
（テスト）専門家の集団。組織が使用するテストプロセスの定義、改善や保守を促進する。
アジャイルマニフェストにより表明された声明で、テストプロセスを改善するための価値を定義している。ここでいう価値とは以下のようなものである。・プロセスの詳細化よりも柔軟性、・テンプレート(ひな形)よりもベストプラクティス、・プロセス志向よりも展開志向、・品質保証(部門)よりもピアレビュー、・モデル駆動よりもビジネス駆動。
テスト改善計画に基づきテストプロセス改善を実行する人。
組織のテストプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。
ファンクションポイント分析に基づき、数式でテストの必要リソースを見積る手法。
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テスト対象のコンポーネントまたはシステムをテストするために使用するテストウェアを規定するモデル。
テストプロジェクトの状態の周期的なチェックに関連した活動を扱うテスト管理タスク。実際の活動と計画した活動とを比較した報告が準備される。
テスト対象の特定のバージョンでテストを実行すること。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
大規模なプロジェクトで、テストマネージャに報告を行い、特定のテストレベルやテスト活動に責任を持つ個人。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テスト活動と結果を要約したドキュメント。テストアイテムがテスト終了基準を満足しているかどうかの評価も含む。
定期的に作成するテストの活動と結果をまとめたドキュメント。テスト活動の進捗がベースライン（当初のテスト計画など）に沿っているかどうか報告するため、かつリスクや決定が必要な代替案をマネジメント層へ伝えるために作成する。
テストケースを作成したり選択したりするための技法。
テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。
組織にとってのテストの目的で、多くの場合、テストポリシーの一部として文書化される。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
テストベースとテスト目的の定義を分析するプロセス。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
テスト資産を後続のテストで使用できるようにし、テスト環境を十分に満足できる状態に残し、テスト結果を関連するステークホルダに伝える活動。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テンプレートまたはガイドラインを提供してテストスイートまたはテストケースの定義作業を支援し、テスト実装を行いやすくする。
テスト手順を実行していくための計画。注）テスト実行スケジュールには、実際に実行するテスト手順書の内容とその実行順を記述する。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テストスイートまたはテストケースの実行をサポートする。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。
テスト対象となるシステムのことであり、テスト対象の一種。
能力成熟度モデル統合（CMMI）と関連させた５段階からなるテストプロセス改善のためのフレームワークであり、効果的なテストプロセスのための重要要素を記述している。
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
テストケースを作成したり選択したりするための技法。
コンポーネントやシステムのテストを実施する熟練した専門家。
組織のテストプロセスとテストプロセスの資産について、長所と短所を徹底的に理解し、組織的にテストプロセス改善を達成することをベースとした計画。
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テスト実行時の実行結果と期待結果との比較を自動的に実施するテストツール。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テストスイートまたはテストケースの手動設計または自動設計をサポートする。
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
汎用テスト自動化アーキテクチャをインスタンス化したもの。テスト自動化ソリューションのアーキテクチャ（レイヤー、コンポーネント、サービス、およびインターフェース）を定義する。
テスト自動化アーキテクチャの設計、実装、および保守を担当する人。作成したテスト自動化ソリューションを技術的に進化させる役割も担う。
テスト自動化アーキテクチャを具現化または実装したもの。特定のテスト自動化要素を実装するコンポーネントの組み合わせで構成される。それらのコンポーネントには、市販のテストツール、テスト自動化フレームワーク、テストハードウェアなどが含まれることがある。
テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。
テスト自動化ソリューションの開発と進化を計画および監督する役割を担う人。
特定の境界条件の下で、テスト自動化の長期目標を達成するための高位レベルの計画。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストのさまざまな局面に紐付けられた概算結果(たとえば、工数, 完了日,コスト, テストケース数, など)。ただし、入力情報が不完全、または不確か、若しくは余計な情報を含んでいても実施できる。
達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
テスト入力を生成することでテスト設計を支援するツール。テスト入力の生成は、CASEツールのリポジトリ(たとえば要件マネジメントツール)に格納している仕様、ツールの中に保存してある特定のテスト条件、またはコードから行なわれる。
テストすべきフィーチャーとそれらに対応するテスト条件を明確にしたドキュメント。
テストアイテムのテスト条件（カバレッジアイテム）、詳細なテストアプローチ、および、関連する高位レベルテストケースを記述したドキュメント。
テストケースを作成したり選択したりするための技法。
概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。
定期的に作成するテストの活動と結果をまとめたドキュメント。テスト活動の進捗がベースライン（当初のテスト計画など）に沿っているかどうか報告するため、かつリスクや決定が必要な代替案をマネジメント層へ伝えるために作成する。
テスト自動化アーキテクチャのレイヤー。抽象レベルのテストスクリプトをSUTのさまざまなコンポーネント、構成、またはインターフェースに適合させるために必要なコードを提供する。
テストケースを適切に生成するために使用する基準、またはテストのサイズを制限するためにテストケースを選択する際に使用する基準。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
システム全体を毎日（多くの場合、夜間）、コンパイル、リンクして作成する開発の活動。これにより、最新の変更を反映した一貫性のあるシステム、アプリケーションにいつでもアクセスできるようになる。
テストスイートによって遂行された、判定結果のパーセンテージ。100%のデシジョンカバレッジは、100%のbranch coverage（ブランチカバレッジ）と100%のstatement coverage（ステートメントカバレッジ）の両方を意味する。
ホワイトボックステスト設計技法の一つ。判定を実行するテストケースを設計する。
ブラックボックステスト設計技法の一つ。デシジョンテーブルにある入力と刺激（原因）の組み合わせを実行するテストケースを設計する。
入力と刺激（原因）、および、対応する出力と処理（結果）の組み合わせを示す表。テストケースの設計に利用できる。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。
反復的な四つのステップからなる問題解決のプロセス（計画-実施-評価-改善）。特にプロセス改善において用いられる。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
ホワイトボックステスト設計技法の一つ。変数の「定義と使用」の組を実行するようにテストケースを設計する。
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。
個人を特定できる情報または機密情報を保護して、意図せず漏洩しないようにすること。
データ変換法の一つ。元のデータを判読できないようにする。
スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。
2つのエンティティ（たとえば、要件とテストケース）を関係付ける2次元の表。この表を使用すると、エンティティ間の関係を前工程および後工程の双方向に追跡できるので、達成したカバレッジを測定でき、変更点の影響を評価できる。
ドキュメントとソフトウェアの関連事項（たとえば、ある要件と、それを検証するテストケース）を識別する能力。
ブラックボックステスト設計技法の一つ。複数の変数を同時にテストできる、またはテストする必要がある場合に効率的かつ効果的なテストケースを識別するのに使用される。同値分割法と境界値分析に基づいて構築され、これらを汎用化する。
別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、一時的なコンポーネントまたはツール。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
信頼のレベルが定義されているサブネットワーク。たとえば、インターネットゾーンおよびパブリックゾーンは信頼できるとはみなされない。
Webサイト上に切断されたハイパーリンクが存在しないことを確認するために使用されるツール。
ウェブページで、他のウェブページへ導くためのポインタ。
抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
リスクの要素を特徴付けるために使う技法。ハザード分析の結果はシステム開発やテストのために使う手法を牽引する。
通常は悪意を持って、セキュリティ攻撃に関与する人または組織。
可変長の文字列を、通常、より短い固定長の値またはキーに変換するプロセス。テーブルまたはデータベースを照会する際は、一般的には、ハッシュ化された値またはハッシュを使用する。また、暗号化ハッシュ関数を使用して、データをセキュリティで保護する。
ハードウェアコンポーネントとソフトウェアコンポーネントとの間のインターフェースおよび相互作用に存在する欠陥を検出するために実行されるテスト。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
企業の営業活動がその目的と整合しているかどうかをビジネスの構想や戦略の観点から評価するための戦略的ツール。
品質に対する考え方の一つ。品質は価格で定義することができる。プロダクトやサービスの品質は、許容できるコスト範囲内で望まれるパフォーマンスを提供するものである、というもの。この品質はステークホルダ間で、期間、労力とコストのトレードオフに基づく意思決定プロセスによって決められる。
一つのイテレーションにおける残作業と時間の関係を表すために公開されるチャート。このチャートは、イテレーションにおけるタスクの完了状況と傾向を示す。一般的に、X軸はスプリントにおける日数を表し、Y軸は残作業の量（通常、理想的なエンジニアリングの時間またはストーリーポイントのどちらか）を表す。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
セキュリティ攻撃方法の一つ。コンピュータシステムに格納されている、またはネットワーク経由で転送されている秘密のパスワードを復元する。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
意思決定における統計的手法の一つで、全体的影響を与える特定の重要な要因を選択するために使用される。品質改善の面では、問題の大半（80％）は少数の主要な原因（20％）によって発生する。
レビュー技法の種類の1つ。レビューアはさまざまな視点から成果物を評価する。
ブラックボックステスト設計技法の一つ。同値分割した領域から代表値を実行するテストケースを設計する。原則として、最低1回各同値分割した領域を実行するように設計する。
目標を達成するのに役立つ、一般的に認められている経験則。
新たに作成した各ビルドに対して、完全性を確認し、主要な機能性、安定性、および試験性を検証する自動化テストのセット。ビルドが頻繁にリリースされる場合（たとえば、アジャイルプロジェクト）に、業界で一般的に行なわれるテストである。新たに作成したビルドは、このテストの完了後に、次のテストに向けてリリースされる。
欠陥を識別して修正するため、プロダクト開発を担当している同僚がソフトウェア成果物をレビューすること。たとえばインスペクション、テクニカルレビュー、ウォークスルー。
事前に定義されたセキュリティ規則に基づいてネットワークの送受信トラフィックを制御する単独または一連のコンポーネント。
ソフトウェアテスト技法の一つ。セキュリティの脆弱性を見つけるために、ファズと呼ばれる大量のランダムデータをコンポーネントまたはシステムに入力する。
ソフトウェアテスト技法の一つ。セキュリティの脆弱性を見つけるために、ファズと呼ばれる大量のランダムデータをコンポーネントまたはシステムに入力する。
情報システムの機能規模を測定する手法。ＦＰＡでの測定は、対象技術に依存しない。生産性測定、必要リソースの見積り、プロジェクトコントロールのベースとして利用できる。
セキュリティ攻撃方法の一つ。ユーザに気付かれることなく、また同意を得ることなく、Webサイトのトラフィックを不正なWebサイトに転送する。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
電子通信において信頼されるエンティティになりすまして、個人情報または機密情報を取得する試み。
クライアントにとっての機能性価値(フィーチャー)の観点で駆動される、イテレーティブかつインクリメンタルなソフトウェア開発プロセス。フィーチャー駆動開発は、ほとんどの場合、アジャイルソフトウェア開発で使用する。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
製品開発環境以外の外部環境で、現在、あるいは、将来のユーザや顧客が実施するテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たし、ビジネスプロセスに適合するかを判定する。マーケットからのフィードバックを得るため、市販ソフトウェアの外部受け入れテストの一形式として用いることが多い。
管理されている環境で、故障モードをシミュレーションするか、実際に故障を発生させて行なうテスト。故障の後、フェイルオーバー機能をテストし、データの損失および破損が発生しておらず、合意されている全てのサービスレベル（機能の可用性、応答時間など）を維持していることを確認する。
ソフトウェアライフサイクルの同一フェーズ内における、混入した欠陥数に対する除去された欠陥数のパーセンテージ。
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とする。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
フォールト（欠陥）の原因分析で使用する方法。特定の顕在化したフォールトと結びつく、故障やヒューマンエラーおよび外部イベントの関係を論理的に視覚化したモデルにする技法。
コンポーネントまたはシステムの中で識別された欠陥の数をコンポーネントまたはシステムのサイズで割った値（サイズを表す標準的な尺度には、コード行数、クラス数、またはファンクションポイント数がある）。
特定の品質特性を評価するために、直接的に焦点を定めて行なう試み。特定の故障が発生するような強制を試みることによって、通常、テスト対象の信頼性またはセキュリティを評価する。
あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
攻撃に役立つ可能性のある情報を取得することを目的として、ターゲット領域を探索すること。
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。
テストスイートによって遂行された分岐のパーセンテージ。100%のブランチカバレッジは100%のデシジョンカバレッジと100%のステートメントカバレッジの両方を意味する。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
ホワイトボックステスト設計技法の一つ。分岐を実行するためのテストケースを設計する。
合意に基づく見積り技法の一つ。アジャイルソフトウェア開発で、ユーザストーリーの作業量または相対規模を見積るのに使用される。ワイドバンドデルファイ方法の一つの種類で、チームが見積る単位を表す一組のカードを使用する。
次のプロジェクトまたは次のプロジェクトフェーズを改善するために、教訓を学び、具体的なアクションプランを作成する構造化された方法。
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
参照モデルを用いた、組織におけるソフトウェアプロセスの統制度合の評価。
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。
プロセスモデルの一つ。ベストプラクティスの汎用的に使用できる部分と、事前に定義された手順を順に実行してプロセスを改善する方法とを提供する。
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
テスト戦略の一つ。テストチームは一連の事前定義されたプロセスに従う。これらのプロセスでは、ドキュメント、テストベースおよびテストオラクルの適切な特定と使用、およびテストチームの組織などの項目に言及する。
スクリプト作成技法の一つ。テスト対象ソフトウェアのユースケースを表すシナリオとなるように、スクリプトを構造化する。テストデータを使用してスクリプトをパラメータ化できる。
相互関係のある活動のセット。入力を出力に変換する。
品質に対する考え方の一つ。品質は明確に定義された品質の属性のセットに基づく、というもの。これらの属性は、客観的かつ定量的な方法で測定する必要がある。同じ種類のプロダクト品質の違いは、特定の品質の属性を実装した方法に由来する。
性能テストツールやモニタなどでコンポーネントやシステムを測定する場合、測定ツールによって埋め込まれる測定のためのコード（インスツルメント）がコンポーネントやシステムに及ぼす影響。たとえば、性能テストツールを使うことによって、性能は若干悪化する。
与えられた状況下で、組織の作業効率に寄与する優れた手法や革新的な実践法。他の同等な組織から、「最善」と認められることが多い。
製品開発環境以外の外部環境で、現在、あるいは、将来のユーザや顧客が実施するテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たし、ビジネスプロセスに適合するかを判定する。マーケットからのフィードバックを得るため、市販ソフトウェアの外部受け入れテストの一形式として用いることが多い。
ふたり（たとえば、テスト担当者２名、開発担当者とテスト担当者が１名ずつ、エンドユーザとテスト担当者が１名ずつ）が、共同で欠陥を見つけること。テスト期間中、ふたりで１台のコンピュータを共有し、交互に使用することが多い。
ソフトウェア開発のアプローチの一つ。１台のコンピュータを共有するふたりのプログラマが、（製品用、テスト用の）コードを書く。これにより、コードレビューをリアルタイムに実施できることを期待している。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
ボットまたはロボットと呼ばれる侵害されたコンピュータのネットワーク。第三者によって制御され、マルウェアまたはスパムを送信するため、または攻撃を実行するために使用される。
他のデータアイテムのロケーションを指定するデータアイテム。たとえば、処理される次の従業員レコードアドレスを指定したデータアイテム。
人々のさまざまな性格およびコミュニケーションスタイルを表す、個人の心理学的な傾向の指標。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
中心となるキーワードやアイデアの周囲に、用語、アイデア、タスク、または他の項目を表現し、関連付け、配置するために使われる図。マインドマップは、アイデアを作り出し、視覚化し、構造化し、分類するために記述する。学習、組織化、問題解決、意思決定、文書作成の補助として活用される。
品質に対する考え方の一つ。品質はプロダクトまたはサービスが、その意図した設計と要件に準拠する度合によって測定される、というもの。品質は、使用されるプロセス（群）に依存する。
ソフトウェアの取得、供給、開発、運用、保守、といったプロセスを体系的に評価すること。管理者や管理者の代理者が、進捗を監視し、計画やスケジュールの状態を判定し、要件やシステム割り当てを確認し、目的遂行用に最適化されるようマネジメントアプローチの効率を評価する。
インターフェースで受信した悪意のあるコードを検出および除去することを目的とする静的解析。
システムまたはそのコンポーネントに危害を与えることを目的とするソフトウェア。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
ソフトウェアやシステムのモデルの作成、修正および妥当性確認を支援するツール。
テストスイートがモデル要素の遂行を計画したか、またはモデル要素をすでに遂行した度合。パーセンテージで表す。
テスト戦略の一つ。テストチームはテストウェアをモデルから生成する。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
テスト時に、コンポーネントやシステムと同時に実行し、コンポーネントやシステムの振る舞いを監視、記録、分析するソフトウェアツールやハードウェア装置。
適切なスタブやドライバを併用した状態、または独立した状態でコンポーネントをテストできるユニットテストまたはコンポーネントテスト用の環境を提供するツール。デバッグ機能など、開発者を支援するその他の機能もある。
使用性評価技法の一つ。ユーザの代表標本に、コンポーネントまたはシステムを使用した体験に基づいて、主観的評価を質問表にレポートするように依頼する。
ユーザインターフェースの設計に関わる低位レベルの固有のルールまたは推奨事項。異なる解釈が発生する余地はほとんどなく、設計者が異なっても同じ実装になる。組織がシステムを構築する際に、ユーザインターフェースの外観と振る舞いに一貫性を持たせるために頻繁に使用する。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
ブラックボックステスト設計技法の一つ。ユースケースのシナリオを実行するテストケースを設計する。
ブラックボックステスト設計技法の一つ。ユーザストーリーが正しく実装されていることを検証するために、テストケースをユーザストーリーに基づいて設計する。
高位のユーザ要件またはビジネス要件。主に、アジャイルソフトウェア開発で用いられる。ユーザが要求する機能とその背景にある理由、およびあらゆる非機能を獲得し、日常言語またはビジネス言語で表現される一つの文で構成する。また、受け入れ基準も含む。
品質に対する考え方の一つ。ユーザの必要性、要望、願望を、どこまで満たすか、というもの。要求を満たしていないプロダクトやサービスは、いかなるユーザの支持も得ることができない。この(ユーザベースド)品質は、背景によって異なる流動的なアプローチである。なぜならば、プロダクトごとに異なる品質の側面によりビジネスに求められる特徴が変わってくるためである。
ブラックボックステスト設計技法の一つ。ユーザーストーリーの実装の正しさを検証するために、ユーザーストーリーに基づいてテストケースを設計する。
日常言語またはビジネス言語で表現された、1つの文で構成されるユーザー要件またはビジネス要件。ユーザーが必要とする機能、その背後にある理由、何らかの非機能、および受け入れ基準を含む。
ユーザーのニーズ、要件、およびビジネスプロセスに重点を置いて、実際のまたはシミュレートされた運用環境で、対象となるユーザーが実行する受け入れテスト。
ユーザの要件とニーズに重点を置いて、（シミュレートされた）運用環境で、使用することが予定されているユーザが実行する受け入れテスト。
ブラックボックステスト設計技法の一つ。ユースケースのシナリオを実行するテストケースを設計する。
アクターとコンポーネントまたはシステムとの間の対話における一連のトランザクション。視覚できる結果を伴う。アクターは、ユーザまたはシステムと情報交換するあらゆるものになりうる。
プロダクトまたはプロジェクトの全期間をフェーズに分割したもの。
独自の適応性を持つ反復ソフトウェア開発プロセスフレームワーク。方向付け、推敲、作成、および移行の四つのプロジェクトライフサイクルフェーズで構成される。
ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能属性のテストに利用できる。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのコンポーネントやシステムに対して実行するテスト。
変更により引き起こされた、コンポーネントやシステムの品質の悪化。
リスクが実際の結果または事象となった場合に引き起こされる損害。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、またはリスクの潜在する影響)で分類されたリスクのセット。特定のプロダクトリスクのタイプはそれを軽減(コントロール)できるテストタイプと関連付けられる。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、またはリスクの潜在する影響)で分類されたリスクのセット。特定のプロダクトリスクのタイプはそれを軽減(コントロール)できるテストタイプと関連付けられる。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを評価するプロセス。一般的に、それらのリスクの影響度と発生確率（可能性）を見積ることによって行なう。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
アセスメントを主導する人。CMMiやTMMiなどの公式なアセスメントを行なう場合は、リードアセッサーは、公式な訓練を受けて認定を受ける必要がある。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
レビュープロセスを支援するツール。レビューの計画、追跡の支援、コミュニケーションのサポート、協調的なレビューの推進、収集や報告用のメトリクスを保存する機能を備えていることが多い。
意図するレビュー活動のアプローチ、リソース、およびスケジュールを記述するドキュメント。特に、レビュー対象のドキュメントとコード、使用するレビューの種類、参加者、公式レビューの場合に適用される開始と終了の基準、それらを選択した理由などが識別される。レビュー計画プロセスの記録である。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
ソフトウェア製品の頑健性（堅牢性）を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
コンポーネントやシステムの振る舞いを測定する性能テストの一種。負荷（たとえば、同時実行ユーザ数やトランザクションの数）を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるか判定する。
テストされるコンポーネントやシステムが稼動中にユーザが行なうであろう活動内容を記した仕様書。ロードプロファイルは、特定の時間内に所定の運用プロファイルに準じ決められたトランザクションを処理する仮想ユーザを複数指定して構成する。
レビュー技法の1つ。レビューアは個々のステークホルダの役割の観点から成果物を評価する。
具体的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
専門家によるテスト見積り技法。チームメンバーから集めた知識を用い、正確な見積りをするもの。
範囲外、若しくは、存在しない位置を参照しているポインタ。
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。
ユーザに気づかれることなく、第三者により、通信（たとえば、クレジットカード決済情報）の傍受、模倣、改ざん、転送が行なわれる攻撃。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
特定のテストやテスト手順でコンポーネントやシステムを実行する前に満足すべき、環境と状態の条件。
テストやテスト手順の実行後に満足すべき、環境と状態の条件。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
人と人の心の内の交流分析。交流は刺激とその反応により定義される。交流は、人と人の間と、人の心の中にある自我の状態（個性の部分）の間に発生する。
設計のアプローチの一つ。ソフトウェア製品の使用に重点を置き、人的要因、人間工学、および使用性の知識や技法を適用することによって、ソフトウェア製品の使用性を高める。
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
入力データと期待結果が具体的（実装レベル）なテストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き換えられる。
体系的なテスト方法論。テストプロセス改善のためにコンテンツベースドモデルとしても使用される。STEPによる改善は、順序には依存しない。
体系的なテスト方法論。テストプロセス改善のためにコンテンツベースドモデルとしても使用される。STEPによる改善は、順序には依存しない。
ソフトウェア製品を使用するユーザ、タスク、機器（ハードウェア、ソフトウェア、ドキュメント）、およびソフトウェアが使用される物理的および社会的環境。
使用性テストの典型的なタスクを実行する代表ユーザ。
使用性テストを実行する一連の手順を定めたドキュメント。モデレータが、ブリーフィングとセッション前インタビューの質問、使用性テストタスク、セッション後インタビューの質問の各状況を追跡するために使用する。
使用性テストにおけるテストセッション。このセッションでは、一人の使用性テストの参加者がテストを実行し、一人のモデレータがモデレートし、複数の観察者が観察する。
使用性テストを実行する活動。モデレータが指定し、使用性テストの参加者が指定期間内に完了する必要がある。
ソフトウェア製品が、特定の条件下で理解され、学びやすく、使用
しやすく、ユーザにとって魅力的である能力を判定するためのテスト。
コンポーネントまたはシステムの使用性に関わる要件。
システムを改善するため（形成的評価と呼ばれる）、またはシステムのメリットまたは価値を評価するため（総括的評価と呼ばれる）、システムの使用性に関わる情報を収集するプロセス。
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用
テスト技法の一つ。不正なアクセスを可能にする既知または未知の脆弱性を発見することを目的とする。
ネットワークからアプリケーションのレベルに至るOSIモデルの7つのレイヤーでの活動を監視し、セキュリティポリシーの違反を検出するシステム。
ソフトウェア製品の保守性を判定するテストのプロセス。
ソフトウェア製品の保守性を判定するテストのプロセス。
修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注）JIS X 0129-1:2003より引用
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
プロジェクトリスクのマネジメントにおいて、リスクの影響を効率的に軽減するためにコンティンジェンシーアクションを実行する必要のある期間。
コンポーネントやシステムのテストにおいて、信頼性に関する故障を発見し、その欠陥を取り除いていくことで時間と共に信頼性が成長することを示すモデル。
ソフトウェア製品の信頼性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
公認ハッカーで、ハッカー技法を使用して脆弱性をテストするセキュリティテスト担当者。
攻撃に役立つ可能性のある情報を取得することを目的として、ターゲット領域を探索すること。
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
品質に対する考え方の一つ。品質は正確に定義することはできないが、みれば分かる、あるいは、欠落していることにも気づくものである、というもの。この品質は、個人やグループがプロダクトに対して持つ知見や思い入れに依存する。
コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
文書化された手順と要件に特徴付けられるレビュー。たとえば、インスペクション。
他人に対する過度の感情的および精神的依存。特に、人が望ましくない振る舞いをしている場合にそれを変えさせようとせず、その支援しか行なわないという精神的状態。たとえばソフトウェアテストにおいては、テストへの移行が遅延することについてクレームを付けはするものの、足りないテスト時間を補うために超過勤務する(ある意味)「ヒーロー」的な仕事を楽しんでおり、その結果スケジュールの遅延を増長することがある。
共通の資源を共有する共通の環境の中で、他の独立したソフトウェアと共存するためのソフトウェア製品の能力。 [ISO/IEC 9126] portabilityも参照のこと。 JSTQB訳注）JIS X 0129-1:2003より引用
入力データと期待結果が具体的（実装レベル）なテストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き換えられる。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。
テスト戦略の一つ。テストチームはテストベースを分析して、カバーするテスト条件を識別する。
たとえば、プロダクトリスクまたは要件のような体系的な分析に基づくテスト。
テストスイートが遂行した条件と判定のパーセンテージ。100%の判定条件カバレッジは、100%の条件カバレッジと100%のデシジョンカバレッジを意味する。
判定の結果（これにより、どの分岐を選択するかが決まる）。
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。
コンポーネントやシステムの実行における全てのイベント (パス) のシーケンスを抽象表現したもの。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
コンポーネントやシステムの実行における一連のイベント（パス）。
（1）明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]JSTQB訳注）JIS X 0129-1:2003より引用
（2）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。
コンポーネントやシステムのソフトウェアを実行させて確認するテスト。
実行中のシステムやコンポーネントの振る舞い（たとえば、メモリの使用効率、CPUの使用状況）を評価するプロセス。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
ブラックボックステスト設計技法の一つ。原因結果グラフからテストケースを設計する。
入力、刺激（原因）、関連する出力（結果）を図式表現したもの。テストケースの設計で使用できる。
入力と刺激（原因）、および、対応する出力と処理（結果）の組み合わせを示す表。テストケースの設計に利用できる。
ブラックボックステスト設計技法の一つ。原因結果グラフからテストケースを設計する。
定義した基準に向けて進捗していることを示すメトリック。たとえば、実行したテストの合計数が、実行を計画しているテストの総数に収束することを示すメトリック。
システムを受け入れる判断に焦点を当てたテストレベル
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
テストアイテム(機能)やフィーチャーが、テストに合格したか失敗したかを判定するための判定規則。
ソフトウェア製品の合目的性を判定するためのテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
仕様に基づき、コンポーネントやシステムの振る舞いが同じとみなせる入力ドメインや出力ドメインの部分。
テスト対象に関連するデータ要素の値の集合を分割した範囲。この範囲のすべての値は、仕様に基づいて同じであるとして扱う。
テストスイートが遂行した、同値分割した領域のパーセンテージ。
ブラックボックステスト設計技法の一つ。同値分割した領域から代表値を実行するテストケースを設計する。原則として、最低1回各同値分割した領域を実行するように設計する。
仕様に基づき、コンポーネントやシステムの振る舞いが同じとみなせる入力ドメインや出力ドメインの部分。
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
プロジェクトにおける特別なマイルストン。品質ゲートは、フェーズ間に存在し、前フェーズの結果に強く依存する。品質ゲートには、その前フェーズのドキュメントの正式な確認が含まれる。
品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。
品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。
品質に関して組織を指揮し、管理するための調整された活動。注記 品質に関する指揮および管理には、通常、品質方針および品質目標の設定、品質計画、品質コントロール、品質保証および品質改善が含まれる。JSTQB訳注）JIS Q 9000:2006より引用
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
ユーザ要求を設計品質に反映し、品質を構成する機能を展開し、さらには設計品質を達成するための方法をサブシステムおよびコンポーネントの部品に展開し、最終的には製造プロセスの特定の要素に展開する方法。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
一つ以上のインシデントを引き起こしている未解明の原因。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。
テスト戦略の一つ。テストチームは回帰のリスクをマネジメントするさまざまな技法（1つ以上のレベルにおける機能／非機能回帰テストの自動化など）を適用する。
ソフトウェアが前の状態に戻ることのリスクをマネジメントするためにさまざまな技法を使用するテスト。たとえば、再利用可能なテストウェアの設計や一つ以上のテストレベルでのテストの大幅な自動化などがある。
ソフトウェア製品の回復性を判定するテストのプロセス。
ソフトウェア製品の回復性を判定するテストのプロセス。
テストスイートによって遂行された境界値のパーセンテージ。
ブラックボックステスト設計技法の一つ。境界値に基づいてテストケースを設計する。
同値分割した領域の端、あるいは端のどちらか側で最小の増加的距離にある入力値または出力値。たとえばある範囲の最小値または最大値。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。
コンポーネント、またはシステムの変更を契機に行うテストの一種。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
受け入れテストの種類の1つ。システムが契約上の要件を満たしていることを確認する。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
IDEALモデルの1フェーズであり、経験から学習し、将来の新しいプロセスと技術を適用するために自らの能力を向上させる。学習フェーズは、分析、妥当性確認、および以降の活動提案によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
テストのアプローチの一つ。テストスイートにより、入力値と事前条件の全組み合わせをテストすること。
コンパイル時にオブジェクトコードに翻訳され、プログラムが走るときに手順に沿って実行されて、データに対して動作を行なうステートメント。
入力値をどのように組み合わせても実行できないパス。
実行するための、入力値のセットと事前条件が存在するパス。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
テスト対象のシステムの動作または入手したテスト結果を基に、動的に対処するテスト。対処テストでは、ほとんどの場合、計画サイクルが短縮されており、テスト対象を受け取るまでテスト設計とテスト実装のフェーズが実施されない。
テスト戦略の一つ。テストチームはソフトウェアを受け取るまでテストの設計と実装を待ち、テスト対象の実際のシステムで対処する。
専門家がレビューする非公式な使用性レビュー。専門家は、使用性の専門家、特定分野の専門家、またはその両方である。
一般市場の多数の顧客向けに同一の規格で開発されたプロダクトの一種。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
システムが故障から回復するまでに要する平均時間。これには一般的に欠陥が解決されていることを保証するテストが含まれる。
システムにおける故障から次の故障までの平均時間。MTBFは、通常、欠陥修正プロセスの一部として、障害が発生したシステムを直ちに修復することを想定した信頼度成長モデルの一部である。
定義されたプロセスに従うレビュー。形式に則った文書の作成を伴う。
評価方法の一種。特にコンポーネントまたはシステムが引き続き設計中である場合に、その品質を改善するために設計および使用する。
特定の要件を変更する前に、開発ドキュメント、テストドキュメント、コンポーネントの各階層が、変更によりどのような影響を受けるか評価すること。
リスクが実際の結果または事象となった場合に引き起こされる損害。
使用性テスト技法の一つ。テスト参加者は使用性テストのタスクを実行する間、自身の思考を発話して、モデレータおよび観察者に伝える。思考発話法は、テスト参加者を理解するのに役立つ。
テストツールの種類の1つ。定義したテストアイテム用の負荷を生成する。また、テストの実行中に、性能を計測・記録する。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
アクターが悪意を持ってシステムまたは他のアクターに危害を及ぼすユースケース。
自己や他者、グループの感情を理解し、評価し、管理する能力、技能のこと。
情報および情報システムの可用性、完全性、認証、機密性、否認不可性を確保することで、情報および情報システムを安全に守り、防御する手段。これらの手段には、防御、検知、対応の能力を用いて情報システムを復元する手段も含まれる。
組織の成熟度の特定側面を構造的に記述した集合体で、組織のプロセスの定義と理解を助ける。成熟度モデルは、多くの場合、共通言語、ビジョンの共有、および改善活動の優先順位を付けるためのフレームワークを提供する。
定義済みプロセス領域のセット全体において、セット内の全てのゴールが達成されているプロセス改善の度合。
(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。
リソースにアクセスすることを可能にする、人、またはプロセスに付与される権限。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。
ソフトウェア製品の拡張性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
他の測定値の見積りまたは予測に使うことができる測定値。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
ランダムであるようにみえるが、実際にはいくつか事前に決められた順序に従って生成される一揃いのもの。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
攻撃者が悪意を持ってシステムへアクセスするために使用するパスまたは手段。
潜在的な悪意を持って、許可なしにデータ、機能、またはシステムの他の制限された領域にアクセスする人またはプロセス。
特定の品質特性を評価するために、直接的に焦点を定めて行なう試み。特定の故障が発生するような強制を試みることによって、通常、テスト対象の信頼性またはセキュリティを評価する。
リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。
物理的または機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、または実行の完全な打ち切りなどで特徴付けられる。
測定単位に発生したあるカテゴリの故障数の率。たとえば、単位時間あたりの故障数、トランザクション数あたりの故障数、コンピュータの運用回数あたりの故障数。
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
情報をエンコードするプロセス。認可されたもののみが一般的には特定の復号化キーまたは復号化プロセスを使用して元の情報を読み取れるようにする。
レビューミーティングで指摘された欠陥や、改善の提案を、所定の書式に記録する人。書記は、記録が読みやすく、理解しやすくなるように留意しなくてはならない。
ブラックボックステストの設計技法の一つ。無効と有効の状態遷移を実行するテストケースを設計する。
計算モデルの一つ。有限個数の状態と、それらの状態間遷移から構成される。状態遷移に対応する動作も記述できる。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
ハードウェア、ソフトウェア、または、両方の集合体。構成管理の対象であり、構成管理プロセスでは、一つの実体として扱う。
ソフトウェア製品の移植性を判定するテストのプロセス。
技術的かつ管理的な指示と監視を適用する規範。この規範の目的は、・構成アイテムの特性を機能的、物理的に識別・文書化すること、・特性に対する変更をコントロールすること、・処理の変更と実装の状況を記録し、報告すること、・特定の要求への整合を実証すること、である。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
コンポーネントまたはシステムの内部構造に基づいたカバレッジの測定値。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントやシステムの内部構造の分析に基づきテストケースを設計、選択する技法。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。
スクリプト作成技法の一つ。再使用なスクリプトまたはその一部のライブラリを構築し活用する。
コンポーネントやシステムの標準適合性を判定するテスト。
テスト戦略の一つ。テストチームは標準に従う。対象となる標準は、たとえば、国（法律標準）、ビジネスドメイン（ドメイン標準）、または内部（組織標準）に準拠する。
コンポーネントやシステムの標準適合性を判定するテスト。
規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
コンポーネントやシステムの機能仕様の分析に基づいて実施するテスト。
ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
システム統合法のアプローチの一つ。早い時期に、基本機能を動作させるために、コンポーネントやシステムを結合すること。
コンポーネントやシステムが実行すべき機能を特定した要件。
コンポーネントやシステムが、特定の条件の下で使用される場合に、定義または示唆されているニーズを満たす機能を備えている度合。
クロスファンクショナルなステークホルダのチーム。報告された欠陥の初期検出から最終的な解決（欠陥除去、欠陥除去の延期、報告取り消し）に至るまでを管理する。構成コントロール委員会と同じチームとなることがある。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムの中で識別された欠陥の数をコンポーネントまたはシステムのサイズで割った値（サイズを表す標準的な尺度には、コード行数、クラス数、またはファンクションポイント数がある）。
あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。
クロスファンクショナルなステークホルダのチーム。報告された欠陥の初期検出から最終的な解決（欠陥除去、欠陥除去の延期、報告取り消し）に至るまでを管理する。構成コントロール委員会と同じチームとなることがある。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
ソフトウェア製品の正確性を判定するためのテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
成熟度レベルとして確立したプロセスエリアのゴールに達したかをみるモデル構造であり、各レベルは次のレベルの土台となるよう組み立てられている。
テスト実行時の実行結果と期待結果との比較を自動的に実施するテストツール。
テスト関連ドキュメント（テスト計画書、テスト設計仕様書、テストケース仕様書、テスト手順仕様書、テストスクリプトなど）の階層を通して、あるテストレベルで対象となる要件を追跡すること。
テスト自動化アーキテクチャのレイヤー、コンポーネント、およびインターフェースを表現したもの。構造化されたモジュール形式のアプローチを使用してテスト自動化を実装できる。
特定ユーザや特定顧客専用に開発したソフトウェア。反対語はoff-the-shelf software（既製ソフトウェア）。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
ブラックボックステストの設計技法の一つ。無効と有効の状態遷移を実行するテストケースを設計する。
コンポーネントまたはシステムが取りうる状態を示し、ある状態から他への状態の変化の原因となる、（または）その結果として生ずる、イベントや状況を表すダイアグラム。
発生する可能性のあるイベントと状態の組み合わせから、生じる結果を示す遷移のテーブル。無効な遷移と、有効な遷移の両方を示す。
コンポーネントやシステムにおいて、二つの状態の間を遷移すること。
重要な懸念、問題、または機会を特定する評価の結果。
標準、ガイドライン、仕様、客観的な基準に基づいた手続きに遵守することを確認し、（1）開発するプロダクトの形式や内容、（2）プロダクトの開発プロセス、（3）標準やガイドライン遵守の測定方法の3つを規定したドキュメント等を含む、ソフトウェアプロダクトや開発プロセスの独立した評価。
直交表を使った変数のオールペア組み合わせテストの体系的な方法。変数を全て組み合わせたときの数を、オールペア組み合わせでテストできるまでに減らす。
特殊な数学的性質を使って構築した2次元の配列であり、配列の中から選択した二つの列から、その配列の中の各値に対して全てのペアの組み合わせを提供する。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
複合条件を評価するためのプログラミング言語/インタープリタの技法。論理演算子の片方が最終結果を決定するのに十分である場合に、他方は評価されないことがある。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
IDEALモデルの1フェーズであり、組織が、計画された目標にどのように到達するかを特定する。確立フェーズは、優先順位の決定、アプローチの開発、行動計画の活動によって構成される。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
ソフトウェア製品の移植性を判定するテストのプロセス。
ある環境から他の環境に移すためのソフトウェア製品の能力。備考：環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。
統計に基づくプロセス管理ツール。プロセスを監視し、統計的に管理されているかどうかを確認する。プロセスの平均値と、上方管理限界および下方管理限界（最大値および最小値）を図示する。
デシジョンテーブルの種類の一つ。出力に影響しない条件を考慮不要に設定して、ありえない入力または同じ出力を導き出す入力の組み合わせを一つの列（ルール）にまとめる。
テスト戦略の一つ。テストチームは事前定義した一連のテスト条件（特定のドメイン、アプリケーション、またはテストの種類に関連する可能性のある品質標準、チェックリスト、汎用化された論理テスト条件のコレクション）を使用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
プロセスを終了させることを意図した実行可能なステートメント、若しくはポイントとして定義したプロセスステップ。
ブラックボックステスト設計技法の一つ。複数のパラメータの値を特定の組み合わせで実行するためのテストケースを設計する。
テスト担当者の経験・知識・直感をベースにテストケースを導き出したり選択したりする技法。
テスト担当の経験・知識・直感をベースにテストケースを導き出したり選択したりする技法。
テスト担当者の経験・知識・直感をベースに行なうテスト。
テスト担当の経験・知識・直感をベースにテストケースを導き出したり選択したりする技法。
統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
全てのメンバーが参加することを基本に、社会の利益と組織のメンバー全員の利益と顧客満足を通じた長期的な成功を目的とした品質中心の組織全体のマネジメントアプローチ。総合的品質管理は、計画、組織化、監督、コントロールと保証からなる。
評価方法の一種。特にコンポーネントまたはシステムの設計が本質的に完了している場合に、それらの品質についての結論を収集するために設計および使用する。
テストスクリプト内に制御構造を含まない単純なスクリプト技法。
効率的にプロダクトを開発・保守するためのプロセスの重要要素を記述したフレームワーク。プロダクトの開発・保守における計画、エンジニアリング、マネジメントでのベストプラクティスをカバーする。
静的アナライザの一つ。コードに潜在する特定のセキュリティ脆弱性を検出する。
IDEALモデルの1フェーズであり、改善を展開し、実践し、組織全体に導入する。行動フェーズでは、解決策の創造、試行/試験的導入、改良、実行の活動によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
論理演算子（AND、OR、またはXOR）によって二つまたはそれ以上の単一条件が結合されたもの。たとえば、「A>B AND C>1000」。
論理演算子（AND、OR、またはXOR）によって二つまたはそれ以上の単一条件が結合されたもの。たとえば、「A>B AND C>1000」。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
要件、要件属性（たとえば、優先順位、信頼できる情報元）、注釈を記録し、要件の階層をたどる追跡や、要件変更管理を支援するツール。要件マネジメントツールの中には、あらかじめ定義した要件規約を基に、整合性や違反をチェックするような、静的解析をするものもある。
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。
以前のテストレベルで検出することを想定していたタイプの欠陥で、そのテストレベルでは検出されなかった欠陥。
受け入れテストの種類の1つ。関連する法律、ポリシー、および規制にシステムが準拠していることを確認する。
コンポーネントやシステムの標準適合性を判定するテスト。
ソフトウェアにある欠陥の診断または故障原因の追及、およびソフトウェアの修正箇所の識別を行なうためのソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
テスト実行ツールの一つ。手動テスト中の入力を記録させ、自動テストのスクリプトを作成して、後に実行（再現）させるもの。自動回帰テストで利用することが多い。
レビューミーティングで指摘された欠陥や、改善の提案を、所定の書式に記録する人。書記は、記録が読みやすく、理解しやすくなるように留意しなくてはならない。
IDEALモデルの1フェーズであり、現在の状態と改善後の状態を明らかにする。診断フェーズは、現在の状態と望ましい状態を明らかにしたり、改善すべき点を明らかにする活動で構成される。 JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。
人またはプロセスが、実際に、それが名乗っている人またはプロセスであることを確認する手順。
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
性能テストの一種。さまざまな負荷でのコンポーネントやシステムの振る舞いを評価するために使用する。負荷については、予測される使用量の低、標準、ピークを一般的に使用する。
プロジェクトの参加者への割り当てを示すマトリクス。割り当てられるものには、タスクを完了するためのさまざまな役割、あるいはプロジェクトまたはプロセスの成果物がある。役割と責任を明確にするのに特に役立つ。RACI は、ほとんどの場合に使用される 4 つの主要な役割であるResponsible（実行責任者）、Accountable（説明責任者）、Consulted（協業先）、およびInformed（報告先）からの頭字語である。
特定の要件を満たした能力を明らかにするプロセス。注）有資格（qualified）という用語は相当する能力を有する場合に使われる。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
真偽を評価できるステートメント。後続の判定ロジックの制御フローを決定する場合がある。
特定のプロセスエリア群内でのプロセス改善アプローチのための推奨順番として提供された、能力レベルをみる成熟度モデル構造。
運用環境の中で、コンポーネントやシステムを評価するテスト。
運用プロファイルの開発および実装を行なうプロセス。
着目すべきシステムやコンポーネントを使って行なわれるタスクセットの描写。各タスクは、コンポーネント、システムと利用者のやりとりやそのときに起きる可能性のある事象に基づいて行なうことが多い。タスクは物理的というより論理的であり、複数のマシン上、ある一つのタイミングのものとして実行される。
受け入れテストフェーズでの運用テスト。通常はオペレータやアドミニストレータスタッフが（シミュレートした）運用環境にて運用面に焦点を当てて行なう。この運用面とは、たとえば、回復性、リソースの振る舞い、設置性、技術的標準適合性などがある。
ユーザや顧客のサイトにインストールしたハードウェアやソフトウェア製品。この環境で、テスト中のコンポーネントやシステムを動作させる。運用環境のソフトウェアには、オペレーティングシステム、データベースマネジメントシステム、その他のアプリケーションを含むこともある。
コンポーネントやシステムの標準適合性を判定するテスト。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
組織やプロジェクトが使命を全うするために必要な要素。成功を確実なものにするために不可欠な要因や活動。
IDEALモデルの1フェーズであり、改善活動が成功するための基盤を具体化する。開始フェーズは、活動背景の確認、支援体制および活動体制の構築によって構成される。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
定義したタスク（たとえば、テストフェーズ）の開始を許可するための基準となる一般・特定の条件のセット。この目的は、開始基準を満足させるための労力に比べ、はるかに多くの（無駄な）労力を投入しないとタスクが始まらない状況を防ぐことである。
プロセスの開始を意図した実行ステートメント、若しくはポイントとして定義したプロセスステップ。
ソフトウェアを実行せずにソースコードを解析すること。
ソフトウェア開発の成果物（要件、設計、または、コードなど）の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。
（たとえば、要件またはコードなどの）ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。
公式な（文書化した）処理手続きに基づかないレビュー。
形式的な（文書化した）処理手続きに基づかないレビューの種類の1つ。
コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。
社内ネットワークなどの信頼できるネットワークの中間に置かれる物理的または論理的なサブネットワーク。インターネットなどの信頼されないネットワークへ外部向けサービスを含み、公開する。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。