目標を、汎用的ではなく、非常に具体的に定義する方法論。SMARTは、定義される目標の属性を表すSpecific（具体的な）、Measurable（測定可能な）、Attainable（達成可能な）、Relevant（妥当な）、およびTimely （タイムリーな）からの頭字語である。
それぞれに異なる特性と能力を持つさまざまな人が、特定の使用状況で特定の目標を達成するために製品またはシステムを使用できる度合。
イテレーティブ-インクリメンタル開発に基づくソフトウェア開発。自己組織化された機能横断的役割を担うチーム間での共同作業によって要件と解決策を発展させていく。
アジャイルソフトウェア開発を支援する価値に関する宣言。ここでいう価値とは、以下のようなものである。・プロセスやツールよりも個人との対話を重視する・網羅的なドキュメントよりも動作するソフトウェアを重視する・契約交渉よりも顧客との協調を重視する・計画に従うことよりも変化に対応することを重視する
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
テスト戦略の一つ。テストチームは一人以上の主要なステークホルダからの意見を戦略の詳細に反映する。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
テストスイートが、ソフトウェアのどの部分を実行（網羅）し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
統合されたシステムが、特定の要件を満たすことを実証するためのテスト。
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース（たとえば、電子データ交換やインターネット）をテストすること。
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。
統計に基づくプロセス管理ツール。プロセスを監視し、統計的に管理されているかどうかを確認する。プロセスの平均値と、上方管理限界および下方管理限界（最大値および最小値）を図示する。
アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク。
すでに記述されているテスト順序通りに実行するテスト方法。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
テストスイートによって遂行されたステートメントのパーセンテージ。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
組織や活動の業務成績の動的な測定結果を、メタファによって表されたメトリクスを用いて表現したもの。ここでいうメタファとは、自動車のダッシュボードに似せた、目にみえるダイヤルやカウンターなどである。これによって、出来事や活動の結果が容易に把握でき、業務上の目標と関連付けることができる。
テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、（テスト実施）プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。
（1）テスト組織に対して、テスト組織と他の分野との関連について、ガイダンスと戦略的指針を提供する人。（2）特定のシステム用にテストを構造化する方法を定義する人。テストツールやテストデータのマネジメントなどのトピックも定義する。
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
テストケースを作成したり選択したりするための技法。
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的またはテスト条件のために開発されたもの。
監視中に計画から逸脱していることを検出した場合に、テストプロジェクトを軌道修正するための対策を考えたり適用したりするテストマネジメントタスクの1つ。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
活動、タスク、またはテストプロセスのイベントに関して、開始/終了日、時間、依存関係を識別できるリスト。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
テスト実行前に実在する（たとえば、データベースの中にある）データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。
ファンクションポイント分析に基づき、数式でテストの必要リソースを見積る手法。
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
テストケースを作成したり選択したりするための技法。
組織にとってのテストの目的で、多くの場合、テストポリシーの一部として文書化される。
テストベースとテスト目的の定義を分析するプロセス。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
テストデータを考え出し、テスト手順の開発および優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。
テストケースを作成したり選択したりするための技法。
コンポーネントやシステムのテストを実施する熟練した専門家。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質の属性、構造要素など。
テストのさまざまな局面に紐付けられた概算結果(たとえば、工数, 完了日,コスト, テストケース数, など)。ただし、入力情報が不完全、または不確か、若しくは余計な情報を含んでいても実施できる。
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。
テストケースを作成したり選択したりするための技法。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
目標を達成するのに役立つ、一般的に認められている経験則。
情報システムの機能規模を測定する手法。ＦＰＡでの測定は、対象技術に依存しない。生産性測定、必要リソースの見積り、プロジェクトコントロールのベースとして利用できる。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
クライアントにとっての機能性価値(フィーチャー)の観点で駆動される、イテレーティブかつインクリメンタルなソフトウェア開発プロセス。フィーチャー駆動開発は、ほとんどの場合、アジャイルソフトウェア開発で使用する。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
合意に基づく見積り技法の一つ。アジャイルソフトウェア開発で、ユーザストーリーの作業量または相対規模を見積るのに使用される。ワイドバンドデルファイ方法の一つの種類で、チームが見積る単位を表す一組のカードを使用する。
次のプロジェクトまたは次のプロジェクトフェーズを改善するために、教訓を学び、具体的なアクションプランを作成する構造化された方法。
（テスト）プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。
テスト戦略の一つ。テストチームは一連の事前定義されたプロセスに従う。これらのプロセスでは、ドキュメント、テストベースおよびテストオラクルの適切な特定と使用、およびテストチームの組織などの項目に言及する。
相互関係のある活動のセット。入力を出力に変換する。
与えられた状況下で、組織の作業効率に寄与する優れた手法や革新的な実践法。他の同等な組織から、「最善」と認められることが多い。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
人々のさまざまな性格およびコミュニケーションスタイルを表す、個人の心理学的な傾向の指標。
（中間）成果物と結果の準備完了が定義されている、プロジェクトのある一時点。
テスト戦略の一つ。テストチームはテストウェアをモデルから生成する。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[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）使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
定義した基準に向けて進捗していることを示すメトリック。たとえば、実行したテストの合計数が、実行を計画しているテストの総数に収束することを示すメトリック。
システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザー、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。
プロジェクトにおける特別なマイルストン。品質ゲートは、フェーズ間に存在し、前フェーズの結果に強く依存する。品質ゲートには、その前フェーズのドキュメントの正式な確認が含まれる。
品質にかかる活動や問題のトータルコスト。予防コストと評価コスト、内部失敗コスト、外部失敗コストというように分ける場合が多い。
品質マネジメントの一環としての運用技法および活動。品質要件を満たすことに重点を置く。
品質に関して組織を指揮し、管理するための調整された活動。注記 品質に関する指揮および管理には、通常、品質方針および品質目標の設定、品質計画、品質コントロール、品質保証および品質改善が含まれる。JSTQB訳注）JIS Q 9000:2006より引用
品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。
テスト戦略の一つ。テストチームは回帰のリスクをマネジメントするさまざまな技法（1つ以上のレベルにおける機能／非機能回帰テストの自動化など）を適用する。
(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
テスト対象のシステムの動作または入手したテスト結果を基に、動的に対処するテスト。対処テストでは、ほとんどの場合、計画サイクルが短縮されており、テスト対象を受け取るまでテスト設計とテスト実装のフェーズが実施されない。
テスト戦略の一つ。テストチームはソフトウェアを受け取るまでテストの設計と実装を待ち、テスト対象の実際のシステムで対処する。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
特定の要件を変更する前に、開発ドキュメント、テストドキュメント、コンポーネントの各階層が、変更によりどのような影響を受けるか評価すること。
ソフトウェア製品の性能を判定するテスト。 JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
(1)プロセスや作業の有効性と効率に関する組織の能力。(2)ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力。
他の測定値の見積りまたは予測に使うことができる測定値。
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。
一般の市場用（不特定多数のユーザ用）に開発したソフトウェア製品。全く同じものを多数の顧客に提供する。
システムやコンポーネントが、処理時間やスループット率の制約内で、定義した機能を果たす度合。
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化することが期待できる。
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
技術的かつ管理的な指示と監視を適用する規範。この規範の目的は、・構成アイテムの特性を機能的、物理的に識別・文書化すること、・特性に対する変更をコントロールすること、・処理の変更と実装の状況を記録し、報告すること、・特定の要求への整合を実証すること、である。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
テスト戦略の一つ。テストチームは標準に従う。対象となる標準は、たとえば、国（法律標準）、ビジネスドメイン（ドメイン標準）、または内部（組織標準）に準拠する。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
コンポーネントやシステムの機能仕様の分析に基づいて実施するテスト。
ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備を報告するドキュメント。
あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。
コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備。たとえば、不正なステートメントまたはデータ定義。実行中に欠陥に遭遇した場合、コンポーネントまたはシステムの故障を引き起こす。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
重要な懸念、問題、または機会を特定する評価の結果。
ソフトウェア製品の相互運用性を判定するテストのプロセス。
問題のさまざまな根本的原因の相互関係を整理し示すための図表現。（潜在的な）欠陥あるいは故障をルートノードとする水平的なツリー構造を用いて、その欠陥あるいは故障の原因をカテゴリ、サブカテゴリに整理する。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
統計に基づくプロセス管理ツール。プロセスを監視し、統計的に管理されているかどうかを確認する。プロセスの平均値と、上方管理限界および下方管理限界（最大値および最小値）を図示する。
テスト戦略の一つ。テストチームは事前定義した一連のテスト条件（特定のドメイン、アプリケーション、またはテストの種類に関連する可能性のある品質標準、チェックリスト、汎用化された論理テスト条件のコレクション）を使用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。
統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。
コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
コンポーネントまたはシステムの内部構造の分析に基づいたテスト。
プロジェクトの参加者への割り当てを示すマトリクス。割り当てられるものには、タスクを完了するためのさまざまな役割、あるいはプロジェクトまたはプロセスの成果物がある。役割と責任を明確にするのに特に役立つ。RACI は、ほとんどの場合に使用される 4 つの主要な役割であるResponsible（実行責任者）、Accountable（説明責任者）、Consulted（協業先）、およびInformed（報告先）からの頭字語である。
運用プロファイルの開発および実装を行なうプロセス。
着目すべきシステムやコンポーネントを使って行なわれるタスクセットの描写。各タスクは、コンポーネント、システムと利用者のやりとりやそのときに起きる可能性のある事象に基づいて行なうことが多い。タスクは物理的というより論理的であり、複数のマシン上、ある一つのタイミングのものとして実行される。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
定義したタスク（たとえば、テストフェーズ）の開始を許可するための基準となる一般・特定の条件のセット。この目的は、開始基準を満足させるための労力に比べ、はるかに多くの（無駄な）労力を投入しないとタスクが始まらない状況を防ぐことである。
（たとえば、要件またはコードなどの）ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。
コンポーネントやシステムで、機能に関係しない属性のテスト。たとえば、信頼性、効率性、使用性、保守性、移植性のテスト。