コンポーネントまたはシステムに含まれる、定義された形式の構造で情報を交換するインターフェースの1つ。Application Programming Interface の頭字語。
グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。
セキュリティ攻撃方法の一つ。悪意のあるSQLステートメントを入力フィールドに挿入して実行する。
セキュリティ攻撃に使用することを目的として、ユーザアカウント情報をトライ＆エラーで繰り返し試みて取得するプロセス。
特定の方法でテスト対象とやりとりするユーザーまたは他の人、あるいはシステム。
マルウェアを検出し阻止するソフトウェア。malwareも参照のこと。
セキュリティ脅威の一つ。多くの場合、組織内の認可されているシステムユーザが実行する。
インシデントを認識、調査、対策、解明するプロセス。インシデントの記録、分類、影響度の識別が必要。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。
ドキュメントの著者による段階的なドキュメント内容の説明。情報を集めて、内容の共通理解を確立するために行なう。
ソフトウェアツールの一つの種類。全ての潜在的なユーザに、通常はインターネットを介して、ソースコードの形式で提供される。一般的に、ユーザはライセンスの下で許可が与えられ、調査、変更、機能強化、場合によってはソフトウェア配布を行なうために使用する。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
脆弱性の一つ。悪意のあるコードを安全なWebサイトへ感染させるために攻撃者が悪用することを可能にする。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
高度な命令語で表現されたプログラムを、等価の機械語に翻訳するソフトウェアツール。
セキュリティ攻撃の成功度合を判定し、発生した被害を評価する作業。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
セキュリティ攻撃方法の一つ。サービスできない正当なリクエストなどを大量に送りつけてシステムを過負荷状態にする。
相互接続したドメインと複数レベルのネットワークに組み込まれた複数の分散システムや異機種環境のこと。通常、共通的な管理構造を持たずに、広範囲に専門領域間をまたがる共通の問題や目的に対処する。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
セキュリティポリシーおよび異なる複数のレイヤーを適用して、システムのセキュリティの脆弱性を削減する段階的なプロセス。
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース（たとえば、電子データ交換やインターネット）をテストすること。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
自身ではなく他のハッカーが作成したセキュリティ攻撃を実行する人。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
テストスイートによって遂行されたステートメントのパーセンテージ。
セキュリティ攻撃を成功させる可能性があるシステムの弱点。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
セキュリティポリシーを実装するために必要な手順と、セキュリティインシデントに対処する際に実行する手順のセット。
システムまたはコンポーネント、リソース、情報への不正なアクセスを成功させようとする試み。またはシステムの完全性を侵害しようとする試み。
組織にとってのセキュリティに関わるプロセスとインフラストラクチャを評価する監査。
許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに廃棄フェーズを含むこともある。注）これらのフェーズは重複することもあるし、反復することもある。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
暗号化技法の一つ。ユーザデータに任意のデータ（ソルト）を追加してから、ハッシュ処理を行う。
システムまたはネットワークを攻撃するために使用できる情報（パスワードなど）を詐取する試み。
組織や活動の業務成績の動的な測定結果を、メタファによって表されたメトリクスを用いて表現したもの。ここでいうメタファとは、自動車のダッシュボードに似せた、目にみえるダイヤルやカウンターなどである。これによって、出来事や活動の結果が容易に把握でき、業務上の目標と関連付けることができる。
どのような技術的アプローチをとるかで意見を一致させることを目的とした、ピアグループによるディスカッション。
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
（1）テスト組織に対して、テスト組織と他の分野との関連について、ガイダンスと戦略的指針を提供する人。（2）特定のシステム用にテストを構造化する方法を定義する人。テストツールやテストデータのマネジメントなどのトピックも定義する。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。
コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
テストベースとテスト目的の定義を分析するプロセス。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、または、手動テストスクリプトとしても知られる。
コンポーネントやシステムのテストを実施する熟練した専門家。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。
発生したあらゆるイベント（テストの最中に調査を必要とする事象など）を報告するドキュメント。
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。
個人を特定できる情報または機密情報を保護して、意図せず漏洩しないようにすること。
データ変換法の一つ。元のデータを判読できないようにする。
スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
信頼のレベルが定義されているサブネットワーク。たとえば、インターネットゾーンおよびパブリックゾーンは信頼できるとはみなされない。
通常は悪意を持って、セキュリティ攻撃に関与する人または組織。
可変長の文字列を、通常、より短い固定長の値またはキーに変換するプロセス。テーブルまたはデータベースを照会する際は、一般的には、ハッシュ化された値またはハッシュを使用する。また、暗号化ハッシュ関数を使用して、データをセキュリティで保護する。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
セキュリティ攻撃方法の一つ。コンピュータシステムに格納されている、またはネットワーク経由で転送されている秘密のパスワードを復元する。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。
目標を達成するのに役立つ、一般的に認められている経験則。
事前に定義されたセキュリティ規則に基づいてネットワークの送受信トラフィックを制御する単独または一連のコンポーネント。
ソフトウェアテスト技法の一つ。セキュリティの脆弱性を見つけるために、ファズと呼ばれる大量のランダムデータをコンポーネントまたはシステムに入力する。
ソフトウェアテスト技法の一つ。セキュリティの脆弱性を見つけるために、ファズと呼ばれる大量のランダムデータをコンポーネントまたはシステムに入力する。
セキュリティ攻撃方法の一つ。ユーザに気付かれることなく、また同意を得ることなく、Webサイトのトラフィックを不正なWebサイトに転送する。
電子通信において信頼されるエンティティになりすまして、個人情報または機密情報を取得する試み。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
攻撃に役立つ可能性のある情報を取得することを目的として、ターゲット領域を探索すること。
テストスイートによって遂行された分岐のパーセンテージ。100%のブランチカバレッジは100%のデシジョンカバレッジと100%のステートメントカバレッジの両方を意味する。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
相互関係のある活動のセット。入力を出力に変換する。
与えられた状況下で、組織の作業効率に寄与する優れた手法や革新的な実践法。他の同等な組織から、「最善」と認められることが多い。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
ボットまたはロボットと呼ばれる侵害されたコンピュータのネットワーク。第三者によって制御され、マルウェアまたはスパムを送信するため、または攻撃を実行するために使用される。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
インターフェースで受信した悪意のあるコードを検出および除去することを目的とする静的解析。
システムまたはそのコンポーネントに危害を与えることを目的とするソフトウェア。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
アクターとコンポーネントまたはシステムとの間の対話における一連のトランザクション。視覚できる結果を伴う。アクターは、ユーザまたはシステムと情報交換するあらゆるものになりうる。
プロダクトまたはプロジェクトの全期間をフェーズに分割したもの。
リスクが実際の結果または事象となった場合に引き起こされる損害。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的（高/中/低など）または定量的に表現できる。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを評価するプロセス。一般的に、それらのリスクの影響度と発生確率（可能性）を見積ることによって行なう。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
特定のレベルまでリスクを減らす（あるいは、リスクレベルを維持する）ために、判定を下したり、対策したりするプロセス。
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。
テストやテスト手順の実行後に満足すべき、環境と状態の条件。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用
テスト技法の一つ。不正なアクセスを可能にする既知または未知の脆弱性を発見することを目的とする。
ネットワークからアプリケーションのレベルに至るOSIモデルの7つのレイヤーでの活動を監視し、セキュリティポリシーの違反を検出するシステム。
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
公認ハッカーで、ハッカー技法を使用して脆弱性をテストするセキュリティテスト担当者。
攻撃に役立つ可能性のある情報を取得することを目的として、ターゲット領域を探索すること。
あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。
コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。
判定の結果（これにより、どの分岐を選択するかが決まる）。
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。
コンポーネントやシステムの実行における全てのイベント (パス) のシーケンスを抽象表現したもの。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
コンポーネントやシステムの実行における一連のイベント（パス）。
（1）明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]JSTQB訳注）JIS X 0129-1:2003より引用
（2）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。
コンポーネントやシステムのソフトウェアを実行させて確認するテスト。
実行中のシステムやコンポーネントの振る舞い（たとえば、メモリの使用効率、CPUの使用状況）を評価するプロセス。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
システムを受け入れる判断に焦点を当てたテストレベル
ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない終了基準。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
仕様に基づき、コンポーネントやシステムの振る舞いが同じとみなせる入力ドメインや出力ドメインの部分。
仕様に基づき、コンポーネントやシステムの振る舞いが同じとみなせる入力ドメインや出力ドメインの部分。
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
(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より引用
人またはプロセスが、実際に、それが名乗っている人またはプロセスであることを確認する手順。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
ユーザや顧客のサイトにインストールしたハードウェアやソフトウェア製品。この環境で、テスト中のコンポーネントやシステムを動作させる。運用環境のソフトウェアには、オペレーティングシステム、データベースマネジメントシステム、その他のアプリケーションを含むこともある。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
ソフトウェア開発の成果物（要件、設計、または、コードなど）の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。
（たとえば、要件またはコードなどの）ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。
社内ネットワークなどの信頼できるネットワークの中間に置かれる物理的または論理的なサブネットワーク。インターネットなどの信頼されないネットワークへ外部向けサービスを含み、公開する。