用語集

テストツールの導入で得られる利益と、そのためにかかるコストの比較。コストには、ツールの評価・選定や初期トレーニングなど一度だけかかる非経常的なコストと、ライセンス料やメンテナンスなど継続してかかる経常的なコストがある。組織の未熟さによる非効率な使用や、予想を上回るコストなどのリスクも考慮する。

テストプロセス改善のモデル。開始（Initiating）、診断（Diagnosing）、確立（Establishing）、行動（Acting）、学習（Learning）の頭文字。

最も形式的なレビュー。汎用レビュープロセスに完全に従い、不正を最大数発見することが主な目的。作成者はレビューリーダーや書記になれない。

作成者が主導するレビュー。品質評価、レビューアの教育、合意形成、アイデアの創出、不正の検出など多くの目的を持つ。事前の個人レビューは必須ではない。

妥当性確認と、デプロイの準備ができていることの実証に焦点を当てるテストレベル。想定ユーザーが行うのが理想。ユーザー受け入れテスト（UAT）、運用受け入れテスト、契約・規制による受け入れテスト、アルファテスト・ベータテストなどの形式がある。

ユーザーストーリーの実装前に、顧客・開発担当者・テスト担当者などが受け入れ基準からテストケースを作るテストファーストのアプローチ。

起こりうる故障モード（品質リスク）ごとに、その原因と影響を洗い出し、重要度・発生の可能性（優先度）・検出のしやすさを評価する重量的な技法。評価結果をもとに、どのリスクから対策やテストを行うかを決める。

人間が犯す誤り。仕様の読み違えや思い込みなど。エラーが欠陥を生み出す。

過去の故障や、開発担当者が起こしやすいエラーなど、テスト担当者の知識に基づいて欠陥を予測してテストする経験ベースの技法。系統的なやり方としてフォールト攻撃がある。

ある活動を始めるための事前条件。リソースやテストウェアの可用性、テスト対象の初期品質レベル（スモークテストの合格など）がある。アジャイルでは準備完了（Ready）の定義と呼ばれることが多い。

現在のプロジェクトで早い段階から測定したデータをもとに、残りの作業に必要な工数を推定するメトリクスベースの技法。イテレーティブな開発で、過去のイテレーションの実績から次のイテレーションの工数を見積るのが典型例。

元の欠陥が正しく修正されたことを確認するテスト。

カバレッジアイテムのうち、テストで通過した（確認した）ものの割合。パーセンテージで表す。

カバレッジを測るときに数える単位。同値分割法ではパーティション、デシジョンテーブルテストでは実行可能な列、状態遷移テストでは状態や遷移など、技法ごとに異なる。

テスト対象が「何」をすべきかを評価するテスト。機能完全性、機能正確性、機能適切性をチェックする。

順序性のあるパーティションの境界（最小値・最大値）に着目してテストする技法。境界値とその隣を確認する2値BVAと、境界値と両隣を確認する3値BVAがある。

作業成果物（コード、要件仕様書、テストスクリプトなど）の中にある不備。フォールトやバグとも呼ばれる。実行されると故障につながることがある。

報告された欠陥について、修正するか、いつ修正するか、却下するかなどを判断する機能横断的なチーム。テストマネージャー、開発の代表者、プロジェクトマネジメント、プロダクトマネジメント、プロダクトオーナー、サプライヤーなどが参加する。

見つかった不正を記録し、解決に必要な情報を伝える文書。識別子、タイトル、テスト対象と環境、再現手順、期待結果と実際の結果、重要度、優先度、状態などを含む。

欠陥レポートが作成されてからクローズされるまでにたどる状態と、その遷移のルール。シラバスの単純な例では、オープン（新規）、進行中、却下、解決、クローズの状態がある。終端の状態を1つにする、連続する状態を異なる役割に割り当てるといった設計上のよい実践例がある。

指定された要件をシステムが満たしているかを確認すること。「仕様どおりに作られているか」を見る。

作業成果物を構成アイテムとして識別・コントロール・追跡する規律。承認されたものはベースラインとなり、正式な変更コントロールを通じてのみ変更できる。

欠陥が実行された結果、システムがすべきことをしない、またはすべきでないことをしてしまうこと。環境条件（放射線や電磁波など）が原因で起こることもある。

コンポーネントを単独でテストするテストレベル。ユニットテストとも呼ばれ、通常は開発担当者が開発環境で行う。

コンポーネント間のインターフェースと相互処理に焦点を当てるテストレベル。ボトムアップ、トップダウン、ビッグバンなどの統合戦略に大きく依存する。

問題が起きる根底の理由。根本原因分析で特定し、対処することで同様の故障や欠陥の防止や頻度の低減が期待できる。

