用語集
TOP >  用語集
JSTQBに準拠したソフトウェアテストに関する用語集ページです。
フリーキーワード検索と五十音索引で簡単に調べることができます。
(出典:ソフトウェアテスト標準用語集 V2.3.J02)
用語検索


検索結果:50件

RACI matrix (責任分担(RACI)マトリクス)
プロジェクトの参加者への割り当てを示すマトリクス。割り当てられるものには、タスクを完了するためのさまざまな役割、あるいはプロジェクト又はプロセスの成果物がある。役割と責任を明確にするのに特に役立つ。RACI は、ほとんどの場合に使用される 4 つの主要な役割である Responsible(実行責任者)、Accountable(説明責任者)、Consulted(協業先)、及びInformed(報告先)からの頭字語である。


random testing (ランダムテスト)
ブラックボックステスト設計技法の一つ。擬似ランダム生成アルゴリズム等を使い、運用プロファイルに合致するテストケースを設計する。信頼性、性能等、非機能特性のテストに利用できる。


Rational Unified Process (ラショナル統一プロセス)
独自の適応性を持つ反復ソフトウェア開発プロセスフレームワーク。方向付け、推敲、作成、及び移行の四つのプロジェクトライフサイクルフェーズで構成される。


re-testing (再テスト)
confirmation testingを参照のこと。


reactive testing (対処テスト)
テスト対象の実際のシステムの動作又は入手したテスト結果を基に、動的に対処するテスト。対処テストでは、ほとんどの場合、計画サイクルが短縮されており、テスト対象を受け取るまでテスト設計とテスト実装のフェーズが実施されない。


record/playback tool (記録再生ツール)
capture/playback toolを参照のこと。


recorder (記録者)
scribeを参照のこと。


recoverability (回復性)
故障時に、指定された達成水準を再確立し、直接に影響を受けたデータを回復するソフトウェア製品の能力。[ISO/IEC 9126] reliabilityも参照のこと。JSTQB訳注)JIS X 0129-1:2003より引用


recoverability testing (回復性テスト)
ソフトウェア製品の回復性を判定するテストのプロセス。reliability testingも参照のこと。


recovery testing (回復テスト)
recoverability testingを参照のこと。


regression testing (回帰テスト)
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。


regression-averse testing (回帰回避テスト)
ソフトウェアが前の状態に戻ることのリスクをマネジメントするためにさまざまな技法を使用するテスト。たとえば、再利用可能なテストウェアの設計や一つ以上のテストレベルでのテストの大幅な自動化などがある。


regulation testing (規程テスト)
compliance testingを参照のこと。


release note (リリースノート)
テストアイテム、その構成、現在の状態、その他のリリース情報を記述したドキュメント。テスト実行フェーズの開始前に、開発側からテスト関係者へ、場合によって他のステークホルダに提供する。[After IEEE 829]


reliability (信頼性)
指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力。[ISO/IEC 9126] JSTQB訳注)JIS X 0129-1:2003より引用


reliability growth model (信頼度成長モデル)
コンポーネントやシステムのテストにおいて、信頼性に関する故障を発見し、その欠陥を取り除いていくことで時間と共に信頼性が成長することを示すモデル。


reliability testing (信頼性テスト)
ソフトウェア製品の信頼性を判定するテストのプロセス。


replaceability (置換性)
同じ環境で、同じ目的のために、他の指定されたソフトウェア製品から置き換えて使用することができるソフトウェア製品の能力。[ISO/IEC 9126] portabilityも参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


requirement (要件)
ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。[After IEEE 610]


requirements management tool (要件マネジメントツール)
要件、要件属性(たとえば、優先順位、信頼できる情報元)、注釈を記録し、要件の階層をたどる追跡や、要件変更管理を支援するツール。要件マネジメントツールの中には、あらかじめ定義した要件規約を基に、整合性や違反をチェックするような、静的解析をするものもある。


requirements phase (要件フェーズ)
ソフトウェアライフサイクルの一区切りの期間。ソフトウェアプロダクトの要件を定義、文書化する。[IEEE 610]


requirements-based testing (要件ベースドテスト)
テストのアプローチの一つ。要件から導き出したテスト目的とテスト条件を基にしてテストケースを設計する。たとえば、特定の機能を遂行するテスト、又は、信頼性や使用性のような非機能特性を調べるテスト。


