テスト分析入門 井芹 洋輝 2025/5/26 @CADDi様 

自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアと様々な立場で 様々なプロダクトのソフトウェアテスト活動に従事 • 現在は車メーカーでQA/テストテックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラス初代審査委員長 ⚫著作・講演 • 「ソフトウェアテスト徹底指南書」（2025年6月発売予定） 「テスト自動化の成功を支えるチームと仕組み」 「シフトレフトテストを支える現代的なテスト設計」 「システムテスト自動化標準ガイド」（共訳）など 

この講演について ⚫テスト分析について解説します • ステップバイステップで具体例を交えながら解説します • 用語はJSTQBに従います ⚫アウトライン 1. テスト分析とは 2. テスト分析の進め方 • スクラムでの具体例を交えながら解説 

テスト分析とは 

テストプロセスの中でのテスト分析 1. テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、網羅基準を設定する • テスト条件： テスト可能なテスト対象の要素。機能や品質特性、構造要素など 2. テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース： 実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット 3. テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃える テストケースを実行可能なテスト手順に具体化する 

テストプロセスの具体例：題材仕様 ⚫ポット給湯機能が対象。 入力：ロック解除ボタン、給湯ボタン。出力：給湯 • 最初は給湯ロック状態。ロック解除ボタンを1秒長押しすると、ロック解除状 態に遷移する • ロック解除状態で、何もボタンを押さずに3秒経過すると、給湯ロック状態 に遷移する • ロック解除状態で、給湯ボタンを押下すると、ボタンを押下している間だけ、 給湯を行う 青背景スライド＝具体例の解説 

テストプロセスの具体例：テスト分析 テスト網羅基準：1スイッチカバレッジ100%、全遷移カバレッジ100% 

テストプロセスの具体例：テスト設計 事前条件 操作 期待結果 給湯ロック状態 ロック解除ボタンを1秒長押し ボタン無操作で3秒経過 給湯ロック状態 給湯ロック状態 ロック解除ボタンを1秒長押し 給湯ボタン押下開始 給湯状態 ロック解除状態 給湯ボタン押下開始 給湯ボタン押下終了 ロック解除状態 ロック解除状態 ボタン無操作で3秒経過 ロック解除ボタンを1秒長押し ロック解除状態 給湯状態 給湯ボタン押下終了 ロック解除ボタンを1秒長押し 給湯ロック状態 給湯状態 給湯ボタン押下終了 給湯ボタン押下開始 給湯状態 

テストプロセスの具体例：テスト実装 事前条件 実行手順 期待結果 貯水状態 電源投入直後 (1)ロック解除ボタンを1秒長押し (2)ボタン無操作で3秒待つ (3)給湯ボタン押下 給湯されないこと 給湯可能ランプ消灯 （前手順から続行） (1)ロック解除ボタンを1秒長押し (2)3秒以内に給湯ボタン押下 給湯されること 給湯可能ランプ点灯 貯水状態 電源投入直後 (1)ロック解除ボタンを1秒長押し (2)3秒以内に給湯ボタン押下し離す (3)3秒以内に給湯ボタン押下 2回給湯されること 給湯可能ランプ点灯 … 

なぜテスト分析が必要か ⚫事前に「何をテストすべきか」を分析・整理することで、テストの漏れ・ 冗長性を予防し、適切に・効率的にテスト設計できるようにする • テストの責務を分析することで、テストの漏れや冗長性を削減する • テスト条件をうまく分析して： • 複雑なテストもテスト設計可能にする • テストすべきテスト条件を見逃さないようにする • 妥当なテスト網羅基準を設定できるようにする ⚫テストベース（テスト分析・設計の情報源全般）の分析・改善に事前 に注力することで、シフトレフトを促進し、開発のスピードと品質に貢 献する 

テスト分析とテスト設計技法の関係 ⚫テスト分析：「何をテストするか」の具体化 • テスト条件を分析する。テスト条件を優先付けし、網羅基準を設定する • テスト条件： テスト可能なテスト対象の要素。機能や品質特性、構造要素など ⚫テスト設計：「どのようにテストするか」の具体化 • テストケースを設計する • テストケース： 実行の事前条件、アクションと入力、期待結果、実行の事後条件のセット ⚫テスト実装：テスト実行の準備 • テスト実行に必要なテストウェアを揃える テストケースを実行可能なテスト手順に具体化する 多くのテスト設計技法は、 テスト分析の一部とテスト設計をサポートする 