テストなどのリスク軽減策を行った後にも残っているリスク。リスクベースドテストでは任意の時点の残存リスクレベルを報告でき、テストを延長するか残存リスクを受け入れてリリースするかの判断材料になる。

楽観値 a、最可能値 m、悲観値 b から見積もるエキスパートベースの技法。一般的には E ＝ (a ＋ 4m ＋ b) ÷ 6、標準偏差 SD ＝ (b − a) ÷ 6 で求める。

ステークホルダーの情報ニーズに合ったメトリクスを定義・分析するためのフレームワーク。まず測定のゴールを決め、ゴールの達成度を判断するための質問を立て、質問に答えるためのメトリクスを定める。収集したデータで質問に答え、ゴールをアセスメントする。

システム全体の振る舞いや能力に焦点を当てるテストレベル。エンドツーエンドの機能テストや、品質特性に対する非機能テストを行う。

テスト対象システムと、他のシステムや外部サービスとのインターフェースに焦点を当てるテストレベル。

テストをSDLCのより早い段階で行うアプローチ。仕様書のレビュー、コードを書く前のテストケース作成、CIでの自動テスト、早期の静的解析などが例。後半のテストを軽視するという意味ではない。

欠陥がステークホルダーの利益や要件に与える影響の度合い。

活動の完了を宣言するために達成すべきこと。カバレッジや未解決欠陥の数などの徹底度の測定と、計画したテストの実行などの完了基準がある。アジャイルでは完了（Done）の定義と呼ばれることが多い。

リスクベースドテストのリスク分析技法を、形式の度合いで分けたもの。重量的な技法は定義された手順と詳細な文書を用い、幅広いステークホルダーが関与する（ハザード分析、エクスポージャーコスト、FMEA、フォールトツリー解析など）。軽量的な技法は徹底度も労力も小さく、リスク要因を順序尺度で整理する（PRAM、PRISMA、SST など）。

システムの状態と、イベントによる状態間の遷移をモデル（状態遷移図・状態表）にして、状態や遷移をカバーするテストを導出する技法。全状態カバレッジ、有効遷移カバレッジ、全遷移カバレッジなどの基準がある。

実行可能なステートメントのうち、テストで通過したものの割合。

テスト目的を明確に書くための基準。具体的（Specific）、測定可能（Measurable）、達成可能（Achievable）、妥当（Relevant）、タイムリー（Timely）の頭文字をとったもの。対象・数値目標・期限がはっきりしたテスト目的にすると、達成したかどうかを判断しやすくなる。

ツールを使って、コードなどの作業成果物を実行せずに評価すること。未定義の変数や到達不能コード、コーディング標準からの逸脱などを見つけられる。CIに組み込まれることが多い。

ソフトウェアを実行せずに行うテスト。レビューと静的解析が含まれる。欠陥を直接見つけられる。

チームが発展していく過程を、形成期、混乱期、統一期、機能期、散会期の5つのフェーズで表したモデル。フェーズごとにリーダーに求められるスキルが異なり、たとえば混乱期には対立を解決する能力、機能期には責任を委ねる委任能力が求められる。

リスクベースドテストでのテスト実行順序の決め方の1つ。テストをリスクレベルの高い順に厳密に実行し、最も高いリスクに関するテストをすべて終えてから次のリスクに進む。最も高いリスクをできるだけ早く軽減したい場合に向く。

ユーザーやステークホルダーのニーズを、運用環境でシステムが満たしているかを確認すること。「正しいものを作ったか」を見る。

テスト対象について学びながら、テストの設計・実行・評価を同時に行う経験ベースの技法。セッションベースドテストで体系的に行うことがある。

必要な知識とスキルを持つメンバーなら誰がどの仕事をしてもよく、全員が品質に責任を持つという考え方。エクストリームプログラミングに由来する。

チェックリストのテスト条件をカバーするようにテストを行う経験ベースの技法。チェックリストは欠陥分析に基づいて定期的に更新する。

テストプロセスの成熟度を5つのレベルで表すモデル。各レベルで達成すべきプロセスエリアが決まっており、下のレベルから段階的に改善していく。当初は CMMI を補完するものとして開発された。

16のキーエリアと4つの成熟度レベルでテストプロセスを評価するモデル。チェックポイントを使ってキーエリアごとに成熟度をアセスメントし、結果を成熟度マトリクスで可視化する。キーエリアごとに改善を進められる。

条件の組み合わせと、それに対応する結果（アクション）を表にまとめ、実行可能な組み合わせ（列）ごとにテストする技法。

