ソフトウェアテスト実務_中級エンジニア向け法人研修

法人研修｜中級エンジニア向け ソフトウェアテスト実務 計画・設計・実行管理・レポーティングの全体像 テスト計画立案から結果レポーティングまで、現場で通用する型を身につける うさうさ研修工房｜ IT研修講師のためのテストマネジメント講座

Orientation 本日のゴール 1 2 3 全体像を説明できる 成果物を作り分けられる 進捗と結果を可視化できる テスト計画→設計→作成→実行管理→分析・報 告の5フェーズと、各フェーズの目的を人に説明 できる。 テストケース／仕様書／手順書の違いを理解 し、目的に応じて適切な成果物を選べる。 テスターへの指示、進捗管理、結果のレポーティ ングまでを一連の型として実践できる。 対象：テスト実務2〜3年目、実行者からリーダー業務へ移行する中級エンジニア ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 02

What テスト業務の全体像｜ 5つのフェーズ ① ② ③ ④ ⑤ テスト計画 テスト設計 成果物作成 実行管理 分析・報告 方針・体制・ スケジュール ▶ 観点・技法・ 実施手順 ▶ ケース・仕様書・ 手順書 ▶ 実行指示・ 進捗管理 ▶ 課題分析・ レポーティング 実務ではフェーズは一直線ではなく、テスト実行中に設計へ戻るなど反復しながら進む。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 03

Why なぜプロセスを型で理解する必要があるのか 欠陥は発見が遅れるほど、修正コストが跳ね上がる（ Boehmの知見） 数十〜 数百x 10〜20x 5〜10x 2〜5x 1x 要件定義 設計 実装 テスト リリース後 ＝上流工程での計画・設計の質が、後工程のコストと納期を大きく左右する。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 04

① テスト計画 What 計画の3要素｜方針・体制・スケジュール 方針 体制 工程 テスト方針立案 体制構築 スケジュール設計 品質目標、対象範囲／対象外、リスクベースの 優先順位、完了基準（Exit Criteria）を文書化す る。 役割分担（PM／テストリーダー／テスター）、責 任範囲、エスカレーションルートを明確にする。 設計・実施・回帰テストの各工程に工数を配分 し、バッファとマイルストーンを設定する。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 05

① テスト計画 How テスト方針書に書くべき項目 1 品質目標 何を「合格」とするか（バグ検出率、致命度別の残存許容数など）を数値・基準で定義する。 2 対象範囲／対象外 テストするモジュール・機能とテストしない範囲を明示し、認識齟齬を防ぐ。 3 リスクと優先順位 影響度×発生確率で機能をランク付けし、限られた工数の配分順序を決める。 4 完了基準（Exit Criteria） テスト消化率・合格率・重大バグ件数など、終了判断の基準をあらかじめ合意する。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 06

② テスト設計 What 観点洗い出しと代表的なテスト技法 観点の洗い出し 機能仕様の網羅（正常系／異常系） 代表的なテスト技法 同値分割 入力を有効・無効なグループに分け、代表値でテストする 画面・入力項目の組み合わせ 境界値分析 業務フロー・状態遷移 非機能（性能・セキュリティ・互換性） 値の境界（最小・最大・その前後）を重点的に検証する デシジョンテーブル 複数条件の組み合わせと結果を表形式で網羅する 状態遷移テスト 状態の変化とイベントの組み合わせを検証する ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 07

② テスト設計 How 実施手順の検討｜設計から着手までの流れ 1 2 3 4 観点を洗い出す 技法を選定する 優先順位を付ける 実施環境を整える 仕様書・要件からテスト観点を抽出し、漏 れをレビューで確認する 観点の性質に応じて同値分割・境界値分 析などを組み合わせる リスクの高い機能・組み合わせから着手 できるよう順序化する テストデータ・環境・前提条件を明確に し、再現性を確保する 目安：手順検討まで完了して初めて「着手可能」＝手戻りを防ぐゲートとして機能する。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 08

③ 成果物作成 What テストケース・仕様書・手順書の使い分け テストケース テスト仕様書 テスト手順書 何を確認するか 何をどこまでやるか どう操作するか 前提条件・入力値・期待結果を 1行単位で管 理 対象範囲・観点・技法の全体設計を記述 画面操作・コマンドを再現可能な粒度で記述 網羅性の確認・進捗集計の単位になる レビューでテストの妥当性を合意する土台 誰が実施しても同じ結果になることが目的 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 09

④ 実行管理 How テスター実行指示と進捗管理 実行指示のポイント 1人1日あたりの実施ケース数の目安を共有する 不具合発見時の記録ルール・エスカレーション基準を明示 進捗の可視化イメージ 計画 100% 実施済 62% 合格 48% 不合格・再テスト待ち 10% 疑問点をその場で解消できる相談ルートを確保する 進捗率だけでなく「合格率」「不合格の滞留状況」も併せて追うと問題を早期発見できる。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 10

⑤ 分析・報告 What 課題分析とレポーティング バグ分析の観点 発生工程・混入工程の分布 レポートの構成テンプレ ① サマリー 結論を先に：完了基準を満たしたか／リリース可否の判断材料 致命度・優先度別の件数推移 ② 実績データ モジュール・機能別の偏り 消化率・合格率・不具合件数の推移をグラフで提示 同種不具合の再発傾向 ③ 課題と対応方針 残存リスクと、追加テストや是正が必要な箇所を明記 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 11

まとめ｜ 5フェーズ振り返りチェックリスト ✓ ① 計画：品質目標・体制・スケジュールを文書化したか ✓ ② 設計：観点を洗い出し、適切な技法を選定したか ✓ ③ 作成：テストケース／仕様書／手順書を目的に応じて使い分けたか ✓ ④ 実行管理：実行指示を明確にし、進捗を可視化したか ✓ ⑤ 分析・報告：結論から始まるレポートで課題を共有したか テストは「壊す仕事」ではなく、リリース判断のための情報を作る仕事である。 ソフトウェアテスト実務｜計画・設計・実行管理・レポーティング 12