テスト分析の進め方 

テスト分析の進め方 1. テストベースを識別・確保する 2. テストベースを整理・理解する 3. テストの責務を具体化する 4. テスト対象を項目分けする 5. テストタイプを分析する 6. プロダクトリスクを分析し対応方針をたてる 7. テスト条件を分析する 8. テスト条件の優先付け・重みづけを行う。テスト網羅基準を設定する ※活動を通してテストベースの改善点（抜け・誤り・矛盾など）を見つけ、 改善を働きかける 

1. テストベースを識別・確保する ⚫テスト分析・設計活動に必要なインプットを確保する • テストベース（テストの入力情報）を提供するステークホルダを識別する • テストベースを識別し確保する ⚫留意点 • あるべき姿を分析し、その実現を働きかける • あるべきステークホルダ、テストベースを分析し、その確保を働きかける • 受動的な立ち回りはテスト失敗のリスクを高める • 確保の段取りを組む（先行版・暫定版を早期確保、Q&Aで情報補足など） • 通常は計画・プロセス設計段階で実施。計画・プロセスに手筈を組み込む。 テスト分析ではそのフォローを行う 

【例】1. テストベースを識別・確保する テストベース 提供者 タイミング テスト活動における用途 リリース計画 PjM リリース計画時 テストのスコープ・目的・十分性基準の検討情報 ユーザストーリー スクラムチーム PO 初期：PB作成時 詳細定義：スプリントプランニング時 主なテスト対象の仕様 ユーザストーリーマップ スクラムチーム PO 初期：リリース計画時 詳細定義：PB作成時 ユーザーストーリの補完情報。 テストの優先付け・網羅基準の検討情報 受け入れ基準 スクラムチーム スプリント中 ユーザーストーリーを補完するテストのスコープ、テスト条件、 補足仕様 DoD スクラムチーム リリース計画時 テストの十分性基準の検討情報 UI仕様 UIチーム スプリント中に更新 詳細な画面設計、意匠、アニメーション仕様 アーキテクチャ仕様 アーキチーム スプリント中に更新 詳細なデータ仕様、バッグエンド仕様、UI以外の外部イン ターフェース定義、横断的な非機能仕様 Q＆Aコメント スクラムチーム PO 逐次 テスト担当者からの疑問点・指摘に対する回答 ・・・ 

2. テストベースを整理・理解する ⚫入手したテストベースを整理し理解する ⚫テストベースの不足を確認し、問題があれば対策を取る ⚫テストベースの欠陥（抜け漏れ、誤り、その他改善点）を見つけ、その 是正を働きかける ⚫留意点 • テストベース作成時点で実施するのが理想。 レビューに参加して、理解と問題是正をサポートする • 例）Wモデル：テストベース作成とテスト分析・設計を並行して行う 

【例】2. テストベースを整理・理解する ユーザーストーリ：検索履歴の呼び出し 「システム利用者として、過去の検索 履歴の一覧を表示し、履歴の検索構 文を選択して再実行できる。それによ り、以前検索した内容をすばやく実行 できるようにする」 表示履歴数の最小値・最大値を確認し、 受け入れ基準に明記する (1)テストベースの内容をレビュー・理解する (2)問題の検出&改善、分析準備を行う 詳細なUI仕様を確保する 「検索履歴の削除」「検索履歴のセキュリ ティ」など、関連するユーザーストーリや仕様 の存在を確認する。 不足する仕様があればユーザーストーリの 発行など改善を促す 

3. テストの責務を具体化する ⚫何をテストするか全体像を具体化する • テスト対象 • 構造・機能で整理。外部サービスや未完成部分なども考慮 • テストのスコープ • テスト分担の境界の明確化。制約やリスク・課題に応じたテストスコープの調整 • 定番の考慮点：他のテストの分担、外部のサービスやコンポーネント（例：FLOSS） • テストの目的と十分性基準 • 何のためにどこまでテストすべきかの目安 • 特別に対応すべき重大なリスク・課題 ⚫留意点 • 方針レベルでは計画時に具体化しすり合わせする テスト分析では、目の前のテスト活動にフォーカスを当て、詳細度を高める • 責務が大きすぎる場合は事前に責務分担を工夫する（例：自動テスト充実など） 