resource utilization (資源効率性)
明示的な条件の下で、ソフトウェアの機能を実行する際の、資源の量及び資源の種類を適切に使用するソフトウェア製品の能力。たとえば、プログラムが使うメインメモリとセカンダリメモリ量、必要な一時ファイルやオーバーフローファイルの大きさ。 [After ISO/IEC 9126] efficiencyも参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


resource utilization testing (資源効率性テスト)
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。efficiency testingも参照のこと。


result (結果)
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。actual result, expected resultも参照のこと。


resumption criteria (再開基準)
テストの中断後、テスト活動の全て又は一部を再開するために使用される基準。


resumption requirements (再開要件)
中断後のテスト再開時に、繰り返す必要のある定義済みのテスト活動のセット。[After IEEE 829]


retrospective meeting (振り返りミーティング)
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。


review (レビュー)
プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。[After IEEE 1028]


review plan (レビュー計画)
意図するレビュー活動のアプローチ、リソース、及びスケジュールを記述するドキュメント。特に、レビュー対象のドキュメントとコード、使用するレビューの種類、参加者、公式レビューの場合に適用される開始と終了の基準、それらを選択した理由などが識別される。レビュー計画プロセスの記録である。


review tool (レビューツール)
レビュープロセスを支援するツール。レビューの計画、追跡の支援、コミュニケーションのサポート、協調的なレビューの推進、収集や報告用のメトリクスを保存する機能を備えていることが多い。


reviewer (レビューア)
レビューの中でレビュー対象のプロダクトやプロジェクトの不整合を識別し、指摘する人。レビューアは、レビュープロセスでさまざまな視点や役割を担った人達が選ばれる。


risk (リスク)
将来、否定的な結果を生む要素。通常、影響度と発生可能性として表現する。


risk analysis (リスク分析)
影響度と発生確率(可能性)を見積るために、識別したリスクを評価するプロセス。


risk assessment (リスクアセスメント)
リスクのレベルを決定するために、特定のプロジェクトリスク又はプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。risk&link=1'>product risk, risk&link=1'>project risk, risk, risk impact, risk level, risk likelihoodも参照のこと。


risk category (リスクカテゴリ)
risk typeを参照のこと。


risk control (リスクコントロール)
特定のレベルまでリスクを減らす(あるいは、リスクレベルを維持する)ために、判定を下したり、対策したりするプロセス。


risk identification (リスク識別)
ブレインストーミング、チェックリスト、故障履歴などを使ったリスクを識別するプロセス。


risk impact (リスクの影響)
リスクが実際の結果又は事象となった場合に引き起こされる損害。


risk level (リスクレベル)
影響度合と発生頻度からみた特徴で定義したリスクの重要性。リスクのレベルはテストを行なうときの強弱を決定するときに使われる。リスクレベルはまた、定性的(高/中/低など)又は定量的に表現できる。


risk likelihood (リスク発生確率)
リスクが実際の結果又は事象となりえる推定確率。


risk management (リスクマネジメント)
リスクの識別、分析、優先順位付け、コントロールのタスクに手順や実施方法を体系的に適用すること。


risk mitigation (リスク軽減)
risk controlを参照のこと。


risk type (リスクタイプ)
一つ若しくは複数の共通の要因(品質の属性、発生原因、ロケーション、又はリスクの潜在する影響)で分類されたリスクのセット。リスクタイプを軽減(コントロール)できるテストのタイプと関連付けられる特定のプロダクトリスクのタイプ。たとえば、誤認識のようなユーザの相互作用のリスクは、使用性テストによって軽減することができる。


risk-based testing (リスクベースドテスト)
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。


robustness (頑健性〔堅牢性〕)
不正な入力や過負荷の環境条件の中でも、コンポーネント又はシステムが正しく機能できる度合。[IEEE 610] error tolerance, fault toleranceも参照のこと。


robustness testing (ロバストネステスト)
ソフトウェア製品の頑健性(堅牢性)を判定するテスト。


root cause (根本原因)
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減又は除去される。[CMMI]


root cause analysis (根本原因分析)
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化する事が期待できる。


RUP (RUP)
Rational Unified Processを参照のこと。