JSTQB【FL】用語まとめ

各数字は、シラバスの章を示しています。

追記：無事合格しました

ブランチテスト３

分岐（if/switch）の「分かれ道」をすべて通ることを目的としたテスト

真（true）と偽（false）を両方とも実行する

目的

- 分岐ロジックが正しく動作するか確認する
- 条件によって処理が抜け落ちるリスクを減らす

ブランチカバレッジ３

プログラム中の分岐（ブランチ）が、どの程度テストで実行されたかを示す指標

ホワイトボックステストにおけるカバレッジ指標

if や switch などの分岐について
**「すべての分かれ道を通ったか？」**を数値で表したもの

テストレベル２

ソフトウェア開発の段階やテスト対象の粒度ごとに分けて行うテストの区分

異なる開発レベルで、異なる目的を持って実施されるテスト

構成管理５

ソフトウェアやテストに関する成果物を、識別・管理し、変更を統制する活動

テストを支援する重要な管理活動

どの版（バージョン）の何を使ってテストしたのかを、正しく管理すること

インスペクション３

定義された手順と役割に基づいて、作業成果物の欠陥の識別、およびレビュープロセスとソフトウェア開発プロセスの改善をする

同値パーティション４

入力や出力のデータを、システムが同じように扱うと予想されるグループに分割するブラックボックステスト技法

基本的な考え方: **「同じパーティション内の値であれば、どれか1つをテストすれば、そのグループの他の値についても同様の結果が得られる」**と仮定する。

目的: すべてのパーティションから少なくとも1つの値をテストすることで、テストの重複を避けつつ、効率的に網羅性を高める。

同値分割法（EP）４

カバレッジ100％のために、識別されたすべてのパーティション（無効パーティションを含む）を、少なくとも 1 回はカバーするように通過しなければならない。

カバレッジ計算

1 つのテストケースによって通したパーティションの数 /
識別されたパーティションの総数

2値BVA４

カバレッジ100％のために、テストケースですべてのカバレッジアイテム、つまり識別したすべての境界値を通過しなければならない。

カバレッジ計算

通した境界値の数 /
識別した境界値の総数

3値BVA４

カバレッジ100％のために、テストケースですべてのカバレッジアイテム（つまり、識別された境界値とその隣接値）を通過しなければならない。

カバレッジ計算

通した境界値とその隣接値の数 /
識別した境界値とその隣接値の合計数

デシジョンテーブルテスト４

カバレッジ100％のために、これらの列をすべて通過する必要がある。

カバレッジ計算

通した列の数 /
実行可能な列の総数

全状態カバレッジ４

カバレッジ100％のために、すべての状態を通過することを保証しなければならない。

カバレッジ計算

通過した状態の数 /
状態の総数

有効遷移カバレッジ４

カバレッジ100％のために、すべての有効な遷移を通さなければならない。

カバレッジ計算

通した有効な遷移の数 /
有効な遷移の総数

全遷移カバレッジ４

カバレッジ100％のために、すべての有効な遷移を通過し、無効な遷移の実行を試みなければならない。

カバレッジ計算

通した有効および無効な遷移の数、または実行したテストケースでカバーを試みた有効および無効な遷移の数 /
有効および無効な遷移の総数

ステートメントカバレッジ４

ステートメントカバレッジが 100%になると、コード内のすべての実行可能なステートメントを少なくとも一度は通過したことになる。

カバレッジ計算

テストにより通過したステートメント数 /
コードの実行可能ステートメントの総数

ブランチカバレッジ４

ブランチカバレッジが 100%になると、コード内のすべてのブランチ（無条件および条件付き）をテストケースで通すことになる。

カバレッジ計算

テストケースによって通したブランチの数 /
ブランチの総数

リリース計画５

• プロダクトバックログの定義と再定義
• 大きなユーザストーリーを一連の小さなユーザーストーリーへと洗練
• テストアプローチとテスト計画書のベース
• テスト可能なユーザーストーリーと受け入れ基準の作成
• プロジェクトと品質のリスク分析
• ユーザーストーリーに関連するテスト工数を見積もる
• テストアプローチの決定
• リリースのためのテストを計画

イテレーション計画５

• イテレーションバックログを考慮
• ユーザーストーリーの詳細なリスク分析に参加
• ユーザーストーリーの試験性を判断
• ユーザーストーリーをタスク（特にテストタスク）に分解
• すべてのテストタスクのテスト工数を見積もる
• テスト対象の機能的側面と非機能的側面を識別し洗練

見積り技法５

比率に基づく見積り

• 類似プロジェクトの**「標準」**比率を導き出すことが可能
• 組織内のプロジェクトの比率（過去データ）は、見積りプロセスで使用するよいソース
• 標準的な比率は、新規プロジェクトのテスト工数を見積もるために使用