【例】3. テストの責務を具体化する ・リリーススプリントはない。スプリン トでDoDを満たしたらインクリメント をユーザにリリースする ・担当のユーザーストーリーテストが リリース直前のテストである テストのコンテキスト ●テスト対象とスコープ ・依存外部サービス含めた、プロダクトサービ ス総体を対象にする ・スプリント中の変更および変更の影響範囲 についてテストする ●テストの目的と十分性基準 インクリメントがリリースできる品質であること を確認する。変更のプロダクトリスクがリリー スできるレベルであることを確認する 分析するテストの責務 

4. （必要に応じて）テスト対象を項目分けする ⚫テスト対象を項目分けし、関心の分離を実施する • 項目分けしたものは仕様項目やテスト条件と呼ばれる • テストベースが項目分けされていればそれを流用できる • 例）ユーザーストーリで項目分けできていれば、それをテスト分析で流用する ただしテストの目線で項目不足や、凝集性・結合性の問題があれば改善する ⚫留意点 • テストベースの項目分けが不適切な場合、まずテストベースの改善を働きか ける。テストベースの二重化（開発が作成したテストベースと、テスト用に書 き換えたテストベースが共存）は、偽陰性・偽陽性のリスクになるほか、保守 の手間も増えるため基本避ける 

4. テスト対象を項目分けする【補足】 ⚫テスト視点での、仕様としての凝集性の高さと結合性の低さを確保 するように、項目分けする • 高い凝集性：意味のある分け方をしている • 仕様項目が、密接に関連したテスト要求に集中しているかの程度 • ひとまとまりにテスト設計を進められる。関連性の低いテスト要求が混在していない • 低い結合性：以降のテスト活動を分けて進められる • 仕様項目間の依存関係が少ない • 分けて別々にテスト設計・テスト実装作業を進められる 

【例】4. テスト対象を項目分けする ユーザーストーリー リスクマネジメント情報、アーキテク チャ仕様などユーザーストーリー以 外のテストベース ・項目分けにユーザーストーリー単位をそのま ま採用する ユーザーストーリー作成から参加し、ユー ザーストーリーの高凝集性・低結合性確保を 初期から働きかける ・項目の漏れが残った場合は、テストタスクと して追加発行する テストベース ・各ドキュメントの項目分けに従う 項目分けができていないテストベースにつ いては、テスト用に仕様項目一覧を作り、ト レーサビリティを取る 

5. テストタイプを分析する ⚫採用するテストタイプを分析する • テストタイプ： 品質特性など、テストで着目する特性に紐づいたテストの種類。 セキュリティテスト、ユーザビリティテスト、ストレステストなど • テストタイプも高凝集性・低結合性を確保するように分析する • 高凝集性：特定の特性に特化したテストタイプになっている • 低結合性：テストタイプ間の依存性が少ない。独立してテストの作成・実行を進められる ⚫仕様項目がどのテストタイプに紐づくかを分析する • 仕様項目×テストタイプで関心の分離を実施する ⚫留意点 • チームレベルのテストタイプはテスト計画・テストアーキテクチャ設計で実施。 テスト分析はそこから選択する 

【例】5. テストタイプを分析する ⚫採用するテストタイプを選択し、各仕様項目をどのテストタイプでテス トするか検討・明示化する ユーザーストーリー テスト ユーザビリティテスト セキュリティテスト ・・・ 検索履歴保存・ 削除の追加 ● ● 検索履歴の表 示・削除・選択 UI追加 ● ● ● 検索履歴の実行 ● 

小休止：質問タイム 1. テストベースを識別・確保する 2. テストベースを整理・理解する 3. テストの責務を具体化する 4. テスト対象を項目分けする 5. テストタイプを分析する 6. プロダクトリスクを分析し対応方針をたてる 7. テスト条件を分析する 8. テスト条件の優先付け・重みづけを行う。テスト網羅基準を設定する ※活動を通してテストベースの改善点（抜け・誤り・矛盾など）を見つけ、 改善を働きかける 