欠陥を見つけ、ソフトウェアやその作業成果物の品質を評価するための一連の活動。テストの実行だけでなく、計画・分析・設計・実装・完了なども含む。要件どおりかの「検証」と、ニーズを満たすかの「妥当性確認」の両方を行う。

テスト活動で作られる作業成果物の総称。テスト計画書、テスト条件、テストケース、テストデータ、テスト環境、レポートなど。

テストの区切り（テストレベルやイテレーションの完了など）で作成し、評価、計画からの逸脱、未解決のリスク、修正されなかった欠陥、学んだ教訓などをまとめるレポート。

テストを先に書き、テストを満たすコードを書き、テストとコードをリファクタリングする、という流れでコーディングを導く開発手法。

テストの目的、リソース、プロセスを記述した文書。スコープ、前提と制約、ステークホルダー、リスクレジスター、テストアプローチ、予算とスケジュールなどを含む。

テスト設計で、テスト条件を具体化したもの。事前条件・入力・期待結果などを含む。

テスト分析で識別する「何をテストするか」。テスト可能な機能や特性など。受け入れ基準もテスト条件とみなせる。

テスト中に定期的に作成し、進捗状況、支障とその回避策、メトリクス、新たなリスク、次の期間の計画などを伝えるレポート。

テストケースやテストプロシジャーを、まとめて実行するためにグループにしたもの。

テストやその結果に関心を持つ、または影響を受ける人やグループ。開発担当者、プロジェクトマネージャー、プロダクトオーナー、顧客やユーザー、運用チームなどが該当する。テストマネージャーはテストスコープを踏まえたステークホルダー分析で、プロジェクト固有のステークホルダーを識別する。

特定のコンテキストでのテストへのアプローチを記述したもの。組織全体の組織的テスト戦略と、それに沿ったプロジェクトテスト戦略がある。

テストされる作業成果物（コンポーネントやシステムなど）。

特定の品質特性に関連するテスト活動のグループ。FLシラバスでは、機能テスト、非機能テスト、ブラックボックステスト、ホワイトボックステストの4つを扱う。ほとんどはすべてのテストレベルで実行できる。

探索的テストで、テストセッションの目的や重点を示したもの。テスト設計の作業成果物。

テストを「ビジネス指向か技術指向か」と「チームを支援するかプロダクトを批評するか」の2軸で4つに分類したモデル（Brian Marick）。

テストの粒度の違いを層で表したモデル。下の層ほど小さく速いテストを多く、上の層ほど粒度が粗く遅いテストを少なくする。

テストケースを実行する手順をまとめたもの。テスト実装で作成する。

テスト分析やテスト設計のよりどころになる情報。要件仕様書、ユーザーストーリー、設計書、コードなど。

テスト計画、テストモニタリングとコントロール、テスト完了といったテストマネジメント活動に責任を持つ役割。リソースやスケジュールの調整、リスクに基づく判断、ステークホルダーへの報告、テストチームの育成なども担う。アジャイルでは、この役割の一部をチーム全体で分担することもある。

系統的にまとめてマネジメントするテスト活動のグループ。FLシラバスでは、コンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストの5つを扱う。

故障の原因（欠陥）を見つけ、解析し、取り除く活動。典型的には「故障の再現 → 診断 → 修正」の流れで行う。テストとは別の活動である。

同じように処理されると想定される値の集まり（同値パーティション）に分け、各パーティションから代表値を選んでテストする技法。無効パーティションもカバレッジに含める。

ソフトウェアを実行して行うテスト。故障を引き起こし、その分析によって欠陥を特定する。

テストベースの各要素と、テスト条件・テストケース・テスト結果・欠陥などとの対応関係を追えるようにしておくこと。カバレッジの評価や変更の影響の判断に役立つ。

仕事への満足をもたらす要因（動機付け要因）と、不満を防ぐ要因（衛生要因）は別物だとする理論。承認や評価、責任と自律性、やりがいのあるタスク、昇進と成長がモチベーションを上げる要因で、適切な報酬や快適な労働条件、良好な対人関係などは衛生要因にあたる。衛生要因は欠けると不満につながるが、満たしても意欲を高めるわけではない。

各リスクの根底にある危険源（ハザード）を識別し、そこまでさかのぼって分析する重量的な技法。リスクそのものだけでなく、その上流にある発生源を明らかにすることで分析を広げる。

システムが「どのようにうまく振る舞うか」を評価するテスト。性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性などの品質特性を対象とする。

過去のプロジェクトで得られた比率（たとえば開発工数とテスト工数の比）を使って、今回のテスト工数を見積るメトリクスベースの技法。組織内に信頼できる過去データがあることが前提になる。

品質に関連する労力と欠陥の総コスト。TMシラバスでは、欠陥予防コスト、評価（アプレイザル）コスト、内部失敗コスト、外部失敗コストの4つに分類する（Feigenbaum のアプローチ）。

