開始、計画、および改善のアクションを実装するためのロードマップとして機能する組織的な改善モデル。IDEALモデルは、開始、診断、確立、行動、および学習の五つのフェーズにちなんで名付けられた。JSTQB訳注）IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。
リスクベースドテストの体系的なアプローチ。プロダクトリスクの識別と分析を行ない、発生可能性および影響に基づくプロダクトリスクマトリクスを作成する。この用語はProduct RISk MAnagement（プロダクトリスクマネジメント）の略語である。
テストプロセスを改善するための、継続するビジネス駆動のフレームワーク。効果的で効率的なテストプロセスの主要な要素を定義する。
要求仕様から保守までのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。
プロジェクトとは異なる場所で、従業員ではない人々により実行されるテスト。
それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
同じ組織ではない人が、プロジェクトチームと同じ場所で行なうテスト。
ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。
アジャイルソフトウェア開発の中で使用されるソフトウェアエンジニアリング方法論。中心となるプラクティスは、ペアプログラミング、徹底したコードレビュー、全てのコードの単体テスト、単純明快なコードなどである。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
ソフトウェアツールの一つの種類。全ての潜在的なユーザに、通常はインターネットを介して、ソースコードの形式で提供される。一般的に、ユーザはライセンスの下で許可が与えられ、調査、変更、機能強化、場合によってはソフトウェア配布を行なうために使用する。
特定のユーザまたは顧客へ特別に開発されたソフトウェアツール。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
12の重要なプロセスから構成されるテストプロセス改善のためのコンテンツベースドモデル。企業の利益や評価に影響を与えるようなミッションクリティカルなプロセスやコンピタンスの状況を同僚や経営陣が判断できるよう高度に可視化したプロセスを含む。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
テストスイートが、ソフトウェアのどの部分を実行（網羅）し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
相互接続したドメインと複数レベルのネットワークに組み込まれた複数の分散システムや異機種環境のこと。通常、共通的な管理構造を持たずに、広範囲に専門領域間をまたがる共通の問題や目的に対処する。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース（たとえば、電子データ交換やインターネット）をテストすること。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
組織のソフトウェアプロセスとその結果のパフォーマンスおよび成熟度を改善する活動プログラム。
フォールト（欠陥）の原因分析で使用する方法。特定の顕在化したフォールトと結びつく、故障やヒューマンエラーおよび外部イベントの関係を論理的に視覚化したモデルにする技法。
リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。
どのような技術的アプローチをとるかで意見を一致させることを目的とした、ピアグループによるディスカッション。
責任を分離すること。これにより、客観的なテストを促進できる。
テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
テストアイテム用のテストケースのセット（目的、入力値、テスト実行、期待結果、実行事前条件）を規定するドキュメント。
テストケースを作成したり選択したりするための技法。
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
監視中に計画から逸脱していることを検出した場合に、テストプロジェクトを軌道修正するための対策を考えたり適用したりするテストマネジメントタスクの1つ。
識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。
テスト活動と結果を要約したドキュメント。テストアイテムがテスト終了基準を満足しているかどうかの評価も含む。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。
テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
テストマネージャをマネジメントする上級マネージャ。
テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テストプロジェクトの状態の周期的なチェックに関連した活動を扱うテスト管理タスク。実際の活動と計画した活動とを比較した報告が準備される。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
大規模なプロジェクトで、テストマネージャに報告を行い、特定のテストレベルやテスト活動に責任を持つ個人。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テスト活動と結果を要約したドキュメント。テストアイテムがテスト終了基準を満足しているかどうかの評価も含む。
定期的に作成するテストの活動と結果をまとめたドキュメント。テスト活動の進捗がベースライン（当初のテスト計画など）に沿っているかどうか報告するため、かつリスクや決定が必要な代替案をマネジメント層へ伝えるために作成する。
テストケースを作成したり選択したりするための技法。
テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。
組織にとってのテストの目的で、多くの場合、テストポリシーの一部として文書化される。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
テストベースとテスト目的の定義を分析するプロセス。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
テスト手順を実行していくための計画。注）テスト実行スケジュールには、実際に実行するテスト手順書の内容とその実行順を記述する。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。
能力成熟度モデル統合（CMMI）と関連させた５段階からなるテストプロセス改善のためのフレームワークであり、効果的なテストプロセスのための重要要素を記述している。
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む。
テストケースを作成したり選択したりするための技法。
コンポーネントやシステムのテストを実施する熟練した専門家。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストのさまざまな局面に紐付けられた概算結果(たとえば、工数, 完了日,コスト, テストケース数, など)。ただし、入力情報が不完全、または不確か、若しくは余計な情報を含んでいても実施できる。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
テスト入力を生成することでテスト設計を支援するツール。テスト入力の生成は、CASEツールのリポジトリ(たとえば要件マネジメントツール)に格納している仕様、ツールの中に保存してある特定のテスト条件、またはコードから行なわれる。
テストアイテムのテスト条件（カバレッジアイテム）、詳細なテストアプローチ、および、関連する高位レベルテストケースを記述したドキュメント。
テストケースを作成したり選択したりするための技法。
概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。
定期的に作成するテストの活動と結果をまとめたドキュメント。テスト活動の進捗がベースライン（当初のテスト計画など）に沿っているかどうか報告するため、かつリスクや決定が必要な代替案をマネジメント層へ伝えるために作成する。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
入力と刺激（原因）、および、対応する出力と処理（結果）の組み合わせを示す表。テストケースの設計に利用できる。
ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。
2つのエンティティ（たとえば、要件とテストケース）を関係付ける2次元の表。この表を使用すると、エンティティ間の関係を前工程および後工程の双方向に追跡できるので、達成したカバレッジを測定でき、変更点の影響を評価できる。
ドキュメントとソフトウェアの関連事項（たとえば、ある要件と、それを検証するテストケース）を識別する能力。
リスクの要素を特徴付けるために使う技法。ハザード分析の結果はシステム開発やテストのために使う手法を牽引する。
ハードウェアコンポーネントとソフトウェアコンポーネントとの間のインターフェースおよび相互作用に存在する欠陥を検出するために実行されるテスト。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
意思決定における統計的手法の一つで、全体的影響を与える特定の重要な要因を選択するために使用される。品質改善の面では、問題の大半（80％）は少数の主要な原因（20％）によって発生する。
ブラックボックステスト設計技法の一つ。同値分割した領域から代表値を実行するテストケースを設計する。原則として、最低1回各同値分割した領域を実行するように設計する。
目標を達成するのに役立つ、一般的に認められている経験則。
新たに作成した各ビルドに対して、完全性を確認し、主要な機能性、安定性、および試験性を検証する自動化テストのセット。ビルドが頻繁にリリースされる場合（たとえば、アジャイルプロジェクト）に、業界で一般的に行なわれるテストである。新たに作成したビルドは、このテストの完了後に、次のテストに向けてリリースされる。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェアライフサイクルの同一フェーズ内における、混入した欠陥数に対する除去された欠陥数のパーセンテージ。
フォールト（欠陥）の原因分析で使用する方法。特定の顕在化したフォールトと結びつく、故障やヒューマンエラーおよび外部イベントの関係を論理的に視覚化したモデルにする技法。
コンポーネントまたはシステムの中で識別された欠陥の数をコンポーネントまたはシステムのサイズで割った値（サイズを表す標準的な尺度には、コード行数、クラス数、またはファンクションポイント数がある）。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
テストスイートによって遂行された分岐のパーセンテージ。100%のブランチカバレッジは100%のデシジョンカバレッジと100%のステートメントカバレッジの両方を意味する。
次のプロジェクトまたは次のプロジェクトフェーズを改善するために、教訓を学び、具体的なアクションプランを作成する構造化された方法。
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
参照モデルを用いた、組織におけるソフトウェアプロセスの統制度合の評価。
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。
プロセスモデルの一つ。ベストプラクティスの汎用的に使用できる部分と、事前に定義された手順を順に実行してプロセスを改善する方法とを提供する。
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
相互関係のある活動のセット。入力を出力に変換する。
与えられた状況下で、組織の作業効率に寄与する優れた手法や革新的な実践法。他の同等な組織から、「最善」と認められることが多い。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
ソフトウェアの取得、供給、開発、運用、保守、といったプロセスを体系的に評価すること。管理者や管理者の代理者が、進捗を監視し、計画やスケジュールの状態を判定し、要件やシステム割り当てを確認し、目的遂行用に最適化されるようマネジメントアプローチの効率を評価する。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
（1）インスペクションや、レビュープロセスに責任を持つ、リーダや中心人物。（2）使用性テストセッションを遂行する中立的な立場の人物。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
高位のユーザ要件またはビジネス要件。主に、アジャイルソフトウェア開発で用いられる。ユーザが要求する機能とその背景にある理由、およびあらゆる非機能を獲得し、日常言語またはビジネス言語で表現される一つの文で構成する。また、受け入れ基準も含む。
アクターとコンポーネントまたはシステムとの間の対話における一連のトランザクション。視覚できる結果を伴う。アクターは、ユーザまたはシステムと情報交換するあらゆるものになりうる。
プロダクトまたはプロジェクトの全期間をフェーズに分割したもの。
独自の適応性を持つ反復ソフトウェア開発プロセスフレームワーク。方向付け、推敲、作成、および移行の四つのプロジェクトライフサイクルフェーズで構成される。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、またはリスクの潜在する影響)で分類されたリスクのセット。特定のプロダクトリスクのタイプはそれを軽減(コントロール)できるテストタイプと関連付けられる。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、またはリスクの潜在する影響)で分類されたリスクのセット。特定のプロダクトリスクのタイプはそれを軽減(コントロール)できるテストタイプと関連付けられる。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを評価するプロセス。一般的に、それらのリスクの影響度と発生確率（可能性）を見積ることによって行なう。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。
レビュープロセスを支援するツール。レビューの計画、追跡の支援、コミュニケーションのサポート、協調的なレビューの推進、収集や報告用のメトリクスを保存する機能を備えていることが多い。
意図するレビュー活動のアプローチ、リソース、およびスケジュールを記述するドキュメント。特に、レビュー対象のドキュメントとコード、使用するレビューの種類、参加者、公式レビューの場合に適用される開始と終了の基準、それらを選択した理由などが識別される。レビュー計画プロセスの記録である。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
専門家によるテスト見積り技法。チームメンバーから集めた知識を用い、正確な見積りをするもの。
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、または知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
入力データと期待結果が具体的（実装レベル）なテストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き換えられる。
体系的なテスト方法論。テストプロセス改善のためにコンテンツベースドモデルとしても使用される。STEPによる改善は、順序には依存しない。
ソフトウェア製品が、特定の条件下で理解され、学びやすく、使用
しやすく、ユーザにとって魅力的である能力を判定するためのテスト。
コンポーネントまたはシステムの使用性に関わる要件。
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用
修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注）JIS X 0129-1:2003より引用
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。
文書化された手順と要件に特徴付けられるレビュー。たとえば、インスペクション。
入力データと期待結果が具体的（実装レベル）なテストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き換えられる。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。
（1）明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]JSTQB訳注）JIS X 0129-1:2003より引用
（2）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。
コンポーネントやシステムのソフトウェアを実行させて確認するテスト。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
ブラックボックステスト設計技法の一つ。原因結果グラフからテストケースを設計する。
入力、刺激（原因）、関連する出力（結果）を図式表現したもの。テストケースの設計で使用できる。
入力と刺激（原因）、および、対応する出力と処理（結果）の組み合わせを示す表。テストケースの設計に利用できる。
ブラックボックステスト設計技法の一つ。原因結果グラフからテストケースを設計する。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
ブラックボックステスト設計技法の一つ。同値分割した領域から代表値を実行するテストケースを設計する。原則として、最低1回各同値分割した領域を実行するように設計する。
品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
ユーザ要求を設計品質に反映し、品質を構成する機能を展開し、さらには設計品質を達成するための方法をサブシステムおよびコンポーネントの部品に展開し、最終的には製造プロセスの特定の要素に展開する方法。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。
テスト戦略の一つ。テストチームは回帰のリスクをマネジメントするさまざまな技法（1つ以上のレベルにおける機能／非機能回帰テストの自動化など）を適用する。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
コンポーネントやシステムをテストしたときに、生じた／観察された振る舞い。
システムにおける故障から次の故障までの平均時間。MTBFは、通常、欠陥修正プロセスの一部として、障害が発生したシステムを直ちに修復することを想定した信頼度成長モデルの一部である。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
組織の成熟度の特定側面を構造的に記述した集合体で、組織のプロセスの定義と理解を助ける。成熟度モデルは、多くの場合、共通言語、ビジョンの共有、および改善活動の優先順位を付けるためのフレームワークを提供する。
定義済みプロセス領域のセット全体において、セット内の全てのゴールが達成されているプロセス改善の度合。
(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。
リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
技術的かつ管理的な指示と監視を適用する規範。この規範の目的は、・構成アイテムの特性を機能的、物理的に識別・文書化すること、・特性に対する変更をコントロールすること、・処理の変更と実装の状況を記録し、報告すること、・特定の要求への整合を実証すること、である。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
コンポーネントまたはシステムの内部構造に基づいたカバレッジの測定値。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。
規格、規約または法律上および類似の法規上の規則を遵守するソフトウェア製品の能力。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネントやシステムが実行すべき機能を特定した要件。
クロスファンクショナルなステークホルダのチーム。報告された欠陥の初期検出から最終的な解決（欠陥除去、欠陥除去の延期、報告取り消し）に至るまでを管理する。構成コントロール委員会と同じチームとなることがある。
欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムの中で識別された欠陥の数をコンポーネントまたはシステムのサイズで割った値（サイズを表す標準的な尺度には、コード行数、クラス数、またはファンクションポイント数がある）。
クロスファンクショナルなステークホルダのチーム。報告された欠陥の初期検出から最終的な解決（欠陥除去、欠陥除去の延期、報告取り消し）に至るまでを管理する。構成コントロール委員会と同じチームとなることがある。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
テスト関連ドキュメント（テスト計画書、テスト設計仕様書、テストケース仕様書、テスト手順仕様書、テストスクリプトなど）の階層を通して、あるテストレベルで対象となる要件を追跡すること。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
標準、ガイドライン、仕様、客観的な基準に基づいた手続きに遵守することを確認し、（1）開発するプロダクトの形式や内容、（2）プロダクトの開発プロセス、（3）標準やガイドライン遵守の測定方法の3つを規定したドキュメント等を含む、ソフトウェアプロダクトや開発プロセスの独立した評価。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
テスト担当者の経験・知識・直感をベースに行なうテスト。
統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
効率的にプロダクトを開発・保守するためのプロセスの重要要素を記述したフレームワーク。プロダクトの開発・保守における計画、エンジニアリング、マネジメントでのベストプラクティスをカバーする。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。
以前のテストレベルで検出することを想定していたタイプの欠陥で、そのテストレベルでは検出されなかった欠陥。
修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。
テスト対象に存在する欠陥を識別できなかったテスト結果。
テスト対象には欠陥が存在しないにもかかわらず、欠陥として報告したテスト結果。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
特定の要件を満たした能力を明らかにするプロセス。注）有資格（qualified）という用語は相当する能力を有する場合に使われる。
運用プロファイルの開発および実装を行なうプロセス。
着目すべきシステムやコンポーネントを使って行なわれるタスクセットの描写。各タスクは、コンポーネント、システムと利用者のやりとりやそのときに起きる可能性のある事象に基づいて行なうことが多い。タスクは物理的というより論理的であり、複数のマシン上、ある一つのタイミングのものとして実行される。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
組織やプロジェクトが使命を全うするために必要な要素。成功を確実なものにするために不可欠な要因や活動。
定義したタスク（たとえば、テストフェーズ）の開始を許可するための基準となる一般・特定の条件のセット。この目的は、開始基準を満足させるための労力に比べ、はるかに多くの（無駄な）労力を投入しないとタスクが始まらない状況を防ぐことである。
ソフトウェアを実行せずにソースコードを解析すること。
ソフトウェア開発の成果物（要件、設計、または、コードなど）の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。
（たとえば、要件またはコードなどの）ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。
公式な（文書化した）処理手続きに基づかないレビュー。
コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。
具体的な（実行レベルの）入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。