6. プロダクトリスクを分析し対応方針をたてる ⚫テスト設計対象について、プロダクトリスク（あるいは想定される欠 陥）、テストの制約・課題を分析し、テストでの対策を検討する • プロダクトリスク： プロダクトの品質に影響をもたらす可能性のある事象や要因。その影響度 と発生可能性の組み合わせで程度を示す ⚫重大なリスクや制約・課題があれば、対策としてテストアプローチを 策定し運用する ⚫留意点 • 主要なプロダクトリスク分析はチームレベルで実施。 テスト分析では、そこから分析結果をピックアップする。さらにテスト対象作 業についての補強の分析を行う 

6. プロダクトリスクを分析し対応方針をたてる【補足】 ⚫プロダクトリスクの分析アプローチ • 要素に分解し、要素ごとにリスク事象を分析する • 代表手法：FMEA • 仕様項目や、テスト対象の構成要素ごとに実施する • 回避したいリスク事象や危害を識別し、その発生要因を分析する • 代表手法：FTA • 蓄積された知識・経験や、その集合知でリスクを分析する • 代表手法：リスクストーミング ⚫テストでのプロダクトリスクへの対策 • プロダクトリスクのリスクレベルが一定以下であることを確認する（発生頻度 を確認する） 

【例】6. プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加 変更影響マトリクスから、追加に伴う気がかりやリスクを分析する アカウント管理 セッション管理 UIフロントエンド ユーザ管理 バックエンド ・・・ 検索履歴保存・ 削除の追加 保存履歴の外部漏洩 未ログイン状態での履歴 表示 履歴のオーバーフロー 重複管理 履歴データの移行、バッ クアップ異常 検索履歴の表示・ 削除・選択UI追加 履歴の誤削除 ポップアップUIとの競合 検索履歴の実行 影響を受ける可能性のある構成要素 変更点 変化点 

【例】6. プロダクトリスクを分析し対応方針をたてる ⚫【対象】検索履歴機能の追加 要対応リスクに対し、リスクベースドテストとしてテストを用意する。 あるいはテストの厚みや網羅基準の調整に用いる リスク事象 リスクに対するアプローチ 検索履歴データがユーザデータ操作と連動し て処理されない。例えばユーザのコピーで履歴 がコピーされない ユーザデータの追加、移植、コピー、削除時に検索履歴 が連動して処理されること受け入れ基準に追記し、ユー ザーテストで確認 未ログイン状態で特定ユーザの検索履歴が表 示される 検索履歴に対するセッション管理のセキュリティ監査・テ ストを実施 リスクコントロールとして対策アプローチを策定 

7. テスト条件を分析する ⚫仕様項目ごとにテスト設計が可能な詳細度のテスト条件（カバレッジ アイテム）を分析する • 本質的なテストモデルを見出し、テストモデルからテスト条件を分析する 仕様項目 IF抽象仕様 機能抽象モデル 非機能抽象モデル ・・・ 分析のための抽象モデル テスト設計アプローチに紐づくテストモデル 状態遷移 デシジョンテーブル クラシフィケーションツ リー ・・・ 詳細なテスト条件 ここでテスト設計技法活用可能 

7. テスト条件を分析する： 機能抽象モデルを使った抽象レベルのテスト条件分析 入力 処理 間接 入力 状態 間接 出力 基盤 テスト対象の入力（インプット とアクション）を観点にテスト 条件を分析する 【テストモデル候補例】パラ メータ・値、組み合わせ、シー ケンス、境界、外乱、・・・ 機能内の静的・動的な状態を観 点にテスト条件を分析する 【テストモデル候補例】 状態遷移、データフロー、・・・ 全体の管理・調停・横断機能を観点にテ スト条件を分析する 【テストモデル候補例】シーケンス、・・・ テスト対象の出力（アウトプットと アクション）を観点にテスト条件 を分析する 【テストモデル候補例】パラメー タ・値、シーケンス、境界、・・・ 出力 入力から出力を得る処理を観点 にテスト条件を分析する 【テストモデル候補例】 デシジョンテーブル、・・・ 