例：前回プロジェクトの開発工数とテスト工数の比率が３：２
　　今回プロジェクトの開発工数６００人日

　　今回プロジェクトのテスト工数は...４００人日

計算方法

３：２＝６００：？
６００/３＝２００
２＊２００＝４００
？＝４００

外挿

• 測定は、データを収集するために、現在のプロジェクトのできるだけ早い時期に行う
• 残りの作業に必要な工数は、このデータを外挿することで概算できる（数学モデルを適用）
• イテレーティブなSDLCに適している

例：次のイテレーションにおけるテスト工数を、過去３回のイテレーションから平均した工数として外挿できる

イテレーション	テスト工数
１回目	１０人日
２回目	１２人日
３回目	１１人日
平均	(10+12+11)/3
今回	１１人日

ワイドバンドデルファイ

• 専門家が経験に基づいて推定する
• 各専門家は、単独で、労力を見積もる
• 結果を収集し、合意した境界線から外れた偏差がある場合、専門家は見積りについて議論
• そのフィードバックに基づき、再び単独で新たな見積りを行う
• このプロセスは、コンセンサスが得られるまで繰り返される

プランニングポーカー:アジャイルソフトウェア開発でよく使われるワイドバンドデルファイのバリエーションの１つ。
労力のサイズを表す数字が書かれたカードを使って見積りする。

三点見積り

三点見積り

最終的な推定値の計算

計算式

最終的な推定値(E) = 
(最も楽観的な推定値(a) + 4 * 最も可能性の高い推定値(m) + 最も悲観的な推定値(b)) / 6

例

a = 10
m = 13
b = 22

(10 + 4 * 13 + 22) / 6

E = 14

測定誤差の計算

計算式

誤差(SD) =
(最も悲観的な推定値(b) - 最も楽観的な推定値(a)) / 6

例

a = 10
b = 22

(22 - 10) / 6

SD = 2

最終的な推定値 = 14
誤差 = 2
最終見積り = 14 ± 2 (12 ~ 16)

テストの四象限５

	指向	支援	テスト	自動or手動
第一象限	テクノロジー	チーム	コンポーネントテスト コンポーネント統合テスト	自動
第二象限	ビジネス	チーム	機能テスト、実例、ユーザーストーリーテスト、 ユーザーエクスペリエンスプロトタイプ、APIテスト、シミュレーション	自動、手動	受け入れ基準をチェック
第三象限	ビジネス	プロダクト	探索的テスト、使用性テスト、 ユーザー受け入れテスト	手動	ユーザー志向
第四象限	テクノロジー	プロダクト	スモークテスト、非機能テスト（使用性テストを除く）	自動

プロダクトリスク分析５

テストレベル２

• テストレベルは、系統的にまとめ、マネジメントしていくテスト活動のグループ
• あるレベルの終了基準が次のレベルの開始基準の一部であるように定義される
• 開発活動は、複数のテストレベルにまたがることがある
• テストレベルは、時間的に重なることがある

コンポーネントテスト（ユニットテスト）

• コンポーネントを単独でテスト
• テストハーネス、またはユニットテストフレームワークのような特定のサポートを必要
• 開発担当者が開発環境で行う

中身（コード・ロジック）が正しいか

コンポーネント統合テスト（ユニット統合テスト）

• コンポーネント間のインターフェース、および相互処理に焦点を当てる
• ボトムアップ、トップダウン、ビッグバンといった統合戦略のアプローチに依存

隣同士の繋ぎ目（インターフェース）が正しいか

システムテスト

• システムやプロダクト全体の振る舞いや能力全般に焦点を当てる
• 本番相当のテスト環境において、すべて揃ったシステムでテストすることが望ましい（使用性テスト）
• サブシステムのシミュレーションを使用することも可能
• システムの仕様に関するものであり、独立したテストチームによって実施

システム全体の機能・非機能特性が仕様通りか

システム統合テスト

• テスト対象システムと他のシステム、外部サービスとのインターフェースに焦点を当てる
• できれば運用環境に近い適切なテスト環境が必要

システム全体のつながり（システム間データフロー）が正しいか

受け入れテスト

• 妥当性確認と、デプロイの準備ができていることの実証に焦点を当てる
• システムがユーザーのビジネスニーズを満たしていることを意味する
• 想定ユーザーによって実施することが理想的

主な形式

• ユーザー受け入れテスト（UAT）
• 運用受け入れテスト
• 契約
• 規制による受け入れテスト
• アルファテスト
• ベータテスト

ユーザーのニーズ・ビジネス要件を満たし、リリース可能か

テスト活動の重複を避けるための区別方法