適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチ。テストはその主要な形式である。

プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチ。プロジェクトに参加するすべての人が責任を持つ。

潜在的な故障を起点に、それを引き起こす欠陥、さらにその欠陥を生むエラーへと関連付けをたどり、根本原因が識別できるまで木構造で掘り下げる重量的な技法。トップダウンで原因を分析する。

期待と異なる事象。報告された不正は、調べると本当の欠陥のこともあれば、偽陽性や変更要求などのこともある。

テスト対象の内部構造を参照せず、仕様上の振る舞いの分析に基づいてテストを導出する技法。仕様ベース技法とも呼ばれる。

制御フローのブランチ（無条件・条件付きの制御の遷移）のうち、テストで通過したものの割合。ブランチカバレッジ100%はステートメントカバレッジ100%を包含する。

ワイドバンドデルファイの変形で、チームメンバーが数値の書かれたカードを同時に出して見積る技法。値が大きく分かれたら、最大値と最小値を出した人が理由を説明し、再び見積る。アジャイル開発でユーザーストーリーの見積りによく使われる。

チームが自分たちのやり方をレビューし、教訓を把握して改善のアクションを決めるミーティング。イントロダクション、データの収集、改善策の導出、改善アクションの決定、クロージングの流れで行う。

望ましい振る舞いを、ステークホルダーが理解しやすい自然言語（通常 Given/When/Then 形式）で表したテストケースで開発を導く手法。テストケースは実行可能なテストへ自動的に変換する。

プロジェクトのマネジメントや統制に関するリスク。組織・人・技術・サプライヤーの問題などで、スケジュールや予算、スコープに影響する。

プロダクトの品質特性に関するリスク。機能の不足や誤り、応答時間の不足、セキュリティの脆弱性など。品質リスクとも呼ばれる。

自分たちのプロジェクトやチームのデータを分析して問題を識別し、改善策を導くアプローチ。根本原因分析、尺度・メトリクス・指標を用いた分析、GQM アプローチなどがある。モデルベースのアプローチと組み合わせて使うこともできる。

Meredith Belbin による、チーム内で人が自然にとりやすい役割の分類。異なる性格や役割のタイプの人が組み合わさることで、チームが効果的に機能するという考え方に立つ。チームに既にあるスキルと不足しているスキルを識別するのに役立つ。

テスト対象の内部構造や処理の分析に基づいてテストを導出する技法。構造ベース技法とも呼ばれる。

稼働中のシステムへの変更に対して行うテスト。きっかけには、変更（計画された機能拡張、是正のための変更、ホットフィックスなど）、運用環境の更新・移行、廃棄がある。

業界で認められた参照モデルと自組織のテストプロセスを比較し、その差分から改善点を見つけるアプローチ。外部の良い実践例を基準にする点が特徴で、代表例として TMMi と TPI NEXT がある。

欠陥を修正する順番・急ぎ具合。

リスクベースドテストでのテスト実行順序の決め方の1つ。まず識別したすべてのリスクに少なくとも1つずつテストを割り当てて先に実行し、その後で残りのテストをリスクレベルの高い順に実行する。プロダクト品質の全体像を早く把握したい場合に向く。

変更（欠陥の修正を含む）によって、変更していない部分や接続する他システムなどに悪影響が出ていないことを確認するテスト。繰り返し実行するため、自動化の有力な候補になる。

顕在化すると悪影響が生じる、潜在的な事象・ハザード・脅威・状況。リスクの可能性とリスクの影響の2つで特徴づけられる。

リスク分析とリスクコントロールに基づいて、テスト活動を選択し、優先順位を付け、マネジメントするテストアプローチ。リスクレベルが高いほど早く、厳密に、多くの労力でテストする。

リスクの可能性とリスクの影響から決まるリスクの大きさ。定量的には両者の積で、定性的にはリスクマトリクスで決める。

さまざまな立場のステークホルダーが集まり、品質リスクを洗い出して議論する場。専門家インタビュー、ブレーンストーミング、チェックリスト、過去の経験の参照などと並ぶ、品質リスクの識別技法の1つ。参加者の幅が広いほど重大なリスクの見落としが減る。

人が作業成果物を読んで評価する静的テスト。形式の度合いにより、非形式的レビュー、ウォークスルー、テクニカルレビュー、インスペクションなどの種別がある。

専門家がそれぞれ個別に見積り、結果を持ち寄って差異の理由を議論し、再び見積る、という手順を合意に近づくまで繰り返すエキスパートベースの技法。個人の偏りを抑えつつ、複数の専門家の知見を見積りに反映できる。