7. テスト条件を分析する： 抽象モデルを使ったテスト条件分析 ⚫分析の切り口にする抽象モデルはアーキテクチャをベースにする • 個々の分析の補強として、仕様項目のタイプに応じた抽象モデルを使用す る（例えば機能の仕様項目なら、前ページの機能抽象モデルを使用する） ⚫テスト設計技法に基づいたテストモデルで、より詳細なテスト条件を 分析する ⚫多様なテストモデルを習得することで、より難しいテスト分析ができる ようになる 

基盤 【例】7. テスト条件を分析する 機能抽象モデルで抽象テスト条件を出す ⚫「検索履歴保存」の機能テストのテスト条件 入力 処理 間接 入力 状態 間接 出力 出力 ・検索構文（境界、文字種） ・異常操作（エラー推測） ・保存検索履歴（状態遷移） ・ログインユーザ（状態遷移） ・重複排除処理（エラー推測） ・FIFO処理（境界、フロー） 他でテスト： ・検索構文チェック ・セッション管理、ログイン管理（状態遷移） ・保存検索履歴（境界） 

【例】7. テスト条件を分析する 抽象テスト条件ごとに詳細テスト条件（カバレッジアイテム）を分析する ⚫ログインユーザ（状態） ⚫異常操作（エラー推測） • 同時・連続入力 • 異なるユーザからの同時入力 • ・・・ 未ログイン ログイン ログイン ログアウト ユーザ切り替え 

8. テスト条件の優先付けを行う。テスト網羅基準を設定する ⚫テストモデルに応じたテスト網羅基準を設定する • テスト設計技法を活用できる。ただし技法ありき・網羅ありきではなく、リスク や重要度に合わせてテストすべきテスト条件を分析・ピックアップする テストモデル テスト網羅基準の例 パラメータ・値、同値分割 同値パーティションカバレッジ 境界 2値境界値カバレッジ、3値境界値カバレッジ 状態遷移 全状態カバレッジ、有効遷移カバレッジ、全遷移カバレッジ、nスイッチカバ レッジ 有則のパラメータ・値の組み合わせ デシジョンテーブルの簡単化程度 無則のパラメータ・値の組み合わせ nワイズカバレッジ 制御フロー、シーケンス ステートメントカバレッジ、ループカバレッジ 

8. テスト条件の優先付けを行う。テスト網羅基準を設定する 技法による一律網羅を盲信しない 【技法を使った一律網羅】 ●オールペア法で2ワイズカバレッジ100%網羅 ●状態遷移テストで2スイッチカバレッジ網羅 ●制御フローテストで複合条件カバレッジ網羅 【目的やリスクに基づいたピンポイント確認】 ●バグがありそうなところを確認 ●テストの目的にとって重要な箇所を確認 ●探索して怪しいところを深掘り △ ・テスト設計技法を学んでいない・学びたて の頃は、こちらが正しそうに見えがち ・ただし一種の思考停止。 無駄が増えがちで、リソース浪費により、 必要なテストの欠落を誘発する場合も 〇 ・ドメイン・プロダクト・品質リスクや不具合へ の精通が求められる。 経験、知識、技術の総合力が求められる ・本質的にこちらが重要。実際にプロダクト 開発を支えているのもこちら ・分析はこのアプローチを支えるために行う 

【例】8. テスト条件の優先付けを行う。テスト網羅基準を設定 する ⚫「検索履歴保存」の機能テストのテスト網羅基準（一部） • FIFO処理 • 保存数の2値境界網羅 • 保存状態の全遷移網羅 • 記録順序の確認 • 削除順序の確認 • ログインユーザ • 全遷移カバレッジ網羅 

これ以降の活動 ⚫テスト設計 • 分析したテスト条件を、設定したテスト網羅基準に従って網羅。 そのパターンをテストケースとする 

テスト分析のまとめ 1. テストベースを識別・確保する 2. テストベースを整理・理解する 3. テストの責務を具体化する 4. テスト対象を項目分けする 5. テストタイプを分析する 6. プロダクトリスクを分析し対応方針をたてる 7. テスト条件を分析する 8. テスト条件の優先付けを行う。テスト網羅基準を設定する