• テスト対象
• テスト目的
• テストベース
• 欠陥、および故障
• アプローチと責務

テストレベル	主な焦点・目的	テスト対象	実施環境	実施者・特徴
コンポーネントテスト （ユニットテスト）	コンポーネント単体の正しさ	単一コンポーネント	開発環境	開発担当者が実施。テストハーネスやユニットテストフレームワークが必要
コンポーネント統合テスト （ユニット統合テスト）	コンポーネント間のインターフェース・相互処理	複数コンポーネント	開発〜テスト環境	ボトムアップ／トップダウン／ビッグバンなどの統合戦略に依存
システムテスト	システム全体の振る舞い・能力	システム／プロダクト全体	本番相当のテスト環境が望ましい	独立したテストチームが実施。使用性テストを含むことが多い
システム統合テスト	他システム・外部サービスとのインターフェース	対象システム＋外部システム	運用環境に近いテスト環境	システム間連携が主眼
受け入れテスト	ビジネスニーズの充足確認・リリース可否判断	完成したシステム	本番に近い環境	想定ユーザーが実施するのが理想。UAT、運用、契約、規制、α/βテストなどがある

テストタイプ２

• 特定の品質特性に関するテスト活動のグループ
• テストタイプは、すべてのテストレベルで実行する

機能テスト

• コンポーネント、およびシステムが実行する機能を評価
• 機能とはテスト対象が「何」をすべきか

主な目的

• 機能完全性
• 機能正確性
• 機能適切性

非機能テスト

• コンポーネント、およびシステムが実行する機能特性以外の属性を評価
• システムが、「どのように振る舞うか」をテスト
• 目的は、非機能的なソフトウェアの品質特性をチェック
• ライフサイクルの早期（レビュー、コンポーネントテスト、システムテストの一部）に開始

非機能ソフトウェア品質特性の分類

• 性能効率性
• 互換性
• 使用性
• 信頼性
• セキュリティ
• 保守性
• 移植性

ブラックボックステスト

• 仕様に基づき、テスト対象の外観を示すドキュメントから導出
• 目的は、システムの動作を仕様に照らしてチェック

ホワイトボックステスト

• 構造に基づき、システムの実装または内部構造からテストを導き出す
• 目的は、テストによって基本的な構造を受け入れ可能なレベルまでカバーする

レビュー種別３

レビュー種別の選択が基づく要素：目的、プロジェクトのニーズ、使用可能なリソース、作業成果物の種類とリスク、ビジネスドメイン、企業文化

非形式的レビュー

• 定義されたプロセスに従わない
• 正式に文書化されたアウトプットを必要としない
• 主な目的は、不正の検出

ウォークスルー

• 作成者が主導
• 品質評価や作業成果物に対する信頼の積み上げ
• レビューアの教育
• 合意形成
• 新しいアイデアの創出
• 作成者のモチベーションの向上と改善
• 不正の検出
• レビューアはウォークスルーの前に個人のレビューをしてもよい（必須ではない）

テクニカルレビュー

• 技術的に的確なレビューアによって行われる
• モデレーターが主導
• 技術的な問題に関して合意を得て判断する
• 不正の検出
• 品質評価や作業成果物に対する信頼の積み上げ
• 新しいアイデアの創出
• 作成者のモチベーションの向上と改善

インスペクション

• 最も形式的なレビュー
• 汎用プロセスに完全に従う
• 不正を最大数発見
• 品質評価や作業成果物に対する信頼の積み上げ
• 作成者のモチベーションの向上と改善
• メトリクスを収集
• インスペクションプロセスを含む、SDLCを改善
• 作成者はレビューリーダーや書記として活動できない

チェックリストベースドテスト４

リストに含める項目

• 経験に基づく項目
• ユーザーにとって重要な項目
• ソフトウェアが不合格になる仕組み

リストに含めない項目

• 一般的すぎる項目
• 開始基準と終了基準
• 自動的にチェックできる項目

テストレポート５

テスト進捗レポート

• テスト期間
• テストの進捗状況（テストスケジュールの前倒し、遅れ）、顕著な逸脱
• テストに支障をきたすもの、およびその回避策
• テストメトリクス
• テスト期間中に新たに発生したリスクと変更されたリスク
• 次の期間で計画しているテスト

テスト完了レポート

• テスト概要
• 当初のテスト計画書に基づくテストとプロダクト品質の評価（テスト目的と終了基準）
• テスト計画書からの逸脱（テストスケジュール、期間、労力などの計画との差異）
• テストの阻害要因および回避策
• テスト進捗レポートに基づくテストメトリクス
• 未解決のリスク、修正されなかった欠陥
• テストに関連する学習した教訓